I think a lot of teams are still asking the wrong question about AI coding tools.

They ask whether the model can write the code. That is not the interesting part anymore. The interesting part is whether the model can take a clear spec, stay inside the boundaries, and keep working until the feature actually behaves the way it should.

That is the shift I have been watching closely with GitHub Copilot.

When I let Copilot work from a proper specification instead of a loose prompt, the experience changed completely. It stopped feeling like autocomplete with ambition and started feeling more like a junior engineer who can move fast, explain its reasoning, and keep iterating if the task is framed correctly.

The Old Way Looked Faster Than It Was

The early AI coding workflow was simple. You described a feature in broad terms, watched code appear, and got a short burst of excitement because something existed on screen in seconds.

Then the real work began.

The model had guessed at edge cases. It had invented defaults. It had skipped non-goals because nobody stated them. You got something that looked like progress but still required a human to reverse-engineer what the system thought you meant.

That is why so many AI demos felt impressive at the start and expensive at the end.

What Changed When I Started With the Spec

The breakthrough was not more enthusiasm. It was more structure.

Instead of saying, “build this feature,” I started forcing the work through a clearer sequence: outcome, constraints, non-goals, acceptance criteria, and the smallest testable slice. That sounds obvious, but most teams still skip at least half of it when they talk to an AI agent.

When the feature is described that way, Copilot has far less room to improvise.

That matters because large language models are very good at filling gaps. The problem is they do not always fill them with the thing you wanted. A spec reduces the surface area for that kind of silent drift.

Copilot Behaves Better When Intent Is Explicit

GitHub’s direction with agent mode makes this more obvious now. The agent can inspect files, suggest commands, iterate on errors, and keep moving toward a goal instead of stopping at the first answer. That is a meaningful improvement over the old pattern of one prompt, one draft, one shrug.

But the more autonomy you give the tool, the more dangerous ambiguity becomes.

In my own testing, the difference between a vague prompt and a structured spec is not subtle. With the vague prompt, I get motion. With the spec, I get alignment.

That is a much more valuable outcome.

What Actually Happened

When I gave Copilot a real specification for a feature, a few things stood out immediately.

First, it decomposed the task better. Instead of jumping straight into code everywhere, it identified the shape of the change and broke the work into smaller units that were easier to inspect.

Second, it asked better implicit questions. Sometimes that showed up as clarifying steps. Sometimes it showed up as a more cautious implementation path. Either way, the quality of the output improved because the spec had already exposed the decisions that normally stay fuzzy until late in the build.

Third, review got easier. I was no longer reviewing a pile of guessed intent. I was reviewing whether the implementation matched the document I had already decided on.

That is a very different use of human attention.

The Real Benefit Was Not Speed

Yes, it was faster.

But speed is still the least interesting metric here.

The bigger gain was fidelity. The feature that came out was much closer to what I meant on the first serious pass. That reduced the usual rework loop where the human has to keep correcting assumptions the model made because the instructions were underspecified.

This is also where people underestimate the value of specs in AI-native delivery. A spec is not bureaucratic padding. It is the control surface.

If the spec is weak, the model has to make product decisions. If the spec is strong, the model can spend its effort implementing instead of improvising.

Why This Matters More Now

This is becoming more important because the models are getting better at end-to-end execution.

GitHub has been pushing Copilot further into agentic workflows, where it can reason across files and iterate toward completion. OpenAI has made a similar move with Codex, framing the newer models as tools that can support a broader range of software lifecycle work, not just code generation.

That means the bottleneck is shifting.

The question is no longer, “can the model type code fast enough?” The question is, “can the team define the work clearly enough for an agent to execute it well?”

That is a much more uncomfortable question for a lot of engineering organisations, because it exposes how much ambiguity was already present in their existing process.

The Human Role Did Not Shrink

If anything, it became more important.

I still had to decide what the feature should do, what it should not do, how much risk was acceptable, and whether the result was good enough to merge. AI did not remove responsibility. It made weak thinking visible much earlier.

That is useful.

It also reinforced something I keep seeing across teams adopting these tools seriously: the human advantage is moving away from raw typing speed and toward specification quality, systems thinking, and review judgment.

You still need engineering discipline. Probably more of it.

What I Would Not Do Again

I would not hand a powerful agent a one-line instruction and expect reliability.

That workflow is still fine for rough prototypes, throwaway experiments, and low-stakes exploration. But if the feature matters, if it touches shared systems, if it has consequences beyond a demo, then the prompt-only approach is just borrowed time.

You eventually pay for every missing decision.

What I Would Recommend Instead

Start with one feature that is meaningful but bounded.

Write the outcome in plain English. Add the non-goals. State the constraints. Define the edge cases. Spell out the acceptance criteria. Then let Copilot work from that, not from a vague paragraph typed in a hurry.

If the result is poor, do not just blame the model. Inspect the spec. In my experience, that is where most of the real leverage is.

The surprising part of this experiment was not that Copilot could write a feature from a spec.

It was that once the spec was strong enough, that started to feel normal.

And I suspect that is the real story of this phase of AI engineering. The tools are becoming capable enough that the quality of what they build is starting to mirror the quality of the thinking that frames the work.

• Vibe Coding Is Dead. Spec-Driven Development Just Replaced It
• Copilot Memory is Now Default and I’d Disable It in 3 Cases
• About
• Anthropic’s DoD stance just changed what “safe” enterprise AI means
• Harness Engineering and the Rise of AI-First Software Delivery