What Your Pre-AI Engineering Experience Is Actually Worth

If you spent years learning to build software before AI tools hit the mainstream, you know what it took to get good. You spent late nights tracing memory leaks and retain cycles, learned platform lifecycles by heart, and figured out the hard way what happens when a null check slips through to a store release.

Now your feeds are full of claims that software engineering is dead because a natural language prompt can spin up an app in seconds. It's hard not to ask yourself the question running beneath all those posts: was all that time spent mastering the craft actually a waste?

The short answer is no. But giving you a soft, comforting answer isn't helpful. To understand why your experience still matters, you have to start by looking clearly at what actually got devalued.

I build mobile, so that's where my examples come from. Most of this holds anywhere, but mobile is where it bites hardest, and I'll come back to why.

What actually got devalued

Pretending nothing has changed helps nobody. A few major parts of traditional software development genuinely lost their premium.

The entry-level ramp. Historically, junior engineers built intuition by grinding through mechanical tasks: building settings screens, writing JSON serialisers, setting up form validation, writing boilerplate test fixtures. Doing that work day after day was how pattern recognition accumulated as a byproduct. Today, an LLM drafts all of it in seconds. The intuition is still necessary, but the primary pipeline that delivered it for free is gone.

Framework syntax trivia. Being the developer who memorised every quirk of a navigation stack or knew layout engine constraint rules cold used to command a real premium. A model now holds most of that and recalls it on demand. It's still useful knowledge, it's just no longer scarce.

Mobile engineers should be less surprised by this than most. We've lived through cross-platform rewrites and state management migrations every few years. Framework-specific fluency has been depreciating on roughly a five-year cycle for as long as most of us have been working. What survives those migrations is what's actually worth betting on.

Here is the real distinction: experience in a narrow tech stack ages poorly, while experience understanding how systems behave on real devices ages extremely well. If your skillset is mostly I know how to write this framework, some of your value was commoditised. If your skillset is I know how production systems fail under real-world conditions, you're holding the rarest asset in software right now.

The bottleneck shifted downstream

Writing plausible code is now fast and cheap. Knowing whether that code is correct, and catching failures early, is expensive. The engineering bottleneck didn't disappear. It moved downstream from code generation to code verification.

This is why most productivity metrics floating around right now are noise. Code generation got dramatically faster. Verification did not get faster at anything like the same rate. When verification is your primary constraint, measuring how fast you generate lines of code is measuring the easy half of the job. How fast the work feels in the editor tells you very little about how fast it actually ships. It's also why we don't quote a multiplier.

That gap is especially brutal on mobile. If a web team ships a broken merge, they can roll it back in ten minutes. Mobile teams ship code through app store reviews into staged rollouts. A bug that slips past release checks lives on user devices for days, or indefinitely on devices where auto-update is turned off. The release gate remains unforgiving, and generation tools do nothing to widen it. Everything required to make a build safe for production still falls entirely on the engineer.

Syntactically clean code vs. production realities

There's a common pattern among developers who lean heavily on AI tools: treating a model as an infallible logic engine. You prompt for a feature, receive two hundred lines of clean, compilable code, verify the happy path, and merge it.

Models are built to output plausible structures. Given a prompt, an LLM will produce code that looks clean and well-organised. That triggers a fast, passive review: you see neat formatting and assume the underlying logic is sound. The problem is that AI-generated code often lacks the defensive engineering built through real-world scar tissue. Guards for devices reporting zero-height safe areas. Exponential backoff for spotty mobile networks. The retry that exists only because one carrier's proxy silently eats the first request. Inexperienced developers read the absence of defensive code as clean design, when it really just means the edge cases were ignored.

This is where years of debugging become your primary advantage. You've accumulated an internal catalogue of failure modes. You know what happens when a screen rebuilds its entire UI tree on every keystroke on a cheap Android device, or how an un-disposed stream subscription keeps firing into a screen the user already left, until it touches state that's gone and the crash arrives in a report you can't reproduce locally.

