05

Article 5 of 12 · ARTHA Craft

I Stopped Asking the Agent What to Build. I Started Telling It. The Difference Was Everything.

The code was correct. The UI was complete. Even I could not use it.

Jitander Singh Chauhan

Lead AI & Data Technologist · Haystream

There is a version of AI-assisted development that feels like collaboration.

You describe what you need. The agent interprets. It fills in the gaps, makes the calls, decides how things connect. It moves fast. It is confident. It produces something complete.

And for the first few weeks, that felt like exactly the right way to work.

Then I looked at what we had actually built.

The functionality was there. The code was correct. Every feature I had described had been implemented. But the interface, the thing a real user would sit in front of and try to use, was so technically oriented, so shaped by implementation logic rather than human logic, that even I struggled to navigate it the first few times.

Not because the agent had failed. Because I had given it the wrong brief.

I had been asking: what should we build?

I should have been telling it: exactly what to build, for whom, and how it should feel to use.

Those are not the same thing. And the distance between them is where most AI-assisted development quietly goes wrong.

What I Had Misunderstood About the Agent's Role.

The agent is an extraordinary executor. [1] Given a clear brief, it implements with speed and precision no human developer can match. Given an ambiguous brief, one that leaves design decisions open, it fills those gaps with its own judgment.

And its judgment is technical. Not wrong. Not careless. Technical.

When left to decide how something should look or flow, the agent defaults to what is architecturally logical. What is clean from an implementation perspective. What makes sense if you understand the system from the inside out.

Real users do not understand the system from the inside out. They arrive from the outside. They make decisions in seconds based on what feels intuitive, not what is technically coherent.

The agent cannot simulate that perspective unless you give it that perspective. Explicitly. In the brief.

The Go-Ahead Moment.

Before any coding session, before the agent writes a single line of implementation code, the planning is done. Separately. Deliberately. In a session whose only job is to think, not to build.

🧠
Plan
Design decisions locked. UI direction set. Every gap resolved.
Approve
Architect reviews mockup. Signs off. Gives explicit go-ahead.
⌨️
Execute
Coding agent builds from locked brief. No invention. No gaps.

Two things happen in the planning session that never happened before:

First: design decisions are locked. Not left open for the agent to interpret. Every decision about how the feature should work, look, and feel: answered, documented, approved before a line of code is written.

Second: the UI is reviewed before the code exists. The interface is designed and mocked up as a visual artifact in a dedicated design step, and the architect reviews and approves it, or rejects it and asks for changes. Only after that approval does the go-ahead get given, and the approved design becomes an input to the brief, not something the coding agent invents while it builds. This single step eliminated an entire category of rework from every project I have run since.

But Here Is What Most Teams Miss Entirely.

The planning agent and the coding agent should not be the same session.

A planning session has a fundamentally different job than a coding session. Planning requires challenge, exploration, devil's advocacy, gap-surfacing. Coding requires precision and execution. The mindset that makes a great planning agent, curious, questioning, surface-every-gap, is actively unhelpful in a coding agent that needs to execute a locked brief without second-guessing it.

Most developers use one session for both, asking the same agent to think and build simultaneously. The result is an agent making design decisions while writing code, because nobody separated those responsibilities before the keyboard started moving.

The Three-Role Model.

1

The Deep Thinker

Planning Session

A dedicated session whose only job is to analyse the requirement, challenge assumptions, explore design options, surface every gap, and propose the UI direction. It never writes implementation code. It produces the brief: a structured document capturing every decision made and every question resolved.

2

The Architect

You

Reviews what the planning session produced. Makes the final calls. Locks the decisions. Approves the UI direction. Signs off on the brief. Only you give the go-ahead, and go-ahead means all decisions are locked, all questions are answered, all design choices have been made. Not mostly made. Completely made.

3

The Coding Agent

Execution Session

Receives the locked brief. Executes precisely. Makes no design decisions, because none remain to be made. Fills no gaps, because no gaps remain to be filled. Builds exactly what was designed. No more. No less. No interpretation required.

Three sessions. Three distinct jobs. No single session trying to think and build at the same time. This is not overhead. It is specialisation: the same principle that made human software teams better when architects were separated from developers.

The Difference Between Asking and Telling.

❌ Asking

"Build me a user dashboard."

An invitation to invent. The agent fills every gap with its own judgment: technically coherent, potentially misaligned with what your user actually needs.

✅ Telling

"Build a user dashboard with these specific sections, this layout, this navigation pattern, these data points in this priority order, as approved in the mockup from the planning session."

A brief. The agent builds exactly what was designed. No more. No less. No interpretation required.

The human holds the decisions. The agent holds the keyboard. [2]

Not as a rule to follow. As a boundary to protect. Because every time that boundary blurs, the product pays for it later in rework, in confusion, in a UI that even the architect cannot immediately parse.

That gap, between asking and telling, is where most AI-assisted development goes wrong. And it goes wrong quietly, because the output looks complete. The code runs. The tests pass.

It just doesn't feel right to the person who has to use it.

Research & Further Reading

  • [1] Bridgers et al. (Google DeepMind), "Human-AI Complementarity: A Goal for Amplified Oversight", arXiv:2510.26518, December 2024: Drawing on a meta-analysis of 106 studies (Vaccaro et al., Nature Human Behaviour, 2024): "On average, human-AI teams perform statistically worse than humans or AIs alone." Complementarity only emerges with explicit division of labor where humans own decisions and AI executes subtasks. Academic Paper
  • [2] Brooks, F.P., The Mythical Man-Month, Addison-Wesley, 1995: "Conceptual integrity is the most important consideration in system design." Brooks argued that a single architect's vision, not committee design, is the hallmark of successful systems. In AI-assisted development, that architect is still human. Book
  • [3] Li et al., "Structured Chain-of-Thought Prompting for Code Generation", ACM TOSEM, 2025: Structured intermediate reasoning before code generation improved accuracy by up to 13.79% over standard prompting, confirming that separating design (planning) from execution (coding) produces measurably better output. Academic Paper

← Previous

Article 4

Next →

Article 6: I Replaced My Chat History With 5 Documents