As AI in software development shrinks the time it takes to build, engineering and product leaders at our roundtable described where the hard work is heading. It is moving into problem definition, written specifications, explicit standards and a new kind of engineer. Meanwhile, roughly thirty engineers in the audience voted in real time. They said AI makes them faster rather than better at deciding, and they feel the review gap more than the leaders on stage do.
A product director at our roundtable builds video games with his six-year-old son. First, the boy records a voice note about whatever his imagination produced that day. Then his father tidies it up and asks an AI coding tool to turn it into a game.
The game arrives in about twenty minutes. Even so, the son finds the wait annoying. To his father, it feels close to magic. To the son, however, this is simply how making things works.
What feels new to us will feel normal to them
Later in the session, one guest offered a way to read that gap. He cited Douglas Adams’s rule about new technology. Anything that exists before you turn fifteen is just how the world works. Anything that arrives between fifteen and thirty-five is exciting and might become your career. After that, anything new looks like the end of society. He admitted he checks himself against it.
Another speaker compared AI to electricity. After all, people rebuilt healthcare, transport and communication on top of electricity. Nobody could picture that when the first wires went up.
In other words, the tools that still surprise today’s engineers and executives will feel ordinary to the next generation. Nobody today remembers choosing to live with electricity or the internet. Soon, nobody will remember choosing to work with AI.
That shift was the backdrop for our roundtable, “AI changed the work. Did we?” The speakers came from our team and from one of our clients. Meanwhile, roughly thirty engineers in the audience voted on each prompt in real time.
Vague objectives now show up the same day
Product building can be described as a simple formula. First, find the problem and define success. Next, propose solutions, gather data and get agreement. Finally, execute and check the result.
For years, execution took so long that it hid weak thinking at every other step. Now that execution has shrunk, the weak steps show up at once. For instance, when he gives AI agents vague objectives, he gets vague work back.
The most humbling thing about AI is realizing how bad I used to be at my job.
The product leader
That also changes what he looks for in people. When he interviews a product manager now, he asks to see everything they have built. In his view, anyone who loves product should be thrilled to have a tireless team of AI engineers. If they haven’t used it, they probably aren’t that interested in building things.
Teams can protect judgment with a few simple habits. First, ask the model for several options and their trade-offs before picking one. Next, have a person write one or two lines on why the chosen option won. Finally, review those decisions alongside the code. That way, speed stays useful, and the first plausible answer stops winning by default.
Speed and judgment are different skills
An engineering leader expects the same pressure on engineers. Lines of code no longer prove anything. Instead, engineers will stand out by understanding architecture, giving precise instructions and knowing what makes a system scale.
An engineer on the client team added a warning. Some people get hooked on how fast the answers arrive. As a result, they accept the first plausible one. AI can make teams better at deciding what to build, he said. However, that only works for people who keep asking for options and use their own judgment.
The audience vote suggests most teams aren’t there yet. Asked whether AI makes people better at deciding or just faster at building, the room chose faster by 20 votes to 9. Still, they felt hopeful about the freed-up time. On a scale of 1 to 5, they leaned toward agreeing (3.7) that AI handling the “how” leaves more time for the “why.”
Teams can protect judgment with a few simple habits. First, ask the model for several options and their trade-offs before picking one. Next, have a person write one or two lines on why the chosen option won. Finally, review those decisions alongside the code. That way, speed stays useful, and the first plausible answer stops winning by default.
The spec is becoming your source code
Next, the roundtable took on a pointed statement: teams now ship code faster than anyone can understand it.
One engineering leader argued that full understanding was always an illusion. Reviewers have always worked from mental summaries of code. AI simply adds one more layer, just as nobody reads the assembly their compiler produces.
An engineer in the audience pushed back. Compilers are deterministic, he said, but models are not. The engineering leader kept his position. Whether you write your intent in Java or in a prompt, you stay accountable for the result. So the core skill becomes understanding intent and expressing it clearly.
However, the engineers in the room felt less relaxed than the leaders on stage. They scored the statement at 4.1 out of 5, one of the session’s strongest results. “Review” also ranked among their top answers when asked what had changed most in their jobs. In short, the people checking the output feel the gap more than the people setting direction. So ask your own reviewers how much of what ships they understand, before you push for more output.
A spec for AI-built software doesn’t need to read like code. Instead, it should describe the system the way an architect would. Start with its purpose and its users. Then list its inputs and outputs, and how it connects to other systems. Next, add the constraints that matter, such as cost, performance and security. Finally, state the acceptance criteria and the things it should not do.
Where the stack goes next
Code is becoming what assembly was. Meanwhile, the written specification is becoming what code was.
The teams building the most maintainable systems with AI start with a clear, structured description of the system. It holds less detail than code, but it states expectations exactly.
He also expects strongly typed languages such as Rust and OCaml to grow, because they rule out more mistakes by design. Similarly, he expects heavy investment in AI that checks code for security flaws. He pointed to the latest generation of models, which found dozens of flaws in code that experts had trusted for decades. Because of results like that, he said, the meaning of expertise will shift.
The reasoning behind the typed-language prediction is simple. In a strongly typed language, the compiler rejects whole classes of mistakes before the code ever runs. Rust, for instance, also checks how programs use memory, which blocks many common security bugs. These languages used to be slow to learn and write. However, that cost matters much less when AI writes most of the code and people read less of it.
The product leader went further still. Human-readable code may not stay a step at all, he said. In fact, some people already experiment with systems that run without code between intent and execution. He also asked engineers to admit how much their resistance protects a well-paid skill. Far fewer people may do that translation in the future. The rest will need to take on more of the stack.
Accountability stays with people
Even so, one thing stays put: accountability. In the product leader’s view, companies hire people to clear up ambiguity and answer for the outcome.
He gave a simple example. When he hires a lawyer, he doesn’t care whether the lawyer uses a thousand assistants or ChatGPT. What matters is that the lawyer owns the decision.
An engineer on the client team said his own accountability is already moving toward the product. He now thinks more about how people use it and how his service fits with others. The audience agreed. Asked whether human accountability quietly disappears when AI writes and reviews the code, they mostly disagreed (2.6).
In practice, every AI-generated change needs a named human owner. Usually, that is the person who asks for the change and merges it. It also helps to review at the level where people can still judge well, such as the design, the interfaces and the tests, instead of pretending to check every line.
- Vague objectives now come back as vague work, the same day
- Full understanding of code was always an illusion
- The written spec is becoming what code was
- Strongly typed languages and AI security checks will grow
- Accountability stays with people, whatever the tools
- AI makes us faster at building, not better at deciding (20 to 9)
- Hopeful about more time for the “why” (3.7 out of 5)
- Code ships faster than anyone can understand it (4.1 out of 5)
- “Review” among the parts of the job that changed most
- Human accountability does not disappear (2.6 out of 5)
Was it the tool, or the brief?
Near the end, the product leader turned the criticism on himself. Most people laugh at the executive who blames engineering when a brilliant idea flops, he said. Yet he catches himself doing the same thing with AI. When an implementation comes back wrong, his first thought is that the AI got it wrong. Often, though, the real problem is a brief he never made clear.
That leaves teams with a useful habit: check the brief before blaming the tool.
1. How is AI in software development changing where the hard work happens?
Execution used to take so long that it hid weak thinking at every other step. Now that AI shrinks build time, the weak steps show up at once. As a result, the hard work moves into problem definition, written specifications, explicit standards and judgment about what to build.
2. What makes an objective clear enough for an AI agent?
It names the problem and who has it. It also says how you will measure success, which constraints apply and what is out of scope. For example, “improve onboarding” gives an agent almost nothing. By contrast, “reduce how many new users abandon sign-up at the payment step, without adding a new screen” tells it where to look and what it can’t touch.
3. What should a spec for AI-built software include?
It should describe the system the way an architect would. Start with its purpose and its users. Then list its inputs and outputs, and how it connects to other systems. Next, add the constraints that matter, such as cost, performance and security. Finally, state the acceptance criteria and the things it should not do.
4. Who is accountable when AI writes and reviews the code?
People are. Every AI-generated change needs a named human owner, usually the person who asks for the change and merges it. Also, review at the level where people can still judge well, such as the design, the interfaces and the tests. The roundtable audience agreed: they mostly disagreed (2.6 out of 5) that human accountability quietly disappears.
