There is a lot of noise about what AI does to software development, and most of it is either breathless or dismissive. I have been running a build with it since late spring, and my read is narrower than both: AI did not make software development faster so much as it moved where the work is.
The build is a new enterprise platform, designed from the ground up to carry the functional weight of what our customers rely on today and to go well past it. I am going to stay general about the product itself. We have not announced it yet, and I am not going to get ahead of a launch I am responsible for. Customers should hear it from us directly, and in the right order. What matters here is the shape of the problem, and that part I can describe plainly. It is enterprise software in a regulated market. The requirements are real, the compliance surface is real, and being wrong does not surface in a retro. It surfaces in an audit.
Here is what actually changed, and it is not what I expected.
The developers stopped spending most of their time writing code. They orchestrate agents and review what comes back: not every line, but samples, chosen where the risk sits. That is a different job. It rewards judgment about what to inspect more than fluency in a language. The good ones got better at it quickly, because the underlying skill was never typing.
Testing changed in the same direction. Regression coverage that used to be a largely manual discipline is now built and run by agents, orchestrated by those same developers. The work did not disappear. It moved upstream, into deciding what has to be verified and what it means to be correct, which, in a regulated system, is a question with a documented answer rather than a matter of taste.
That last point deserves more than a clause, because it is the one people skip. Building this way does not mean trusting a generated answer. It means the opposite. Everything is specified to a standard that can be checked, the coverage that proves it is itself built and run continuously, and human review is aimed deliberately at the places where an error would matter most. I would not put agent-built code into a compliance-bearing system on faith, and I have not asked anyone else to. The verification discipline is the price of admission, not an afterthought.
And I became the business analyst. Not by title, and not because I set out to take on more. It happened because the constraint moved to my end. I put the requirement into Claude, and the stories, the specifications, and the ticket structure come back built. What used to take a week of translation between intent and implementable detail now takes an afternoon, and the limiting factor is how clearly I can state what I actually want.
That is the whole finding, and I want to be careful about how I say it.
A developer who might have carried a single story through a two-week cycle can now, on a good day and inside our token budget, move several in one. I am deliberately not going to turn that into a multiple. The stories are not the same size, the ceiling is not the average, and we are still early enough that I would not defend a number I have not lived with for a full year. Anyone quoting a clean multiple on this right now is selling something.
What I will defend is the direction. Implementation is no longer the thing we wait on. Specification is.
That turns out to be a harder problem than it sounds, and it is the reason I think this is a product leadership story rather than an engineering one. When implementation was expensive, a vague requirement got absorbed. A developer would ask a question, make a reasonable assumption, and the ambiguity would quietly resolve somewhere between the ticket and the commit. That absorption was invisible, and it was doing enormous work.
Agents do not absorb ambiguity. They resolve it, immediately and confidently, in whatever direction the words point. A requirement that was 85 percent specified used to produce a short conversation. Now it produces 100 percent of something, built fast, and some fraction of it is wrong in a way that is expensive to see. The failure mode is no longer slow delivery. It is confident delivery of the wrong thing.
So the scarce skill became writing things down precisely enough to be built from. Which is, I would point out, exactly the discipline that regulated product work has always demanded.
I have spent most of my career in a market where a requirement that is almost right is a compliance finding. You cannot hand a regulator an assumption. Eligibility rules, audit trails, retention, what counts as a duplicate: all of it had to be specified to a standard where a stranger could implement it without guessing, because eventually a stranger would, and eventually someone would audit the result. I did not think of that as a transferable skill. It felt like a tax the market imposed. It turns out to be the exact muscle this way of building requires.
That is the connection I did not see coming. The two things I have been doing for twenty-five years, translating policy into logic precise enough to survive an audit and owning the product decision behind it, collapsed into a single activity. The specification is the product decision now. There is much less distance between deciding and shipping, which is exhilarating, and it also means a sloppy decision reaches production faster, which is the part that keeps me careful.
I do not want to overstate where we are. We are in the middle of this, not at the end of it. I do not yet know how it holds up across a full release cycle, what it does to long-term maintainability, or where the real ceiling sits once token economics stop being the binding constraint. I have opinions. I do not have a year of evidence, and I have learned to tell those apart.
But I am confident about the shape of it. The work moved upstream, toward knowing precisely what you want and being able to say it. That was always the job. It is just no longer possible to be vague about it and have the gap absorbed downstream by someone who cares.
Which is a good trade, if you have spent your career in a market that never let you be vague in the first place.