// post

· 5 min read

Professional Antipatterns: the CTO who chose agentic development over agentic development

// A colleague presented GitHub's Spec Kit and spec-driven development with Claude Code and Cursor in an internal workshop. The CTO's verdict was that we would go with agentic development instead. Why answering a topic you do not know with something irrelevant costs a leader more than asking a question would.

// contents
  1. What happened
  2. Why the answer was a non sequitur
  3. Why it does more damage than silence
  4. What a good answer looks like
  5. Why this is an antipattern

A colleague ran an internal workshop on spec-driven development. I was in the room as one of the audience. The presentation was very good, and the question that closed it was simple. The answer was not.

What happened

The presenter showed GitHub’s Spec Kit as a practical way to do spec-driven development (SDD), and ran it live with Claude Code and Cursor as the agents. It was well prepared, the flow was clear, and the demo did what it was supposed to do.

At the end the presenter turned to the CTO and asked how he liked it. His answer was something like this: it is cool and all, but I think we are going to go with agentic development.

The presenter stood there in shock. So did the rest of us. Everyone in the room understood that the answer had nothing to do with what had just been shown, and nobody started explaining why. We just stood there, surprised.

Two-panel comic. Left: a developer with a lanyard stands in front of a whiteboard listing Spec-kit benefits and a Spec, Design, Build flow, asking a CTO in sunglasses and a gold CTO badge "So what did you think of Spec-kit?" Right: the CTO, grinning in front of an Agentic Development buzzword diagram, answers "It's cool, but I think we're going with agentic development instead of this," while the developer scratches their head thinking "How does that even make sense?"
Obviously AI generated, sunglasses included: the moment, roughly as it felt from the audience.

Why the answer was a non sequitur

To see why the room went quiet, it helps to know what Spec Kit actually is. Its own README calls it “an open source toolkit that gives AI coding agents structured processes, reusable templates, and documented outcomes.” It is not an alternative to coding agents. It is a process that runs inside one.

The SDD flow is a short sequence of skills you invoke in the agent’s chat, not in a terminal. A constitution is written once per project to fix the principles the agent must follow. Then, per feature, the agent writes a specification of what to build and why, turns it into a technical plan, breaks the plan into tasks, and implements them. The README’s own quickstart looks like this:

/speckit-constitution Create principles focused on code quality, testing, and maintainability.
/speckit-specify Build a photo organizer with albums grouped by date and a tile preview of each album.
/speckit-plan Use Vite with vanilla JavaScript. Keep images local and store metadata in SQLite.
/speckit-tasks
/speckit-implement
/speckit-converge

Every one of those steps is executed by the agent. The README says to repeat implement and converge until the converge step reports Converged. Some agents invoke the same steps in a dotted form, such as /speckit.specify, but the flow is the same. And the toolkit is deliberately agent-agnostic: specify init takes an integration key, with Claude Code (claude) and Cursor (cursor-agent) among the supported ones, which is exactly the pair the presenter used.

So “we are going to go with agentic development instead” answered a question nobody asked. SDD with Spec Kit is agentic development. What it adds is structure: a written spec and plan the agent works against, and that a human can review before code exists. A reasonable objection would have been about that structure, whether it is worth the overhead for our kind of work. The answer we got implied the speaker did not know agents were involved at all.

Why it does more damage than silence

I keep coming back to one question: why is it so important for someone in a position like CTO to look like they know everything? I believe the real value of that seat is the opposite. When you do not know something, you ask.

Answering with something irrelevant does not hide the gap. It announces it, to a room of engineers who can tell immediately, while you remain the person who makes the decision. Two things happen at once. The presenter, who put real work into a good session, learns that the work was not engaged with. And everyone else starts quietly questioning the direction the company is heading, because if the answer to a clear demo is a category mix-up, what are the bigger technical decisions based on?

A question costs a few seconds of looking less than omniscient. A confident non-answer costs credibility with every engineer who heard it.

What a good answer looks like

The fix isn’t a CTO who has studied every tool. It’s a CTO who asks. Nobody expects a CTO, a director of engineering, or anyone in a similar role to be the know-it-all in the room. That is what the rest of the room is for. Any of these would have kept the conversation honest:

  • The fit question: “How does this fit with agents running more autonomously? Where does the human review step sit?”
  • The honest one: “I don’t know this area well. Walk me through where it fits compared to how we use agents today.”
  • The cost question: “What does writing a spec and a plan first cost us per feature, and what does it save later?”

Each one engages with what was shown, gives the presenter room to go deeper, and lets the decision maker learn in public at no real cost. Take your place in the discussion as a participant. Learning and asking is never shameful, and in a technical leadership role it is most of the job.

Why this is an antipattern

Answering a topic you do not understand with a confident, irrelevant verdict, instead of asking a question, is an antipattern because the intent is to protect authority and the effect is to spend it. The intent is to look decisive and informed in front of the team. What it actually incentivizes is bluffing over learning, and it teaches everyone watching that the honest move, admitting what you do not know, is not safe even at the top. The damage is concrete: the person who did the work is deflated, the team’s morale drops with them, and the engineers who saw the gap now discount the technical direction coming from the one person whose job is to set it.

What else I build and think about is collected at lezli01.is-a.dev.

// thoughts? reply by email

// comments

// comments load as you scroll here. They live in GitHub Discussions; sign in with GitHub to join in.

← all posts