This article is inspired by the work of Hoang Nguyen.
The Illusion of Speed in the Prompt Era
For the past two years, the industry has been obsessed with the "Prompt." We've been told that if we just find the right incantation, the perfect sequence of tokens, the AI will do everything. So we spent time crafting prompts, building libraries, categorizing them. We got faster at asking the AI for things. And it worked. For a while.
The reality, though, is that prompts solve a surface problem. They make a single AI interaction faster. They don't make a workflow faster. They don't make it more reliable. And they certainly don't prevent the AI from drifting, skipping verification steps, or quietly ignoring architectural decisions you made three sessions ago.
The engineers who are actually shipping faster with AI today aren't better at prompting. They've built systems where the AI isn't just a code generator β it's a participant in a structured, self-reinforcing workflow. That's a fundamentally different problem to solve.
The Bottleneck Was Never the Model
Here's a pattern that many engineers who use AI daily will recognize. You open your agent, you describe a feature, and the AI starts generating code. It looks good. You review it. You ask for something else. You copy the context from the previous message, re-explain the constraints, ask it to verify its own output, and then realize it's already moved into implementation without actually reviewing the design. You pull it back. You remind it about the edge case. You push it to write the tests. You find it wrote tests for the implementation, not the requirements.
You're doing a lot of work. But you're not writing code.
This is the real bottleneck: not the model's capability, but the engineer's cognitive overhead in orchestrating the AI's behavior across a multi-step workflow. The moment you step away, or context gets too long, or you move too fast, quality degrades silently.
What Changed: From Commands to Workflow Infrastructure
The shift is subtle but significant. Six months ago, a sophisticated AI setup might look like this: a set of reusable prompt templates, some custom commands in your editor, a decent system prompt. You could kick off requirement writing faster, structure planning better, avoid some of the repetition. It was a power-user setup.
But the commands were still invoked manually. The templates still depended on the engineer to connect requirement β design β implementation β review. The workflow was only as consistent as the engineer's discipline on a given day.
The next level β the one that actually changes the daily experience β is building workflow infrastructure: skills, memory, auto-triggered verification, and structured phase transitions. Tools like AI DevKit operationalize this shift. The difference in practice:
| Dimension | β Old (Commands + Templates) | β New (Workflow System) |
|---|---|---|
| Context between sessions | Lost. Re-explain every time. | Persisted in memory. Auto-recalled. |
| Workflow progression | Engineer manually triggers each step. | Skill system auto-advances phases. |
| Verification | Skipped when moving fast. | Auto-triggered. Hard to skip. |
| Test scope | Tests written against implementation. | Tests written against requirements. |
| Engineering rules | Remembered (or forgotten) by engineer. | Stored in memory, surfaced automatically. |
| Engineer's role | Orchestrator + developer + reviewer. | Product decision-maker + final reviewer. |
A Concrete Example: From One Sentence to PR in Under 30 Minutes
Here's what workflow infrastructure looks like in practice, drawn from a real feature implementation.
The feature: when a user runs ai-devkit skill add <registry> without specifying a skill name, show an interactive multi-select list so they can choose what to install. Small, but real. One sentence of instruction to Codex.
What happened next wasn't code generation. It was a workflow:
- Requirement phase: The system scaffolded a structured requirement document β not just paraphrasing the prompt, but expanding it with edge cases and constraints.
- Memory recall: Without prompting, the system surfaced a previously stored rule: CLI commands need a non-interactive fallback for CI environments. This was a decision made in a different session. The engineer didn't have to remember it.
- Design review: The system reviewed the requirement, then reviewed the proposed design against the requirement. Two separate passes.
- Implementation with progress tracking: As tasks completed, the planning document updated automatically.
- Verification: The implementation was checked against both the requirement document and the design. Not vibes-checked. Structured verification.
- Test generation: Tests were written against the requirement, not the implementation. This is a critical distinction β it catches drift.
- Code review: A final review pass before PR creation.
Total time from idea to PR: under 30 minutes. Total output: requirement doc, design doc, planning doc, implementation, tests, review artifacts. And the engineer's contribution was: intent-setting, one product decision (keep v1 simple, flat list is enough), and final review.
What Still Needs You
It's tempting to over-claim here. A workflow system doesn't replace engineering judgment. It specifically shouldn't try to.
The decisions that require a human remain exactly the same: what to build, which trade-offs to accept, when "good enough" is actually good enough, what to deprioritize for v1. These are product engineering decisions that depend on context the AI doesn't have β business constraints, team dynamics, user feedback, architectural vision.
What changes is the surface area where human judgment is actually needed. When the workflow system handles context persistence, phase transitions, and verification, the engineer gets to spend cognitive energy on the things that actually require it.
There's also a risk management angle here. AI-assisted workflows feel productive until they're not. The code ships, the velocity looks good, and then you realize the implementation has been drifting from the requirements for three features. Automatic verification doesn't just save time β it's a forcing function that makes quality degradation visible before it compounds.
The Engineering Insight
The real insight from watching this pattern evolve is that the value of AI in engineering isn't primarily about code generation speed. It's about making workflow discipline sustainable at velocity.
Without AI, good workflow discipline (requirement review, design review, test-first, verification) is expensive. Teams skip it when under pressure. It requires individual discipline to maintain consistently. It doesn't scale.
With a well-designed AI workflow system, discipline becomes structural. Verification happens because the system makes it happen, not because the engineer remembered to ask for it. Memory persists because it's stored, not because the engineer re-explains it. Phase transitions happen because the skill triggers them, not because someone checked the checklist.
That's the actual unlock. Not "AI writes my code." But "AI makes my team's engineering practices consistent at a speed that wasn't previously possible."
If your current AI setup mostly helps you write code faster but still makes you carry the workflow in your head β the architecture, the verification steps, the context between sessions β that's the gap worth closing next.
Reference: This post was inspired by Hoang Nguyen's original article on how his AI workflow evolved from prompts to a full workflow system, and his open-source project AI DevKit.