AI made it easy for me to get a feature started.
It did not make the feature finished.
I kept seeing the same failure pattern. I could prompt an AI tool, get code quickly, and feel fast for a moment. Then the real work started. I had to debug unclear requirements, missing edge cases, and design decisions that should have been made before implementation.
That was the shift for me.
The problem was not that the AI could not code. The problem was that I was asking it to make product and design decisions while coding, then treating those decisions like implementation bugs.
Now I do the opposite. Before implementation, I do research, proposal, design, specs, and a task list. I started using OpenSpec to make that workflow real inside the repo instead of keeping it in my head or in chat history.
What Changed In Practice
Before:
- idea
- ask AI to build it
- inspect the result
- notice gaps
- rewrite prompts
- debug behavior
- discover missing scope in the code
After:
- research the problem
- write the proposal
- write the design
- define the specs
- break the work into tasks
- implement with AI against that context
This looked slower at first.
It was faster by the time the feature was actually stable.
The gain did not come from typing less. It came from doing fewer rounds of rework.
The First Real Artifact
The first useful thing about OpenSpec is not the branding. It is that the planning layer becomes visible.
The setup is simple:
npm install -g @fission-ai/openspec@latest
openspec init
From the OpenSpec repo, that first step scaffolds a file-based workflow into the project. The important part is what it creates:
openspec/
changes/
specs/
AGENTS.md
That small file tree changed how I worked with AI.
Before, the context lived in prompts and memory. After, it lived in files that could survive across sessions, agents, and revisions.
Why This Improved Delivery
The main benefit was not better prose in planning documents.
The main benefit was that AI had less room to guess.
Research forced the problem to be clearer. Proposal forced the change to be scoped. Design forced the key decisions earlier. Specs forced expected behavior to be written down. Tasks forced the work into smaller units.
By the time implementation started, the AI was no longer inventing half of the feature while coding it.
That changed debugging too.
More of the debugging became real implementation debugging. Less of it was hidden product thinking that had arrived too late.
A Simple OpenSpec Example
The easiest way to show the difference is with a small feature.
Say I want to add profile search filters by role and team.
In OpenSpec, I would move through the change step by step instead of jumping into code.
- Explore the change
openspec:explore Add profile search filters by role and team
- Create the proposal
openspec:proposal Add profile search filters by role and team
That creates a change folder with the planning artifacts for the feature.
- Apply the change
openspec:apply add-profile-filters
- Validate the result
openspec validate add-profile-filters
- Archive the change when the work is done
openspec archive add-profile-filters --yes
That is the real difference.
The AI is not being asked to define and implement the feature in one jump. It is being asked to move through proposal, validation, implementation, and archive as separate steps.
Other Solutions People Use
OpenSpec is not the only answer.
I found a few other patterns people use:
- Claude Code supports a lighter plan-first workflow inside the session. It is faster to start, but the planning is less durable.
- Shape Up is a strong manual shaping method. It improves problem framing, but it is not built around AI execution artifacts.
- Spec Kit is close to the same category as OpenSpec. It shows that spec-driven AI coding is becoming a broader pattern.
- Kiro specs show the same workflow moving directly into the IDE.
The useful comparison is not tool versus tool.
It is lightweight session planning versus durable file-based planning.
When I Would Not Use This
I would not use this workflow for tiny fixes.
If the task is obvious, local, and low risk, the overhead is not worth it.
This approach starts paying for itself when the feature has enough moving parts that you already expect back-and-forth with the AI.
That is usually the signal that the real risk is not coding speed. It is missing decisions.
Rule Of Thumb
If I expect the AI to ask implied questions during implementation, the feature is probably large enough to deserve research, proposal, design, specs, and tasks first.
FAQ
Why stop building features with AI right away?
Because fast code is not the same as a finished feature. Writing the spec first helps define scope, decisions, and edge cases before implementation starts.
What was going wrong before?
AI was generating code before the feature was clearly defined. That led to missing requirements, unclear behavior, and more rework later.
What changed in your workflow?
Instead of jumping straight into code, the process now starts with research, proposal, design, specs, and tasks, then AI is used to implement against that context.
What is OpenSpec?
OpenSpec is a tool that helps turn planning into files inside the repo, so the context is visible, reusable, and easier for AI to follow.
Why is this approach better?
It reduces guesswork. AI works better when the feature is already defined, which means fewer prompt rewrites and less debugging caused by missing decisions.
Does this make development slower?
At first, yes. But it usually makes delivery faster overall because there is less back-and-forth and less rework before the feature becomes stable.
Should every task use this workflow?
No. It is most useful for features with enough complexity that AI would otherwise need to guess during implementation. For tiny fixes, it is usually not worth the overhead.
Takeaway
AI did not remove the need for feature definition.
It made missing definition more expensive.
I am not faster because AI writes code faster. I am faster because I ask AI to build against a better-defined change.