Consider a concrete case. An engineer uses an agent to build a sync queue for an offline logging feature. The pull request looks pristine on the surface: modular architecture, clean interfaces, full unit test coverage for the happy path. But the code retries every queued write on reconnect without an idempotency key, and it updates local sync status in a step completely separate from the network response. In production, a user moving in and out of weak cell signal accumulates duplicate writes within a day, and an app killed mid-sync re-uploads everything on next launch. A junior reviewer sees neat, passing code. Years of debugging sync issues see a support queue.

Beyond logic, models have a fundamental limitation: they cannot run your application. A model can satisfy the compiler, but it can't see that the soft keyboard obscures the primary submit button, that frame rates drop during a custom transition, that translated strings break the layout in German, or that denying a system permission leaves the user stranded on a broken flow. Logic is only one piece of a mobile app. The rest requires an engineer testing on physical hardware.

The same applies to root-cause diagnosis. When AI code breaks, inexperienced developers often get stuck in a prompt loop, copying stack traces into a chat box and accepting increasingly complex code modifications for a bug nobody actually understands. Each iteration makes the codebase messier. If two prompts fail to fix a bug, that's your signal to stop prompting, attach the debugger, run the app on a physical device, and trace what's actually happening.

How your daily work actually shifts

Three things stop mattering much. You no longer hold parameter order, manifest entries or build configuration in active memory, because recognising that a problem needs exponential backoff is the engineering skill and looking up the syntax for it is not. Hand-writing model classes, serialisation, database adapters and test fixtures is largely automated. And nobody argues about formatting in pull requests any more, because linters settle it, which frees human review attention for logic.

Three things take their place, and they're harder.

Writing tight specifications. Models don't resolve ambiguous requirements, they amplify them into confident, broken code. If your spec doesn't say what happens when the write fails halfway, you'll get an implementation where it doesn't.

Adversarial code review. Reviews shift from passive approval to hunting specific failure classes: state mutations after async boundaries on unmounted screens, unnecessary sub-tree rebuilds, unpaginated network calls, sensitive data leaking into crash logs, non-idempotent writes on retry paths. You're not checking whether it compiles. You're checking what it does on the fifth retry.

Context engineering. Writing your architectural rules and boundaries into repository configuration. When your team's failure modes are documented in repo context, the tooling adopts your architecture instead of guessing at it.

The rules nobody wrote down

An AI model can infer a data schema from your prompt. It cannot infer which of your system's unwritten rules are load-bearing for your product.

It doesn't know that your local database must act as the source of truth until a sync finishes, meaning a simple server-wins merge will silently wipe out data recorded offline in a basement gym. It doesn't know that an eighteen-month-old build is still active in the wild hitting your API, meaning making a field required on the backend will start failing requests from users you can't reach with a deploy. It doesn't know that "user" means three different things across your client app, backend and analytics platform, and that confusing them caused last quarter's biggest incident.

Those constraints aren't documented in code syntax. They live in your head and in your team's collective domain experience. Feeding those realities into the development process is your core responsibility.

The real takeaway

Generative AI is a leverage multiplier for your existing skills.

Apply it without a deep understanding of architecture or production failure modes and it doesn't just produce zero value, it produces negative value. Massive amounts of plausible, neatly formatted code that fails the moment it hits real devices under spotty network conditions, built by developers who lack the experience to diagnose why, shipped behind release gates that make quick rollbacks impossible.

Apply it with years of real production experience behind you and the leverage is immense. You stop spending hours on tedious setup and plumbing, which frees you to focus on system boundaries, data flow, specs and edge cases. The parts of the job that were always real engineering anyway.

Some of what we learned over the years has been automated. But knowing how systems fail under real-world conditions is the one thing these tools cannot replace. That isn't a silver lining. It's the exact reason AI tools produce great results in expert hands and broken apps in amateur ones.

This is the thinking behind how we build mobile apps: senior engineers on the build, real devices in the loop, and verification treated as the expensive half of the job. If that's the standard you want, talk to us.