In the age of AI, the bottleneck is shifting from writing code to specifying what we actually want.

Most of us in technology have seen some version of the famous project swing cartoon.

Illustration from ProjectCartoon.com

The customer explains one thing. The project leader understands something slightly different. The analyst designs something else. The programmer builds another interpretation. Operations installs something different again. And at the end, what the customer actually needed was remarkably simple.

We used to laugh at this because it captured one of the oldest problems in software development – what someone meant and what eventually got built were often very different things.

For decades, software engineering has focused heavily on one question – how do we build software better? For years, we tried to solve that problem with better requirements, Agile, user stories, acceptance criteria, prototypes, architecture reviews and tighter collaboration. Better languages. Better frameworks. Better architectures. Better development tools. Better testing. Better DevOps. And yet the fundamental problem never disappeared. Intent gets lost in translation.

Now add AI.

AI changes the economics of misunderstanding

Give an experienced developer an ambiguous requirement and they will usually stop and ask questions.

What exactly do you mean? What happens in this scenario? Which system is the source of truth? Who is allowed to do this? What does “done” mean?

Give an AI coding agent permission to execute against the same ambiguous requirement, and unless the workflow forces clarification, something interesting can happen – it may simply build it – Quickly – Beautifully – And potentially incorrectly.

That changes the problem. When software took weeks to build, ambiguity created rework. When AI can generate an API, write tests, refactor code, create documentation and prepare deployment artifacts in hours – or sometimes minutes – the act of producing code becomes less of the constraint. Ambiguity can now scale at machine speed. The act of producing code starts becoming less of the constraint. A different constraint becomes visible – did we clearly specify what we wanted in the first place?

The New Programming Language May Be Specification

We spend enormous energy discussing prompt engineering. But as AI takes on more execution, I think another discipline becomes equally important – specification engineering – the ability to turn business intent into clear, contextual and testable instructions for humans and AI.

Not bigger requirements documents. Not bringing waterfall back.  Quite the opposite – A good specification is a clear expression of intent with enough context for execution. It should allow a human – or an AI agent – to understand.

• What are we trying to accomplish?
• Why does it matter?
• What are the constraints?
• What systems and data are involved?
• What decisions have already been made?
• What remains open?
• What does “done” actually mean?

That changes the role of the backlog. A Jira story shouldn’t simply be a ticket waiting for someone to code. It becomes an expression of intent. And creating that expression of intent isn’t the responsibility of one role. Product owners bring the business outcome and priorities. Business analysts and domain experts translate needs, rules and exceptions. Architects and engineers surface technical constraints and dependencies. Security, data, QA and operations contribute the questions that make the specification complete.

Consider a simple Jira story

Suppose the story says – build an API to retrieve policy information. AI can certainly generate an API from that. But should it? There are dozens of unanswered questions. Which policy information? For which user? Who can call the API? What is the source of truth? What happens if there are multiple matches? What fields are restricted? What should happen when the policy system is unavailable?What are the latency expectations? What should be logged? What should the error response look like? What constitutes success?

Those aren’t really coding questions. They’re specification questions.

Experienced engineers have always filled these gaps through conversations, assumptions, institutional knowledge and judgment. AI doesn’t eliminate those gaps. It exposes them. And sometimes it does something potentially more dangerous – It confidently fills them in for us. An LLM is exceptionally good at filling gaps. Unfortunately, the answer it invents may not be the answer your business intended.

The quality of the answer starts with the quality of the question

Now imagine giving an AI engineering agent a vague Jira story. It can generate code.

Now give the same agent – a clear requirement + acceptance criteria + API standards + architecture patterns + data models + security requirements + existing code + examples of similar implementations.

The difference in output can be enormous. And this is an important distinction. The model didn’t necessarily become smarter. The context became better. That may be one of the most important lessons in AI-led software engineering. The answer isn’t necessarily to keep searching for a smarter model. Sometimes the answer is to give the model better intent, better context, better constraints and better evidence of what “good” looks like.

The bottleneck is moving

For decades, much of software engineering productivity focused on – how quickly can we turn requirements into code? AI is rapidly compressing that part of the lifecycle. The emerging constraint may instead become -how clearly can we turn business intent into something executable? That changes the engineering lifecycle. Traditionally, we might think of it as – Requirement – Developer – Code. Increasingly, it looks more like – Intent – Specification – Context – AI Execution – Human Judgement – Evidence. Each part matters.

