A lot of people still talk about AI coding workflows as if the main story is code generation.
That was true for me at first too.
Six months ago, my AI workflow was already useful. I had reusable commands, predefined templates, and a decent setup across tools like Cursor, Codex, and Claude Code. It was enough to help me generate code faster and reduce repeated prompting.
But after using it every day, I realized the real bottleneck was not code generation.
It was workflow orchestration.
I was still the one remembering what to run next. I was still dragging context from one step to another. I was still forcing verification when the AI tried to jump too quickly into implementation.
That is what changed the most while building AI DevKit.
The workflow evolved from reusable commands and templates into:
- skills
- memory
- auto-triggered behavior
- automatic verification
A recent feature made that difference very obvious to me.
I was building interactive skill selection for ai-devkit skill add.
Previously, if you wanted to add a skill, you had to know the exact skill name. If you did not know what was available, you had to search first, copy the name, then run the add command.
So I wanted this instead:
If the user runs ai-devkit skill add without a skill name, show an interactive multi-select list and let them choose.
I opened Codex and gave one sentence of instruction.
That was the only prompt I gave.
From there, the dev-lifecycle skill took over and moved through eight phases:
- new requirement
- review requirement
- review design
- execute plan
- update planning
- check implementation
- write tests
- code review
The actual feature flow took around 30 minutes.
The whole session, including docs, verification, tests, and final cleanup, was under an hour.
That still feels a bit wild to me.
What impressed me was not just that AI wrote code.
It was that one prompt kicked off a structured workflow that carried context forward and left behind something much closer to a complete engineering trail:
- requirements
- design
- planning
- implementation
- verification
- tests
- review notes
A few details stood out:
- Memory was actually useful: The workflow pulled in an old rule I had stored months earlier: CLI commands should have a non-interactive fallback for CI environments. I had forgotten that I even stored it.
- The workflow could challenge itself: The review phases were not just decoration. They could loop backward if something important was missing instead of blindly moving forward.
- Verification mattered more than I expected: The check-implementation phase found gaps between the code and the earlier design. Later, I still had one failing test assertion to fix manually. The workflow did not remove responsibility, but it caught structural problems much earlier.
- I still drove the product: I kept the first version simple, avoided over-designing the selection UI, and made the tradeoff calls myself. The workflow drove the process. I still drove the decisions.
That is the part I care about now.
My old AI workflow could generate code.
My current workflow can carry context, verify work, and keep me from repeating myself.
That is the real upgrade.
If you want the full breakdown, I wrote it here:
How my AI workflow evolved from prompts to workflow – Codeaholicguy
About six months ago, my AI workflow was already useful. I had reusable commands. I had predefined templates. I had a decent setup in Cursor and later Claude Code and Codex. It was enough to make A…
codeaholicguy.com
If you want to try the setup:
npx ai-devkit@latest init
npx ai-devkit skill add codeaholicguy/ai-devkit dev-lifecycle
npx ai-devkit skill add codeaholicguy/ai-devkit verify
npx ai-devkit skill add codeaholicguy/ai-devkit tdd
npx ai-devkit skill add codeaholicguy/ai-devkit debug
Then open your AI editor and ask it to use the dev-lifecycle skill on a real feature.
Top comments (0)