The hard paths of growing a software engineer are now optional.
They haven’t disappeared. You can still design an interface by hand, debate the right architecture, and refactor until the shape is right. You just don’t have to. And people rarely choose friction when a shortcut sits right next to it.
Without that friction, we stop building the engineering judgment that turns someone who can write code into someone who can build software. If we ignore this shift, we will produce a generation of engineers who can make software work, but who never build the muscle for making it good — secure, usable, reliable, cheap to change, or whichever of those a particular system actually needs.
What the Hard Ways Actually Teach You
Before AI tools, growth meant struggling through design patterns, software architecture, and object-oriented design. That struggle looked like it was about code. It wasn’t. It was training you to answer two questions that sit above the code.
The first is: what does “good” mean for this particular piece of software? Making it work is the minimum bar. The real question is which of a dozen viable designs you should pick, and that depends on which properties you’re optimizing for. These are the system quality attributes — you may have met them as non-functional requirements. I’ll call them quality attributes.
The catalog runs to roughly a hundred entries: availability, security, usability, accessibility, scalability, maintainability, testability, observability, portability, interoperability, latency, recoverability, auditability, and on and on. Nobody optimizes for all of them. Many of them trade directly against each other. The skill is figuring out which handful actually matters for the system in front of you, and then designing so those few hold. That’s what makes one working implementation better than another working implementation.
The second is: what do you know that isn’t written down anywhere? Which team owns the service you’re about to depend on, and how fast do they move. Whether this prototype gets thrown away in six weeks or carries production traffic for six years. What your organization is optimizing for this quarter. Which stakeholder will quietly veto the elegant option. I’ll call this the unwritten context, because that’s exactly what it is — real constraints that live in people’s heads, in hallway conversations, and in decisions nobody documented.
Put those together and you have the actual difference between a junior and a senior engineer. Both can implement the ask. The senior engineer knows which quality attributes this system has to hold, reads that from the unwritten context, and picks the implementation that gets there. That’s the whole job, and absorbing it takes years.
Now here’s what changed. AI coding tools handle implementation well. You prompt the tool, and it handles the structure and the refactoring. You are no longer in the business of planning dependencies or getting stuck on architecture. That removes real friction — and it removes the exact exercise that used to train you to choose quality attributes and read unwritten context.
The Muscle Is Already Weakening
This is not a hypothetical worry. Two studies show it happening, and both measure what happens to the person rather than what happens to the code.
Start with learning. In a randomized field experiment published in PNAS, nearly a thousand high school students got access to a GPT-4 assistant while practicing. Their practice scores rose 48%. Then the researchers took the assistant away for the exam, and they scored 17% below students who never had it. Two details matter more than the headline: the students never noticed it happening, and a second group using a version that gave hints instead of answers showed no loss at all. The subject was math, not software, but the mechanism is the one I’m describing — and the damage came from how the students used the tool, not from the tool.
Experience doesn’t protect you. METR ran a trial with sixteen developers in repositories they had worked in for five years, randomly assigning each task to AI or no AI. The AI tasks took 19% longer. Asked afterwards, the developers said AI had made them about 20% faster. They had the direction backwards, in code they knew by heart. Sixteen people is a small sample, so don’t lean on the exact numbers — but if veterans can’t tell, someone who never built the muscle has no chance of telling.
Put the two findings together and the risk gets specific. Shipping working software no longer requires you to choose quality attributes or read unwritten context, so you can produce all year without practicing either one. And the gap doesn’t announce itself — you feel fast, not weak. That’s how a skill disappears without anyone deciding to give it up.
Why AI Still Can’t Do This Part
The muscle still matters because of two gaps, and they map onto the two things this job actually turns on: the quality attributes go unscored, and the context goes unwritten.
Unscored. The benchmarks that drive coding models score one thing — does the patch pass the tests? Passing tests is the minimum bar, not the quality attributes a good design has to hold. Labs optimize their models against what the grader can measure, and no grader measures whether a design will still be cheap to change in two years. When METR had open-source maintainers review AI patches that had already passed the automated grader, they rejected roughly half. They cited regressions elsewhere in the codebase, and quality-attribute failures — maintainability, and fit with the conventions of the repository.
Unwritten. This gap is the harder one, because no amount of training closes it. A coding agent can’t see the unwritten context. It doesn’t know that the service you’re calling belongs to a team mid-migration, that your director killed this exact approach last quarter, or that “we need this by Thursday” means the prototype is disposable and the elegant version is waste. None of that is in the repository. It isn’t in any document either.
The two gaps compound, because the unwritten context is what tells you which quality attributes to hold. Whether this thing lives six weeks or six years decides how much maintainability is worth. Who the users are decides whether accessibility outranks latency. Without those answers an agent still has to choose, so it falls back on a default. The default may happen to suit your situation, but nothing in the process aimed it there, and a mismatch usually surfaces months later, when it’s expensive to undo.
Someone has to supply that judgment. For now, that someone is you.
How Long Until It Can?
The two gaps close on completely different schedules.
The unscored gap closes fast. Models are improving quickly at handling long, complicated work — METR finds that the length of task a frontier agent can finish on its own has been doubling roughly every seven months since 2019, and faster than that in the last two years — and researchers are already building benchmarks that score maintainability rather than just passing tests. Give this a few years and the tools cover the implementation craft.
The unwritten gap is different, because the bottleneck isn’t the model. For AI to reason about your organization, your organization has to become legible to it — decisions recorded, priorities stated, tradeoffs captured somewhere other than a meeting nobody transcribed. Some of that will happen as agents sit closer to where the work happens. How fast organizations change their habits sets the pace here, not how fast models improve. And habits don’t double every seven months.
So I’m not going to give you a number, because I don’t have one and neither does anyone else. What I’ll give you instead is the signal to watch for. You’ll know we’re close when an AI tool pushes back on your instruction — when it tells you not to build the thing, or flags a constraint you never typed, because it understood something about your situation that you didn’t say. Today, tools do what you ask. When they start telling you what you should have asked, the muscle I’m describing genuinely becomes optional.
We’re not there. Until we are, this is the part of the job that’s still yours.
If You’re Early in Your Career
Train the muscle deliberately. The first two close the unscored gap, the next two close the unwritten one, and the last tells you whether any of it is working.
Name the quality attributes first. Before you implement, write down the three or four this system has to hold, and say why the rest can slip. Choosing the shortlist is the skill; measuring against it is the easy part.
Own the contract. Draft the interface and the test cases yourself, then let AI implement against them. Deciding exactly what correct looks like is the cheapest design practice there is.
Ask what isn’t in the ticket. How long does this live? Who owns the service I’m about to depend on? Was this approach tried before, and why was it dropped? Nobody will volunteer these answers, and no tool can retrieve them.
Write down what you learn. When you find out a team is mid-migration or a deadline makes something disposable, capture it. Your teammates benefit now, and you’re building the record tools will eventually need.
Predict before you read. Say what you expect AI’s design to look like before you open it. Where you were wrong is where your judgment is missing — otherwise you’ll never notice the gap, and the METR developers didn’t.
Delegate to AI for two things only: implementing a design you’ve fully planned, and acting as a sparring partner who critiques your approach.
If You Lead a Team
Everything in the last section asks a junior engineer to work slower on purpose. That won’t survive a team that measures them by tickets shipped — no amount of advice beats an incentive. Fixing the incentive is your job, not theirs.
Review designs, not just diffs. If the only artifact a junior engineer produces is a pull request, you are only training their prompting.
Put the quality attributes in the ticket. Nobody trains judgment against targets nobody stated — and stating which attributes don’t matter here teaches as much as stating which do.
Require design-first on high-ambiguity work. Not every task needs a design doc, but the ambiguous ones need a technical discussion before anyone generates a line of code.
Reward the question. When someone asks who owns a service or why the elegant option got vetoed, treat it as the work, not a delay — and answer with the reasoning, not just the verdict. A team that learns your decisions without your reasoning has learned nothing.
Keep your seniors teaching, not just checking. AI produces more code than ever for them to review, and review expands to fill whatever time they have. If verifying output consumes every senior hour, nobody builds the judgment you’ll need in five years.
Keep Building It
Intentional training is incredibly difficult. Not because the exercises are harder than they used to be, but because a highly effective shortcut sits right next to you.
That is the trap. The hard way hasn’t gotten harder. It just stopped being mandatory, and nothing in our incentives replaces the pressure it used to apply.
You have to apply that pressure yourself. The tools will cover implementation. What they can’t yet reach — the quality attributes, and the unwritten context that tells you which ones matter — is what will define your career.