For as long as I can remember, we have insisted on the opposite. The best developers understand the domain. They sit with the people who will use the thing. They learn why it matters before they build it. Somewhere along the way, most of us came to believe that the understanding and the building were the same craft.
I am no longer sure they are.
When I watch a capable developer work with LLM now, the seam between the two begins to show. They are not reasoning their way through the domain. They are describing an outcome, steering the model toward it, testing what comes back, correcting it, and trying again until the result is right. What you are watching is not comprehension. It is execution, and execution of a particular and demanding kind. Dont get me wrong, its a skill and I see people with varying levels of this skill now.
It reminds me, oddly, of a factory in Shenzhen.
A company sends a specification. The factory has no idea who the customer is, what the product means, or why anyone would want it. It builds, tests, returns a prototype, takes the corrections, and builds again. It can take many rounds, and still the loop moves faster than the company could have managed alone.
And the factory is not the lesser party in that exchange. It holds something the company does not: a deep, specialised mastery of how to make the thing, quickly and well. We send work to Shenzhen precisely because that execution is hard, and rare.
The same may be true of this new kind of AI Engineer. Not understanding the business is not the absence of skill. It is the presence of a different one. Knowing how to turn an intention into working software through a machine, reliably and at speed, is becoming a specialisation in its own right.
None of this means the understanding stops mattering. It moves upstream, to whoever can turn a vague requirement into a clear specification precise enough for this "new" developer to follow. That is where much of the difficulty now lives.
Which leaves a question I keep returning to. As we separate the people who understand why from the people who build, each becomes more specialised, and faster. What do we lose when the two are no longer the same person?
This is part of "What If", a series where I share questions I keep returning to. They are my own thoughts and opinions, shaped by experience and projects around me rather than formal research, and shared to make us think rather than to settle anything.
Top comments (2)
Honestly, in the world I've been living in for the past 3 years this has always been the way of things, even before AI. I worked in 2 very large projects, managed with the Scaled Agile Framework, for the last 3 years. In those projects, I had a product owner and a business analyst on the Scrum team I worked in. The product owner did all the customer communication, and the business analyst translated the business analysis results into JIRA tickets for us developers to implement.
However, I think letting developers work from specifications alone is a grave mistake, with or without AI. I always appreciated having at least a rough idea of the business functionality I was actually implementing, and having some idea of the needs of the customer. This made it easier to have a mental model of what was actually happening when we executed the code, which in the spirit of domain driven design I think is extremely important so the BA and the dev are on the same page when they talk about a feature. It's also easier to know what parts of the application are truly critical, and what parts are maybe a bit less important. That way, when a problem happens I can put it into its proper context without having to do laborious translation from the technical problem to the business impact going through the BA.
Also, I don't see why exactly you would isolate those AI engineers from knowing the business impact of their work. It seems a bit lazy to be honest. As if we were back in the 80s and 90s, before the agile movement, where devs really were coding from just a specification and nothing more. We learned with all the failures happening back then that this was a bad idea. Why would this learning be different just because we can produce code faster with AI? The AI engineer still has to review the produced code after all, and for that having some business context is always better than having no business context.
If the circle is fast enough, what does it matter? You get the end result and the steps and mistakes in between are not seen. There is no plan, only the objective.