Early-career engineers, write your own code before AI does
I recently built native iOS and Android apps in a few weeks, reviewing every AI-written line and keeping the agent inside strict guardrails. Both apps work today, though neither has shipped yet. What I did not walk away with is real platform fluency.
That gap is the whole argument here, and it is aimed at engineers early in their career more than anyone else. An agent will hand you a working result faster than you could build it alone. The speed is not the problem. What you skip on the way there is.
I reviewed every line. I still didn't learn the platforms.
This was not my first mobile project. I had shipped Windows Phone apps years ago, and built with Xamarin, Ionic, and React Native around 2015. None of that was native iOS or Android, though, and it sat a decade removed from tooling that has since moved through SwiftUI, Jetpack Compose, and Swift's async/await model. When a recent project called for native apps on both platforms, built in a few weeks, I knew that gap would close almost entirely through an AI coding agent.
I did not do this carelessly. I knew what turning an agent loose on a codebase risks. So I reviewed every diff line by line and built strict guardrails to keep its scope and its output under control. The result held: both apps reached a working state and did what they were supposed to do.
What I actually learned split cleanly in two. Wherever the agent got an API right on the first or second try, I reviewed the code, understood what it did, and moved on, without that API ever becoming mine. Wherever it got stuck, on a handful of calls that no amount of prompting fixed, I opened the platform documentation myself and solved them the old way. Those APIs I know by heart now. The rest I can still explain, but I could not rebuild from memory.
Then a developer who had written production Swift for years joined the project. They asked good questions almost immediately, the kind a review does not surface on its own:
- which pattern was idiomatic instead of merely working
- where a call quietly cost performance
- what the platform assumed but the code never stated
Within days, they had improved performance more than my review process had in weeks.
This was the proof: review sharpens judgment, but only hands-on struggle builds fluency, and I came away fluent only in the handful of places the agent could not save me. Everywhere else, I was reviewer-competent, a real result, just not the one that builds platform knowledge.
Struggle is how understanding sticks
That split lines up with what I have watched across more than a decade of leading engineering teams: people learn at the point where things stop being easy, not before. I know what I know as an engineer because I fought for it, not because it arrived assembled. Every strong engineer I have worked with got there on the same path: hit the wall, fail at it, and only then see why the wall was shaped that way.
Cognitive psychologist Robert Bjork has a name for this: desirable difficulty. His research found that easy learning conditions (quick answers, smooth paths, no friction) often produce the weakest long-term retention. Struggling to retrieve or build an answer yourself is what makes it stick. Being handed the answer is what makes it evaporate by Thursday.
An AI agent removes exactly that friction. Ask it to write the function, explain the stack trace, or scaffold the whole feature, and it does, cleanly, on the first try, most of the time. For someone already senior in the domain the agent is working in, it mainly saves time: the judgment already exists, so it just executes faster. For someone still building that judgment in that domain, the same ease removes the one mechanism that would have built it. On this project, no matter how many years I had logged elsewhere, I was the second kind of person.
Working code is not proof you understand it
This is not an argument against using AI to move fast. The apps I built work. The project got what it needed, on the timeline it needed, even with shipping still ahead of them. An agent made that possible in weeks, instead of however long it would have taken me to learn two mobile platforms by hand first. If delivery is the only goal, AI is worth every bit of the investment.
But delivery and skill are different currencies, and AI pays out only in the first one. Everywhere it does not fail outright, it hides complexity instead of teaching it. Whether a pattern is idiomatic or merely working, whether one call quietly costs more than another: it all resolves inside the model, out of view, and never becomes yours. It is the same blind spot that lets an agent generate a clean replacement it cannot explain for code it never understood in the first place.
There is a fair counter to all of this: prompting an agent well is its own skill, and juniors may be better placed to build it than seniors are. They have not spent years forming opinions about how a codebase should look, so a new tool meets less resistance from them than it does from someone unlearning old habits. That is real, and it is a reason to hand agents to juniors rather than keep the tools away from them.
It is also a different skill from the one this piece is about. Prompting well gets you a working result fast. It does not teach you why one call costs more than another, or which pattern the platform actually expects, the way that Swift developer could tell within days. Juniors who pick up the tool quickly still need that second skill, and being quick with the tool will not hand it to them any faster.
If you already love this craft enough to get your hands dirty regardless, AI multiplies what you can build. If you reach for it because the alternative feels too hard, you are choosing the path guaranteed not to make you better at the job you are paid to do.
What should an early-career engineer do instead?
None of this means avoid AI, or ration it behind some arbitrary struggle quota. It means don't let it be the first move. Three things work, and the strongest results come from mixing them.
- Talk it through first with an AI that only asks questions, instead of one that answers them, until the gaps in your own thinking show.
- Set yourself the problem before you open an assistant: try to solve it on your own, on a clock, and bring in AI only once you have hit your limit.
- Or just open the editor and start writing code, badly, before you ask anything. The struggle of the blank file is not wasted time. It is the rep.
Simple stuff. What matters is the order: struggle first, agent second, not the reverse. Ask for the answer once you have spent enough time with the problem to recognize a right one when you see it.
The industry still needs juniors who become seniors
This is bigger than any one engineer's growth curve. I watched hiring managers cut junior roles hard over the past couple of years, on the theory that senior engineers plus AI could cover the gap. The industry is now relearning a simple fact: some of today's best senior engineers spent years earning it through exactly this kind of struggle. If nobody does that work now, there is no future senior standing behind them.
If AI can already produce in weeks what took years to learn to produce by hand, keep using it. Just make sure some of what you ship, you built the hard way too. Juniors already have an edge here: fewer fixed opinions, faster to adopt a new tool. That same openness works just as well on a new platform, once the prompt box runs out of answers. Spend some of it on the editor as well as the agent, and ten years from now you will still be able to do the work without one.