• Intent – What business outcome are we actually trying to achieve?
• Specification – What precisely should happen?
• Context – what does the AI need to know about our architecture, systems, standards, data and constraints?
• AI Execution – use AI to perform and accelerate more of the analysis, design, coding, testing and documentation, within defined engineering controls.
• Human Judgment – review critical decisions, resolve ambiguity and exceptions, make trade-offs and validate that the outcome matches intent.
• Evidence – can we demonstrate that what was built satisfies the requirement and behaves correctly?

The better the specification and context, the less the AI has to guess. And as AI gets faster at execution, the quality of everything upstream becomes more important, not less.

Asking the right question becomes an engineering skill

There is another implication that we find particularly interesting. Engineers have traditionally been valued partly for knowing how to produce the answer. Increasingly, some of the highest-value engineers may be those who know –  which questions must be answered before anything should be built? Take our simple requirement – build an API to retrieve policy information.

A product owner asks what business outcome we’re trying to achieve and for whom. A business analyst asks about the workflow, rules, exceptions and acceptance criteria. An architect looks at it and asks about system boundaries and integration patterns. A security engineer asks who should be allowed to call it and what they should be allowed to see. A data engineer asks where truth resides and how data should be interpreted.A QA engineer asks how we’ll know the API behaves correctly across positive, negative and edge cases. An operations engineer asks what happens when a dependency fails at 2 a.m. A domain expert sees the business exception nobody else noticed. No single role owns all the right questions. The quality of the specification emerges from bringing these perspectives together.

AI can help answer many of those questions. But first, somebody has to know – that the question matters. That is engineering judgment. And judgment may become more valuable – not less – as execution becomes automated.

This doesn’t make humans less important

As AI takes on more execution, more human value moves upstream—and toward the points in the lifecycle where judgment matters most. From writing every line of code toward – defining intent, providing context, challenging assumptions, making trade-offs, setting constraints, recognizing exceptions, validating outcomes.

The scarce skill may no longer simply be – can you build it? It will increasingly become – can you define precisely what should be built – and recognize whether what was built is right? AI may make implementation dramatically faster. It doesn’t remove accountability for the outcome.

The next generation of SDLC may start before the code

This is something we have been thinking about as we develop AcxWorks, our approach to AI-led software delivery. The interesting opportunity isn’t simply putting a coding assistant in front of every developer. The opportunity is bigger. Start with the backlog. Understand the intent. Identify what is missing. Ask the questions that need to be answered. Bring in the relevant enterprise context – Architecture, API standards, Security patterns,  Data models, Existing code, Similar implementations, Testing standards, Business rules, Acceptance criteria.

Then let AI progressively help across the lifecycle – Plan – Design – Build – Test – Deploy – Operate.

• At Plan, AI can analyze the backlog, identify missing information, dependencies and risks.
• At Design, it can propose API contracts, architecture, integration patterns and technical approaches using enterprise standards and existing patterns.
• At Build, it can generate and modify code using the approved design and repository context.
• At Test, it can derive test scenarios from the original requirement and acceptance criteria—not merely test the code it generated.
• At Deploy, it can assist with reviews, release evidence, documentation and readiness while deterministic CI/CD controls what ships.
• And at Operate, production telemetry, incidents and behavior can become context for the next iteration.

The lifecycle becomes a continuous loop rather than a one-way path to production.

AI-led execution. Human governance.

This is an important distinction. AI-led engineering doesn’t mean – AI builds software and humans watch.

It means AI can take on substantially more of the execution while people retain responsibility for the decisions that require context, judgment and accountability. The engineer’s role changes from doing every step manually to guiding, constraining, reviewing and validating an increasingly capable execution layer.

That is why the starting point isn’t code. It’s clarity. Because when AI can build faster than ever, ambiguity gets expensive faster too.

Perhaps the old swing cartoon has never been more relevant

For years, the cartoon was funny because it showed how easily a simple customer need could become distorted as it moved through an organization. AI doesn’t automatically solve that problem. In some ways, it raises the stakes. We may finally have technology capable of turning ideas into working software dramatically faster than before. That’s extraordinary. But before celebrating how quickly AI can build the swing, perhaps we need to become much better at answering a more fundamental question:

What kind of swing did the customer actually want?

The future of software development isn’t just about writing better code. It’s about expressing better intent. And perhaps one of the most valuable engineering skills in the age of AI won’t be knowing all the answers. It will be knowing the right questions to ask.

AI can build faster. The question is – can we specify better?