The short version
Two software architects at Zeiss (Stefan and Bastian, digital customer experience platform) showed how they moved a real Java microservice from AI-assisted coding to a spec-driven agentic workflow: a spec.md with objective, tech stack, executable commands, boundaries, and given-when-then success criteria, run end-to-end with Claude Code and Addy Osmani's agent skills, no human approval between plan and implementation. Then they went further: they threw the whole codebase away and had the agent regenerate it from the spec, reaching 80% match on the first shot and 90% after manual tweaks. A Java-to-Go rewrite of the same kind managed only 60-70%, because the agent lacked their Go guidelines and templates. They also let an agent loose on replicated infrastructure; it escaped the guardrails and destroyed the database. The idea worth stealing: the spec is not a requirements document, it is an operating manual for the agent, and its success criteria must be executable so the agent can verify itself.
The talk
Zeiss is not just glasses: semiconductor manufacturing, industrial quality, medical technology, and consumer markets. The speakers work on the digital customer experience platform, a microservice estate behind the company's web shops that has grown over five years. Their starting point matters: they had already done the platform engineering homework. Backstage as a developer portal, Soundcheck for standards checks against repositories, markdown documentation, templates and golden paths, central ADR repositories per domain. The talk's argument is that this homework is exactly what makes agentic workflows possible, because the agent inherits the guardrails the platform already enforces on humans.
They frame three maturity levels: vibe coding (unstructured, not a reliable delivery model), AI-assisted development (the AI helps, the human still orchestrates), and agentic workflows (the human describes intent and guardrails, the agent executes and verifies itself). The move to level three is a triage decision, not a blanket one: high-criticality services keep human attention, and the automation experiment targets a low-criticality service, a webhook translator that maps product data changes from their PIM/ERP systems into the platform.
The approach
A spec is an operating manual for the agent
Their spec.md contains the objective (system intent), the tech stack, the executable commands to compile, test, and verify, the project structure, coding guidelines, testing strategies, boundaries (what the agent may modify, read, or must not touch), and success criteria written as given-when-then scenarios the agent can execute against its own work.
Extract the spec from the code you already have, but at feature level
They reverse-engineered the existing service (built from a Backstage template, clean architecture) using its backlog, its ADRs, and interviews with the developers, and judged the extracted behavior about 90% of the way there. Warning they give: a forensic extraction faithfully captures your tech debt too, so they extract behavior at feature level and leave the implementation detail behind.
Don't build your own harness, adapt a public one
They use Claude Code plus Addy Osmani's agent skills, tweaked so /build auto runs the whole loop (spec, plan, implement, test) without stopping for plan approval. Added MCP servers: Headroom for token compaction, Serena and a codebase-memory tool for semantic code search, a repository indexer that builds a graph, and Centrox (name as heard in captions) to score architecture quality against thresholds. They explicitly recommend against starting from scratch with your own markdown agent: you just replay every mistake the industry already made.
Verification is what makes autonomy safe
The agent's output is checked by static analysis, tests, API linters, and security checks, and the given-when-then scenarios end up coded into the tests. In their demo run (a new SLO: reject request payloads over 1 MB with a 413), the agent updated the spec, planned, implemented a request size filter, wrote the tests, and fixed its own implementation, in a run over 20 minutes long. The pipeline currently stops where the PR would be created; everything after that stays behind human approval.
Humans own intent, agents own execution
Their summary of the division of labor: humans define system intent, functional and non-functional requirements, guardrails, and ADRs. The AI owns code, tests, CI/CD pipelines, and infrastructure artifacts, with one explicit exception: infrastructure as code does not run without a human gate.
The regeneration experiments
Instead of patching security fixes into old code, they tried deleting the entire codebase and regenerating it from the spec in the same language: 80% match on the first shot, 90% after manual tweaks. A Java-to-Go rewrite reached only 60-70%, because the agent had no connection to their Go coding guidelines and template blueprint. Their read: same-language regeneration is close to feasible for small contained microservices; cross-language needs the guardrail artifacts ported first.
The numbers
- ~90% of the existing service's behavior recovered when extracting the spec from backlog, ADRs, and developer interviews
- 80% match regenerating the service from spec on the first shot, 90% after manual tweaks
- 60-70% match on a Java (Spring Boot) to Go rewrite attempt
- One full autonomous run (spec to tested implementation): over 20 minutes
- Demo change: reject payloads over 1 MB with HTTP 413
- Platform context: five years of growth, central ADR repos per domain
Caveats
This recap is built from auto-generated captions, so names and figures deserve suspicion (the architecture-scoring tool rendered as "Centrox" is a guess, and the percentages are the speakers' own claims with no external write-up to verify). The speakers name their own failures: an agent trial on replicated Kubernetes infrastructure escaped the guardrails and destroyed the database, which is why infrastructure stays behind a human gate. They also learned that skills are not guaranteed to execute, so hard constraints belong in hooks (pre-tool-use), where they say Claude Code is ahead of other harnesses. On token costs for regeneration they stay vague: "interesting" compared with the cost of a manual migration, but no bill is shown. And the whole story rests on years of prior platform engineering investment; without Backstage, golden paths, ADRs, and linters in place, there is nothing for the spec to point the agent at.
Why it matters here
Most spec-driven-development talks stop at "write better specs." This one is concrete about what a spec must contain for an agent to act on it (executable commands, boundaries, executable success criteria), and it is honest about the two-sided result: same-language regeneration nearly works, cross-language fails exactly where the guardrail artifacts are missing. That failure is the interesting part of the data: the missing 30-40% traces to guardrail artifacts the agent could not see (Go guidelines, template blueprints), rather than to model capability. Anything your team knows that only exists in people's heads or wikis is invisible to the agent and shows up as a percentage drop. The reskilling point lands too: someone has to build and maintain these harnesses, and that work looks like platform engineering, not prompting.
Join the discussion
Question for the channel: Zeiss extracted a spec from an existing service and got a 90% behavioral match regenerating it, and they now argue regeneration could beat patching for things like security fixes. Would you trust a regenerated low-criticality service into production if your test suite and given-when-then scenarios passed, or is the missing 10% exactly the part your tests don't cover?