I like that Spec Kit exists. That may sound inconvenient, because I am building Software Dark Factory and the lazy internet move would be to turn this into a dunk. I do not think that is honest. Spec Kit is a sensible reaction to a real problem.
Vibe coding got people into trouble because vague intent plus powerful generation creates confident software-shaped output. The danger is not only bad code. It is bad code wrapped in enough structure to look persuasive. Files appear. Tests appear. A feature appears. The agent sounds sure. The human gets tired.
So of course GitHub pushed toward specifications. Write down the principles. Clarify the feature. Create a plan. Break it into tasks. Then implement. That is better than magic-prompting a feature into a repo and pretending the agent has product judgment, architectural taste, and local context by default.
But the expensive part was never the licence.
Spec Kit is open source. It is free upfront. Good. But the operational cost of a delivery workflow is not measured by the tool’s price tag. It is measured by the drag it creates, the mistakes it hides, the review confusion it causes, and the confidence it manufactures before the work has earned it.
This is where I get nervous about the current wave of spec-driven AI workflows. Not because specs are bad. Specs are useful. They force intent out of someone’s head. They give the agent a target. They make review better than comparing a diff against a half-remembered Slack thread. The danger is treating the spec as governance.
It is not.
Real software is shaped during implementation. You never know everything upfront. The codebase has opinions. Tests encode old promises. Product copy makes commitments the spec forgot. A helper already exists. A route is named differently. A user state is messier than the happy path. One implementation detail can change what the right solution should be.
This is why agile won. Plans go stale once real work starts. AI does not repeal that. AI accelerates it. When an agent can create more code faster, the feedback loop needs to get tighter, not looser. The team needs smaller slices, clearer acceptance criteria, faster verification, and better evidence about what happened during the work.
That is the distinction I care about with Software Dark Factory. SDF is not anti-spec. It treats specs as intent. Intent matters. But proof lives somewhere else.
Proof lives in the governed delivery record: the prompt, the run log, the preflight, the acceptance criteria, the playbooks applied, the verification outputs, the risk and confidence notes, the AI usage and model awareness, the limits, and the reviewer-ready summary. Proof lives in whether the slice stayed aligned with the spec, the codebase, the tests, the risks, and what was learned during implementation.
In my own work, I want the agent to be useful without pretending the agent is sovereign. That is why SDF’s current posture is assisted, operator-reviewed, and evidence-backed. It makes AI-assisted delivery reviewable, auditable, and adaptive. It is not a claim of automatic approval, automatic merge, automatic deploy, or guaranteed correctness.
There is a line in the operating model that matters more than it first appears: `automatic_execution_permitted: false`. That is not anti-automation. It is pro-trust.
The commercial problem is not “can we make an agent do more?” We can. The problem is whether the people responsible for the software can understand what the agent did, why it did it, what it checked, what changed along the way, and where the remaining risk sits.
Spec Kit makes the upfront document stronger. Software Dark Factory makes the delivery loop safer. Those are related problems, but they are not the same problem.
If your team is stuck in vibe coding, a spec-driven workflow is probably an improvement. Write down intent. Make the agent plan. Stop treating a prompt like a product brief. But do not stop there.
The harder work is building a loop that can survive contact with the codebase. A loop that expects plans to change. A loop that captures evidence during implementation instead of relying on confidence at the start. A loop that helps a reviewer inspect the slice without becoming an archaeologist.
That is the agile answer to AI-assisted delivery: smaller slices, faster feedback, better evidence, and human gates where they belong.