Utopia vs Reality
My First Two Weeks with Kiro: Spec-Driven Development, AI Harnesses, and the Myth of Interchangeable Models
Spec-Driven Development (SDD) sounded like a promising concept: a structured bridge to transition from raw "vibe coding" into something predictable, robust, and engineering-grade.
I brought Kiro into a mature Python codebase with over 100 modules, complete with a fully generated code graph and project wiki.
Here is what happened when theory met reality.
The SDD Protocol vs. Reality
For my first fully autonomous task, I decided to play strictly by the book.
Requirements review: Checked. Clear, well-structured, aligns with the prompt.
Design phase: Checked. Looks solid.
Tasks definition: I skimmed past this step without reading deeply. After all, if requirements and design are validated, tasks should be a mere formality... right?
The goal was straightforward: build a lightweight API to compute key metrics from existing database tables to feed a front-end dashboard.
300 manual allow prompts later—despite setting up global and project-level permission rules—the agent finished.
Time to test.
It crashed immediately.
Realizing I had left model selection on automatic mode, I reset, brought back familiar tools, and forced Claude Opus5 (my faithful buddy)
Round two: Same prompt, but this time I inspected the task list carefully. Sure enough, several critical tasks specified in the requirements were missing. I corrected the plan and started the pipeline.
Oddly enough, I still faced 300 authorization requests despite the auto settings. Worse, there was zero self-correction during code generation, and no pytest runs took place—even though test tasks were explicitly defined in the spec.
The build completed. It ran, but the calculated metrics were flat-out wrong.
I ran my custom multi-agent PR review skill against the codebase: 10 critical errors, 5 medium, 5 low.
Next, I tested OpenAI’s high-tier stack.
Still no real-time self-correction. It followed tasks blindly like an obedient executor, never questioning its own output. It ran, felt slightly better, but my PR review still caught 6 critical errors and 1 medium issue.
Returning to Claude Code
Frustrated, I reverted to Claude Code running on Opus. Same task description, no SDD scaffolding, no rigid task lists.
The contrast was stark. Claude Code moved forward, backtracked, cross-checked against my initial prompt, asked clarifying questions when ambiguous, wrote explicit assert statements, ran pytest repeatedly, and consumed an eye-watering amount of tokens.
Get Workworkwork Fotsa’s stories in your inbox
Join Medium for free to get updates from this writer.
Result: The API worked seamlessly, the KPIs were accurate, and my PR review returned just 1 low-severity finding.
I tried the same benchmark across OpenCode with various model/skill combinations (Opus, openAI sol, Qwen 7 Coder).
The results were consistently disappointing for what should have been a routine database-to-API transformation.
The Myth of Interchangeable Models
This isn’t a fan letter to Claude. The same principle applies to OpenAI’s native tooling, Qwen’s specialized harness, or proprietary developer environments: the harness and the model are co-designed. They are built around specific model behaviors, failure modes, and prompt sensitivities.
Reading recent papers on OpenMCP, local agent architectures, DeepSeek’s open-source harness, and the 300+ agent frameworks popping up everywhere reminded me of a t-shirt design contest I once entered. One submitted design was titled Utopia vs. Reality.
The narrative being pushed today is that the harness is the real product, and underlying models are cheap, interchangeable commodities.
That is false.
It’s the same myth as the "Open Web." Just this week, I had to build two web scrapers for a client whose vendor provides no API—just raw Excel files behind SSO and Multi-Factor Authentication. The twist? Those Excel files only contain half the data needed to actually work.
What is genuinely safer or more efficient? Giving 50 employees full access credentials so they can manually copy-paste incomplete data to do their jobs, or building an API?
We live in locked ecosystems while pretending open standards are the norm.
Generalists vs. Specialists
We are locked in, yet we pretend abstraction layers fix everything. If you needed heart surgery, would you hire a general practitioner because they use a standardized scalpel framework, or would you go straight to a specialist cardiothoracic surgeon?
- My verdict after two weeks: I’m going to spend a week writing custom hooks (pre-tool, pre-commit, validation guards) for Kiro. It might be able to handle basic UI scaffolding and boilerplate reporting.
- But for complex mathematical algorithms, NP-hard optimization problems, heuristics, and delicate code architectures where a single micro-decision can shatter the entire system? I’m staying with Claude Code.
It understands its model’s weaknesses and human blind spots. It adapts. It isn’t afraid to scrap an hour of work if it hits a dead end. It brainstorms with me and calls me out when my design is flawed. And when I tell it, "That’s my call, if I fail I fail," it respects the boundary and executes.
Yes, the project wiki is long. Yes, context windows get stuffed with thousands of tokens. Yes, the dependency graph looks like a cubist painting. - And yes my dev are like dancing with an elephant on a tiny, fragile spider web, any nose moved have a countermove on another point.
But we are still very far from truly open AI, open web, or plug-and-play agents.
These agentic systems only work when there is complete communication transparency, strict access boundaries, and a deep, honest understanding of each model’s limits.
In a world where raw data remains the rarest, most expensive asset despite its overabundance, how do we bridge the gap between Utopia and Reality?
