For decades, software engineers have essentially been human compilers. The business had an intent (when a customer pays late twice, flag the account) and the machine needed instructions, thousands of them, precise down to the character. Engineers stood in the middle and did the translation largely by hand. And, we built the entire industry around the fact that this translation was slow: team sizes, timelines, hourly billing, and the shape of the org chart. All of it assumes that turning intent into syntax is the expensive part.
Agentic AI is collapsing that translation layer. An engineer can now describe an outcome, hand it to an agent, and get working code back in minutes. So the profession is migrating, out of the land of syntax, where the work was expressing solutions in a language machines accept, and into the land of intent, where the work is deciding and describing what should exist and judging whether it does.
The old structure was all we had so the mechanics of the work dictated the environment around it. When translation is manual, you staff for translation; a rational trade-off, and until very recently the only option that existed. But, the trade is changing underneath us and most of our companies haven't adjusted a single assumption yet.
What the Work Looks Like Now
A decade ago you could watch an engineer think by watching them type. The typing was almost the medium of thought; you figured the problem out with your hands on the keyboard. Write some tests, write some implementation code, run it, fix it, run it again...loop.
Now watch one of your senior engineers work for an afternoon. They write a spec. They define the constraints and the edge cases, the things that must not break. An agent proposes a plan and they redline it. The agent produces a change spanning 14 files and they read the diff the way an editor reviews a manuscript, push back ("you changed the API contract, put it back"), rerun the checks, and merge. Then they do it again, sometimes with 3 or 4 agents running in parallel, a cohort of very fast, very literal junior developers.
Notice what their hands actually produced. A spec. Constraints. Review notes. A pile of decisions. English, mostly. Time spent reading and judging now outweighs writing, and output stops looking like lines of code and starts looking like decisions made per day. On a good day, a startling number of them.
Measuring the Wrong Thing
That creates a problem upstairs when every dial leadership uses to manage software work is measured in syntax production. Hours logged, headcount, story points, or lines shipped. All of them proxies for how much translation was or could be accomplished. These dials still spin but they’ve come loose from the things you actually care about.
Even engineers' own internal instruments misread this moment. In 2025, METR ran a randomized controlled trial with 16 experienced open-source developers doing real tasks in repositories they knew well, using early-2025 AI tools. Before starting, the developers predicted AI would make them about 24% faster. Afterward, they believed it had made them about 20% faster. The stopwatch said they were 19% slower. METR's own follow-up in 2026 suggests the picture flipped as tools and working habits matured, but the first result is worth sitting with. Perception and measurement pointed in opposite directions, for seasoned professionals, working on their own code.
Blame the shape of the work before you blame the tools. Grafting agents onto a syntax-shaped process creates friction. But reorganizing the work around intent (spec first, review and judgement as the job, verification as a gate) allows the same tools to create compound value. So before anyone concludes that nothing changed, check what the instruments are wired to.
Who Catches the Ambiguity Now?
Vague requirements used to be caught by drag in the process. Somewhere in week 2, a developer would hit the gap mid-build, walk over to someone's desk, and ask what should happen when a customer has 2 accounts. A short but annoying journey most of the time. But also one of the most effective quality filters your company had even though it never appeared on an org chart or a process document.
Agents don't walk over to anywhere. They pick an answer and build it, convincingly, on the spot.
The constraint moves upstream from how fast your team can build to how precisely your business can define and communicate what it wants. Try it with the last one-line feature request that left your inbox. "Let customers update their own billing info." Count the decisions hiding inside that sentence. Which customers. What counts as proof of identity. What happens to invoices already in flight. Does finance get told. You'll find a dozen tiny requirements without breaking a sweat, and each one gets decided either way; the only question is whether it's decided on purpose by someone who understands the consequences, or by an agent picking the statistically likely answer.
Saying what you want, precisely, has become a leadership capability. And, it cannot be bought as a tool.
"Done" Needs a New Definition
When a person writes every line of code, comprehension comes for free. Understanding being merely a byproduct of the typing. But when an agent writes the code, understanding necessarily becomes a separate and deliberate act. Skip it and you meet the newest failure mode in software: work that merely appears to be done. The code compiles, the demo goes fine, and tests pass, which is less comforting once you know the agent wrote the tests to satisfy itself.
The fix is moving the definition of "done" to somewhere beyond the agent's reach. Behavioral checks, written and owned by the humans who are accountable for the outcome, describing what the system must do in terms the business would recognize. Practitioners call these evals, and they're quickly becoming the real ship or no-ship gate. A team that can't demonstrate its software behaving correctly, independent of the thing that wrote the code, hasn't finished the job; they’ve just stopped typing.
The Residency Requirement
When syntax is nearly free, what exactly are you paying engineers for? Curiosity, discernment, and j. Knowing what (and what not) to build, what correct means for your business, and when the machine is confidently wrong. That last one is the crux; agents fail with total conviction, and telling polished-wrong from actually-right requires a deft hand.
We've navigated a version of this migration before. When spreadsheets made arithmetic free, accountants didn't disappear. Ledger clerks did, and the profession moved up a level into analysis and judgement (a rare essay where the spreadsheet gets to be the hero). Engineering is making a similar (albeit more generalized and expansive) move now, and it favors seniority and mastery.
The uncomfortable fact is that the land of intent has a residency requirement. The engineers who will thrive there spent years in the land of syntax first. Judging code you didn't write is a skill requiring direct experience, and you can't review your way out of a problem you never learned to build your way into.
"So we need fewer engineers?" Wrong question, mostly. You need more insight per seat, which is why small senior teams are quietly outrunning much larger delivery pyramids. (Where the next generation of seniors comes from if nobody starts in syntax anymore is a real question. It deserves its own essay, and this isn't it.)
It's also why our delivery model puts one accountable senior engineer-architect at the center, the role we call the Conductor. They own the specification, the architecture, the evaluations, and the final call, directing agents and human engineers alike.
The migration is happening whether or not anyone signs off on it. If your team is writing code with agents, your best engineers are already spending their most precious hours in the land of intent. The open question is whether the rest of the company moves with them. The measures. The requirements discipline. The definition of "done." The way you buy and staff software work.
Intent over syntax is the new shape of the job, not a productivity tip. Count where your senior engineers' hours actually went last week. That record will tell you which land your company still lives in.