The thing I keep coming back to when I read takes about software engineering in 2026 is that the writing on the wall from people who actually ship software does not match the writing on the wall from people who post about shipping software. The latter is loud, the former is quiet, and what the quiet ones keep saying is that the fundamentals got more important, not less.
This is a short look at what the agent era actually changed, what it did not change, and where the fundamentals still do most of the work.
What the agent era changed
In the past year, agent harnesses crossed the “can it be done” line. A coding agent can take a working spec, scaffold a project, run the test suite, fix what fails, and open a pull request. That part is real, and it is not going away. Open-weight models are getting close enough to the frontier that a beefy laptop can run them locally. The delta in capability between a hosted model and a local one is small enough that “can it be done” no longer separates the two.
“Can it be done” was the start, not even close to the majority of what a software engineer does. It is closer to the welding step of the build, not the architectural step. When I learned to weld in my twenties, the first thing I made was a thing I could not lift out the door of the shop. I had learned to make something. I had not learned to make something useful. The two are not the same skill, and the second one takes longer to acquire than the first.
What the agent era did not change
Software is made up of subjective measures that rely on your viewpoint for both what you are solving now and how to live with that software over a long period of time. The seams of a system, its API, the way it composes with other software, the way it fails under load, and the way it changes when someone touches it six months from now, those are still art and science at the same time. Making software debuggable, maintainable, layered, and composable is still the trick. Most of that work still requires extensive, thoughtful reasoning.
What I see in real wins from people using coding agents well:
- Concise data at the right time. The agent gets the right context when it asks for it, not a pile of everything.
- Deterministic validation tooling. Tests with natural-language feedback the agent can use to correct itself.
- Red/green TDD as a discipline. The agent writes the failing test first, then the code, then watches the test pass. Without that discipline, the agent writes code without knowing what “done” looks like.
The discipline part is the human’s job. The agent does not invent it on its own.
What the models actually do
It helps to know that LLMs do not reason. They predict. The model is human knowledge, compressed, with weights that make some sequences of tokens more likely than others. Anything that is in human knowledge that was encoded can echo out the human reasoning, including the reasoning patterns about software that have been written down for decades. For agents focused on software development, those reasoning traces are the precious data the models are pulling from.
A useful research paper on just how bad LLMs are at reasoning is called The Illusion of Thinking. There is also a different, more fascinating area of research that includes prediction of results of actions, which is closer to what we actually want from a coding agent. If you want to explore, look into JEPA models, LeWorld Model, and recent talks by Yann LeCun. Today’s coding agents do not have that capability, and that gap is part of why “can it be done” is not “is it done well.”
The thing about instruction following
A coding agent that follows instructions well is also a coding agent that cannot tell good instructions from bad ones. Simon Willison has a name for this: the lethal trifecta. LLMs are foundationally incapable of consistently preventing prompt injection attacks. Alignment work, safety harnesses, and sandboxes add barriers, but they do not close the gaps. A system that follows instructions tirelessly, without solid reasoning, is a system that takes bad instructions as seriously as good ones.
This is one place where the fundamentals do not change. A piece of software that takes external input from a less-trusted source still needs to validate, normalize, and trust that input as little as it has to. That has been true since the first multi-user system. It is still true. An agent that calls your API based on a paragraph of natural-language instructions from a stranger still needs your API to treat those instructions the way it would treat any other untrusted input. The agent does not get a pass on that, and the API does not get a pass on that.
Trade-offs
The agent era is not free in skill atrophy. If you stop practicing the fundamentals because the agent does them for you, the agent’s mistakes will get harder to catch. The cost of catching an architectural mistake after the agent has shipped it is higher than the cost of catching the mistake before the agent writes the code.
It is also not free in time spent on context engineering. Most of the wins I see from people using coding agents well come from time spent making the agent’s context clean. That time is not free, and it does not show up in any metric that measures how fast code was written.
A few things I would weigh before leaning hard on an agent for a piece of work:
- The cost of catching a mistake later vs. sooner. If the agent is doing the work without a reviewer who can spot the architectural mistake, the cost moves to whoever reads the code in six months.
- The cost of bad context. Most agent failures I see are not model failures. They are context failures. The agent did not know what it needed to know, and the human did not realize it did not know.
- The cost of speed without discipline. If the team ships faster than the tests can keep up, the agent is the bottleneck for the next refactor, not for the next feature.
- The cost of trusting instructions too far. The lethal trifecta is real, and the agent’s instruction-following is a feature for the trusted case and a bug for the untrusted one.
In our case, the trade-off is that the agent saves time on the work the human is good at and loses time on the work the human is bad at. Your math will be different if your team is mostly good at the work the agent is bad at.
What I would tell past me
If I could send a message back to the version of me that started writing software, I would say three things.
First, learn the seams before you learn the tools. The tools change every two years. The seams are the same ones the previous generation was arguing about. If you understand seams, you can pick up any tool.
Second, write code that fails loudly. An agent that does not know it failed is worse than a human that does not know it failed, because the agent will move on to the next task without pausing to ask. Build your systems so the failure modes are obvious, in code and in conversation.
Third, do not skip the fundamentals because the agent does them. The agent does the part of the work that the fundamentals make possible. If the fundamentals go away, so does the part of the work that was valuable.
If you only do one thing from this article, treat the agent as a junior engineer who is good at the parts of the job that have been written down before, and not so good at the parts that have not. The fundamentals are the parts that have not been written down before. The agent is a tool. The fundamentals are what make the tool worth using.