While building KageFlow, I repeatedly tried to make my AI receptionist more reliable by improving its prompt.

Each patch fixed one behaviour, then exposed another. Conversation state drifted. Tools executed at the wrong time. Latency increased. One instruction improved a test case while weakening another.

Eventually, I realized I was fixing the wrong layer.

The model was not the entire problem. The architecture and development workflow around it were.

Most developers ask AI to code too early

AI can generate code quickly, but it cannot rescue an unresolved product decision, an unclear architecture, or a task with no meaningful definition of completion.

When we give an agent an ambiguous request, we are not removing the engineering work. We are allowing the agent to make hidden product and technical decisions on our behalf.

The generated code may compile. It may even pass tests. But it can still solve the wrong problem.

My current workflow starts much earlier:

Idea
  ↓
AI-guided discovery
  ↓
Human decisions
  ↓
Architecture and contracts
  ↓
Bounded tasks
  ↓
Automated validation
  ↓
Human review

My working heuristic is to spend roughly 80% of the effort shaping the work and 20% supervising its execution.

That does not mean writing enormous specification documents. It means eliminating the ambiguity that would otherwise reappear as incorrect code, technical debt, or repeated rework.

Before implementation begins, I use AI to interview me about the idea, expose missing decisions, challenge assumptions, and propose possible features or technical approaches.

The AI helps explore the solution. I decide what becomes project truth.

Autonomy should depend on consequence

I do not believe every agent should operate under the same level of control.

When I needed a marketing website for KageFlow, I gave the coding agent almost complete autonomy. It controlled the copy, layout, components, styling, and visual execution.

I only fixed the information that had to remain true:

  • Pricing
  • Contact details
  • Core business information
  • A few design references

The page was reversible, low-risk, and not where I wanted to spend my attention. Shipping quickly mattered more than controlling every design decision.

The AI receptionist engine was different.

Its architecture determined conversation state, tool execution, latency, reliability, and whether customer information could be handled correctly. I defined the architecture and required the agent to ask before making any change that affected those properties.

The agent could choose local implementation details, but it could not silently redesign the system.

The principle is simple:

Delegate based on consequence, not task size.

A large marketing page can tolerate broad autonomy. A small change to state management may require strict human approval.

Autonomy should also decrease as a product matures:

Prototype  → High autonomy
MVP        → Moderate autonomy
Production → Restricted autonomy

Early experiments favour speed and reversibility. Production systems favour consistency, reliability, and controlled change.

The workflow should recommend an autonomy level based on task risk, reversibility, development stage, and delivery priority. The human should retain the ability to override it.

During execution, planned checkpoints prevent long-running drift. An agent should continue independently between those checkpoints, but stop immediately before crossing a protected architectural, security, data, performance, or reliability boundary.

“Done” is still a human decision

An agent reporting that it has completed a task is not evidence that the task is complete.

Automated tests and acceptance checks should run whenever the requirements are objectively testable. They can confirm that the implementation follows measurable rules.

They cannot always determine whether the result serves the intended product outcome.

That remains a human responsibility.

Agent implementation
        ↓
Automated checks
        ↓
Human review
        ↓
Complete

The goal is not to supervise every line of generated code. It is to preserve human judgment where that judgment has consequences.

The engineering work has moved

AI has reduced the effort required to produce an implementation. It has not removed the need for product judgment, architecture, task design, validation, or accountability.

Those responsibilities now matter earlier.

An AI-native engineer is not simply someone who uses a coding agent frequently. It is someone who knows:

  • what must be decided before implementation;
  • what can safely be delegated;
  • how much autonomy each task deserves;
  • when an agent must escalate;
  • and what evidence is required before work is accepted.

Better prompts helped my system temporarily.

A better workflow changed how I build software.

AI did not replace software engineering. It changed where the engineering happens.