A colleague recently gave an internal presentation about GitHub's Spec Kit and spec-driven development.
It was a good presentation.
The demo was practical. Claude Code and Cursor were used as the coding agents. The workflow showed how you can take an idea, turn it into a specification, create a technical plan, break that plan into tasks, and then let the agent work through the implementation.
At the end, the presenter asked our CTO what he thought.
The answer was approximately:
"It's cool, but I think we're going to go with agentic development instead."
There was a short silence.
Because we had just spent the presentation looking at...
agentic development.
Wait, isn't Spec Kit agentic?
Yes.
That's what made the answer so strange.
Spec Kit isn't competing with Claude Code, Cursor, Copilot, or other coding agents.
It gives those agents a process.
Instead of:
Build this feature.
and hoping the agent correctly reconstructs all the missing context, the workflow becomes something closer to:
idea
↓
specification
↓
technical plan
↓
tasks
↓
agent implementation
↓
validation / convergence
The agent is still doing the work.
In fact, that's the whole point.
You're giving an autonomous or semi-autonomous coding agent better inputs, clearer boundaries, persistent artifacts, and checkpoints where a human can review what is happening.
You can absolutely disagree with that approach.
Maybe specifications create too much overhead.
Maybe your team works on changes small enough that a formal planning phase isn't useful.
Maybe you want agents to operate with significantly more autonomy.
Maybe you have a completely different orchestration model.
Those would all be interesting discussions.
But:
"We won't use this because we're going agentic."
isn't really one of them.
It's like watching someone demonstrate Kubernetes and responding:
"Looks interesting, but we're going with containers."
The actual antipattern
The funny part isn't that someone didn't understand Spec Kit.
Nobody understands everything.
Especially now.
The AI development ecosystem is moving ridiculously fast. New agent frameworks, protocols, models, IDE integrations, orchestration patterns, and methodologies appear constantly.
A CTO not knowing the details of one of them is completely normal.
The antipattern is something else:
Feeling that being the most senior technical person in the room means you must always have an answer.
When you don't understand something, there are two options.
You can ask:
"Help me understand how this differs from the agentic approach we're considering."
Or:
"Where does the human stay in the loop here?"
Or simply:
"I don't know Spec Kit well enough yet. Walk me through how it fits into an agent-based workflow."
All three are good questions.
And none of them make a technical leader look weak.
Quite the opposite.
Engineers can tell
Trying to bluff through a technical discussion has an unfortunate property:
The people you're bluffing are usually technical too.
They know.
The moment a confident answer reveals that the underlying concept wasn't understood, something changes in the room.
And it's not just about that one topic.
People start wondering:
If this decision wasn't based on understanding the thing we just demonstrated...
what are the bigger technical decisions based on?
That is where the real damage happens.
A CTO doesn't need to personally know every framework.
A CTO does need engineers to trust the reasoning behind technical direction.
And trust is surprisingly easy to lose.
"I don't know" is an underrated leadership skill
One of the strongest things a technical leader can say is:
"I don't know."
Followed by:
"Explain it to me."
That creates a completely different engineering culture.
It tells people that learning is more important than appearing knowledgeable.
It tells senior engineers that their expertise is actually wanted.
It makes technical discussions about finding the right answer rather than defending hierarchy.
And perhaps most importantly, it makes it safe for everyone else to admit when they don't know something either.
If the CTO has to pretend to understand everything, eventually everyone below the CTO learns to do the same.
That's not a great environment for engineering.
Agentic development needs more structure, not less
There's another interesting part of this story.
As coding agents become more capable, the need for good specifications doesn't disappear.
Arguably, it becomes more important.
When a developer writes every line manually, misunderstandings are discovered gradually during implementation.
When an agent can produce thousands of lines of code in minutes, it can also implement the wrong interpretation incredibly efficiently.
The bottleneck starts moving.
Less:
How quickly can we write this?
More:
Did we clearly define what should be built?
Did the agent understand the constraints?
Can we review the decisions it made?
Can we verify the result?
That's exactly why specifications, plans, acceptance criteria, checkpoints, and review workflows are becoming interesting again.
Agentic engineering doesn't make engineering discipline obsolete.
It changes where that discipline needs to live.
The lesson
This isn't really a story about Spec Kit.
And it's not about whether Spec Kit is the best way to build software with agents.
It's about technical leadership.
You don't lose credibility because you haven't heard of something.
You don't lose credibility because an engineer knows more about a particular technology than you do.
You don't even lose credibility by saying:
"I don't understand this yet."
You lose credibility when everyone in the room realizes you don't understand something...
while you're pretending that you do.
A question might cost you five seconds of looking less than omniscient.
A confident non-answer can cost you the trust of every engineer who heard it.
This is part of my Professional Antipatterns series: stories about the strange ways software organizations sometimes manage to make engineering harder than it needs to be.
Originally published at:
https://blog.lezli01.is-a.dev/blog/professional-antipatterns-cto-spec-kit/
Top comments (0)