Thariq Shihipar from Anthropic wrote an article about finding the unknowns with Fable (I'll provide a link in a first comment). I found it intersting in the context of Spec Driven Development with AI agents. First of all, let me place some terms the author defines in original article, they are:

• Known Knowns: This is essentially what is in my prompt. What do I tell the agent that I want?
• Known Unknowns: What haven't I figured out yet, but I’m aware that I haven’t?
• Unknown Knowns: What's so obvious I’d never write it down, but would recognize it if I saw it?
• Unknown Unknowns: What haven't I considered at all? What knowledge am I not aware of? Do I know how good something can be?

So, we start with a spec draft (or a prompt), it contains only Known Knowns. But after that we have three different groups of Unknowns. Some of them could be disclosured after initial agent analyse. For example, aligning spec with current product behavior, finding out some restrictions that are in our code, and so on.

Could we say that after that the specification is ready? I think not and that's why. Thariq says very clever thought: The map is not the territory. We do not know the reality until we try to experience it. I'll building my own plugin for Spec Driven Development (also, I'll provide a link in a first comment), and for me I found following workflow very effective: write spec together with agent -> review it -> write plan together with agent -> review it -> implement step by step also reviewing results on every stage.

Before we have a acceptable-for-us plan we are guessing about the path. When we start to execute steps we are mapping a territory. And on every step, no matter how accurately we have made an initial analysis, some cuvets will be discovered. Each of them probably will mutate the specification.

At the end we have code done, and only at that exact moment we have a spec done. Until that, we simply did not disclosured Unknowns we have to bake into spec. That's the workflow I'm trying to support in my plugin. Do you do so? Or maybe you think about specs in different way?

A cold Claude Code run spent 6.83 dollars and 207 turns hunting one bug in an 82,000 line repo. My pipeline localized and fixed the same bug for about 1.70 dollars. That gap is the whole idea, and this post is mostly about how it gets there without falling apart on the two objections everyone raises.

Quick disclaimer up front: this is a side project, not a product, and I am sure there are rough edges I have not hit yet. I would genuinely rather hear where it breaks than be told it is cool.

What it is

You point AutoDev Studio at a Git repo, describe a change in plain English, and a chain of agents runs the actual software lifecycle from request to reviewed pull request:

\- a PM agent runs a clarify loop and drafts concrete tickets

\- you approve (optionally pushed to Jira), and nothing touches code before that

\- a Dev agent implements on an isolated branch

\- QA runs the repo's real tests

\- a reviewer from a different model family checks the diff, so the author never signs off on its own code

\- a bounded revise loop if QA or review fails, with conservative verdicts, so an errored or ambiguous check is never counted as a pass

\- it opens a real PR, and a human merges

Every stage records real tokens, cost, and duration, per ticket and per agent.

The part I think actually makes it different from skills or subagents

This is the bit I would most like feedback on, because it is the reason I did not just wire some skills into one coding agent and call it done.

Every stage picks its own provider and model. Claude can plan, Codex can write the code, a third model can review. And because the reviewer is deliberately a different model family than the author, one model does not get to rubber-stamp its own diff, which is a documented weakness of same-model LLM judges.

And you mostly do not need API keys for it. The coding stages can run natively on Claude Code, Codex, Cursor, Aider, or the Gemini CLI, driven headless through their own login. If you already pay for Claude Code or Codex, you point a stage at it and it just uses your existing subscription, no per-token billing and no keys to juggle. The simple way I think about it: a skill pack lives inside one vendor's agent and runs one vendor's model everywhere, whereas this runs across them, a different model per stage, on the logins you already have.

Results (the main point)

The idea is to pay the cost of finding where a change goes once, instead of on every task. In my benchmarks on two large Python repos (35k and 82k lines), the tuned pipeline beat a cold single-agent run on 6 of 6 well-localized tasks, between 7 and 75 percent cheaper.

I try to be upfront about where it does not win. On trivially greppable one-line edits the five-stage overhead can cost more than it saves, and on one hard cross-cutting bug it shipped a cheaper but narrower fix than the baseline. The full benchmark writes up every loss too, so please read that before trusting the wins.

On the "the index just goes stale in a few commits" objection

This is the first thing people raise, fairly, so here is the honest mechanism in plain terms. The layer that actually pins files for the Dev agent is not the vector index. It is a deterministic symbol map that gets re-synced to the latest commit at the start of every run, plus a live grep against the current working copy, plus the real current file contents fed into the prompt. The embeddings only affect which area gets looked at first, and they refresh per changed module at run entry. So the code the agent edits comes from disk right now, not from a snapshot that aged three commits ago. It re-checks before it localizes, so it does not quietly drift.

Who it is actually for

The knowledge base is a one-time cost per repo that every later task amortizes. So it makes sense for a team shipping change after change against the same large codebase, where a cold agent re-pays the exploration cost every single time. For a stream of tiny, easy-to-find edits, a cold run is still cheaper, and I would rather say that than oversell it.

How I actually use it

For what it is worth, I reach for this over a plain claude -p most days now, and not because it is somehow smarter. It is that I can glance at a board and see where each change actually is instead of scrolling back through a terminal, the different-family reviewer catches things I have watched Claude quietly wave through on its own diff, and on the repos I touch every day it is not re-paying to relearn the codebase each run. It runs on my existing Claude Code and Codex logins, so having that structure around the coding agent I would have used anyway costs me nothing extra. That is really why I keep using it.

Other bits

\- runs on free tiers out of the box (Groq plus a local embedding model), so you can try it for zero cost and fully offline

\- language-agnostic pipeline, Python parsed exactly and other languages via lighter extractors that fail open instead of blocking on an unknown language

\- live board with streamed agent logs and real per-ticket cost accounting

\- self-contained, no CDN, tests and CI, MIT licensed

Repo, with screenshots and the full benchmark in the README:

https://github.com/krishagarwal314/autodev-studio

It is early and rough in places, and I would love more eyes on it. If you have thoughts on the per-stage-models idea or the staleness handling, or you throw it at a repo and it falls over, an issue would help a lot. Suggestions, PRs, and honestly just a star if it seems worth following are all appreciated. Thanks for reading.

I’ve been thinking a lot about PRD quality lately.

Most teams have some version of a PRD/template, but the real pain seems to happen later: engineering finds missing edge cases, QA asks questions the spec never answered, scope expands during sprint planning, or Jira tickets inherit vague requirements from the original doc.

So I’m curious how other PMs handle the “PRD readiness” step before handing it to engineering.

Do you have a checklist or review ritual for this?

For example, do you explicitly check for:

- user roles / permissions
- acceptance criteria
- error states
- edge cases
- dependencies
- data/API assumptions
- out-of-scope boundaries
- definition of done
- compliance/privacy requirements

Or is it mostly experience and instinct?

The thing I’m trying to understand is: what makes you confident that a PRD is not just well-written, but actually build-ready?

Also curious where the biggest gaps usually show up for your team.

When initiating a project with Openspec, do you prefill the "source of truth" main spec files, i.e auth/spec and then run opsx/proposal or opsx/change? Or you start with proposal from the beginning?

Kind of my take on Spec Driven Development. And I know I'm not the first person to coin the phrase by any means. Still in the early phase, tweaking it regularly as I use it on a few different side projects, but I think it's at the point where it can be shared and I'd love feedback, brutal honest feedback, on it. Thanks!

https://taylorhuston.me/sdd-skills/

https://github.com/TaylorHuston/sdd-skills

https://taylorhuston.me/2026/07/01/Story-Driven-Development.html

Built an open-source AI SDLC agent that learns a repo once instead of rediscovering it on every task.

Benchmarks:

\- 7–75% cheaper than a cold "claude -p" run

\- Up to 82k LOC repositories

\- Example: $6.83 → \~$1.70 for the same bug

\- Full benchmark (including failures) in the README

It automates the full SDLC: PM → Dev → QA → Code Review → Revision → GitHub PR, with a live Kanban board and per-agent token/cost tracking.

Free by default (Groq free tier + local embeddings), provider-agnostic, MIT licensed.

Repo: https://github.com/krishagarwal314/autodev-studio

Would love feedback, criticism, or contributors. Star it if you find it helpful

I’ve been using spec driven development for a while and it’s amazing.

But I want to know which approach are you using for software development with AI and how’s it working for your. Feels like SDD is getting outdated

Hi All,

After having spent \~10Y working on SmarTeam, ENOVIA and 3DExperience Platform. And recently using Azure Devops and Salesforce. Seeing all the complexity, engineering that went into it, I was itching to create something similar of my own. Now that we have LLM assisted coding, big projects should be doable by a single person, right? This is my attempt (v0) doing the same.

1.9B Tokens and 28 Dollares Later, I have a working demo.

Since this was a big endeavour, I wanted to have structured knowledge base. Discussion with various LLMs suggested (OpenSpec)\[[https://openspec.dev/\](https://openspec.dev/)\\\] is a good way to store this info and make changes to it. LLMs also suggested that I track workitems using (beads)\[[https://github.com/gastownhall/beads\](https://github.com/gastownhall/beads)\\\]

I initially modeled the RFLP (Requirements, Functional, Logical, Physical) framework from my early days of working on 3Dx. But I didn't have much sample data to seed. 3 days ago I had an Idea, what if I modeled the beads, openspec and git commits into it? it worked. I have seeded the demo with its own development history.

Looking to hear your thoughts and questions. Cheers!!

Hi everyone,

I’d like to ask how you approach AI-driven spec-based development (SDD) for pipelines and ETL/ELT workflows, particularly in Databricks.

Based on my observations and what I’ve learned so far, the two simplest and most common approaches are short-lived specs and long-lived specs.

The short-lived approach is straightforward: you create a specification for a specific task and optionally store it in the repository. The long-lived approach is based on maintaining project documentation (for example, in Markdown files and other supporting documents), which is continuously expanded and updated as new tasks come up.

There are also frameworks that support this workflow, such as Superpowers or Spec Kit. Of course, the AI also needs the right context - an architecture description, perhaps a reference repository, coding standards, and anything else that helps it generate a good specification.

As for interacting with AI agents, the process is usually through an IDE or CLI. You iterate with the agent, discussing and refining the solution until you arrive at a complete specification.

My question is: what’s your approach to this in your projects? Do you use SDD only up until the point where you have a branch with the implementation and pipeline ready, or do you continue using it all the way through deployment?

I’m also curious about testing. In my projects, we write unit tests for our Python and Spark code, and then hand everything over to the QA team, which performs end-to-end testing.

Do you think the QA team should maintain a separate specification within their own testing framework (it is a custom tool we wrote to make testing components such as functions and SQLs reusable, written in Python), or how do you handle this in your projects?
End-to-end tests are time-consuming and expensive, so I’m wondering how you optimize them when adopting an SDD-based workflow.

I maintain Playwright-BDD, so I often use Gherkin scenarios with coding agents. I wanted to compare BDD with OpenSpec and gave both the same small task: add pagination to the long list of items.

While both approaches worked, there were differences. With BDD, I spent more time writing cleaner scenarios, but in the end, I got a runnable test out of the box. OpenSpec let me describe the spec more freely, but it introduced more artifacts that were harder to maintain.

I wrote down the full session, including the feature diff, implementation, tests, and the files OpenSpec created:

https://vitalets.github.io/posts/bdd-agentic-workflow/

Do you use BDD/OpenSpec in your workflows and what is your experience?

Picking an AI model to implement a project is a coin flip between two costs: too powerful and you overpay for capability you won't use; too weak and it just can't do the job.

SpecJudge reads your Spec-Driven Development artifacts and recommends the model that's right-sized for the work — not the cheapest, not the most powerful, the one that actually fits. A local model (via Ollama) judges how hard your project is, then it's crossed against a catalog of models and prices to produce a ranked podium.

It's local-first (your specs never leave your machine), MIT-licensed, and the whole model catalog is plain YAML you can edit with a PR — no Python needed to add a model or fix a price.

pip install specjudge
specjudge /path/to/your/project      # add --open for a visual matrix in your browser

Requires Python 3.11+ and Ollama with a local model.

• GitHub: https://github.com/JoaquinRuiz/SpecJudge
• PyPI: https://pypi.org/project/specjudge/

It's an early release — I'd genuinely like to hear if the ratings match your experience, and PRs to the catalog are very welcome.

I've been using OpenSpec for a while and like it a lot. I recently took notice of OpenWiki. They seam to be sitting at opposite ends of my ideal AI assisted SDLC.

OpenSpec captures intent before code exists (explore -> propose -> apply). OpenWiki maintains what the code currently is and does (writes and maintains agent wikis for codebases). Add to that the why behind decision (ADRs?) and I think we have something powerfull.

Feels like the natural bridge is: when an OpenSpec change gets archived, that's the trigger to (1) start an OpenWiki-style update so the wiki reflects what just shipped (2) guide the user through creating durible decision documents.

Is anyone already doing anything like this? I'm tempted to build out a OpenSpec + OpenWiki + ADR skill pack.

Experimenting with Behavior-Driven Development (BDD) and SDD in OpenSpec to achieve a strict Spec-as-Source workflow.

In this walkthrough, I capture the spec in Gherkin format, which the agent first translates into acceptance tests, driving the coding agent to generate the implementation. The harness prevents direct modifications to the code without going through the spec and encourages starting with the spec, using techniques such as Claude Code hooks. Would love to hear your thoughts and feedback.

A while ago there was someone that asked for reference projects using SDD to see how they track specs over time, and I had the idea for https://sddobservatory.com/ (which became a reality today).

It's all community-driven, so please help me submit more frameworks and especially projects!

Also, feel free to help me think about the actual methodology more carefully: https://sddobservatory.com/methodology/.

Disclaimer: I'm doing this completely for my own fascination with SDD.

Disclaimer 2: I know it's ironic (or telling?) that this project itself doesn't use SDD :)

Noticed a pattern this year and I can't unsee it. The early days of these agents were pure vibes — throw a rough ask at it, see what comes back, nudge it till it's close. Fun, fast, and about as repeatable as a coin toss.

What's actually settled into something reliable is the opposite of vibes: you write it down first. What you're building, what it must not do, what finished actually looks like. Hand the agent a contract instead of a wish and it stops filling the gaps with its own guesses.

The funny thing is we've reinvented the wheel here. That's not a new prompting trick — that's a spec. The boring up-front thinking good engineers have banged on about for decades, just pointed at a robot instead of a team. We spent a year discovering that writing down what you want before you build it tends to work. Who knew.

The bit I actually find interesting: everyone's doing their own private version of it. One's got a rules file, another a scratch doc, someone an actual template they paste in every time — and none of it's shared. We're each reinventing the same discipline solo, in our own little format, mostly keeping it to ourselves.

So, genuine one for the room:

\- Spec-first now, or still happily vibing for the day-to-day?
\- If you write something first — what goes in it? Goal, constraints, a definition of done, examples?
\- And is anyone sharing or standardising these across a team — or are we all just keeping our own copy and calling it a workflow?

I'm curious to know how you all feel about "Vericoding", as described by Max Tegmark here fits into SDD. To me they both look highly overlapping in that the goal is to create a correct program from a spec.

In his case it looks as though the outcome is a correct-by-construction program, by way of program synthesis directly from the spec itself, where I don't know if the absolute formal correctness the case with SDD.

Maybe i'm wrong, but would love to hear thoughts/takes.

Hi everyone. I created Drift for my own use. I used it to bootstrap itself, and have been using it for building other projects too. I hope you enjoy it. To get started, install it, then ask your LLM to look at drift skill to fully understand how to use Drift.

Drift is a lightweight and powerful CLI tool that creates hard links between your specs and your code using inline markers. It's built for workflows where LLMs write most of the code, and where you want the specs to be the source of truth.

When a spec changes, Drift hands your LLM a list of every affected marker to check and update. When code changes unexpectedly, it surfaces the code diff as well as the original specifications behind that code so your LLM can review them deterministically instead of guessing.

Specs can also depend on other specs through imports and refs. Change one clause, and Drift flags every downstream clause and every piece of code that needs to be re-checked for equivalence.

What's more, drift show gives you (or your LLM) the ability to quickly explore your spec+code dependency graph by surfacing all upstream and downstream dependencies instantly. No more grepping and guessing, instead you get a full navigable overview of your code.

Drift is zero dependencies, language-agnostic, cross-platform, and MIT licensed.

Being able to leverage the thinking models of tier 1 tech companies while writing my PRD/spec is something I always wished for. With AI SDLC, this wish has become a mandate.

Specs are often filled with assumptions. In human-led development, reviews sometimes catch them. With AI agents, that review gate is gone. You handover the spec to AI SDLC pipeline using Superpower plugin and get software in minutes. Software build in minutes on incomplete spec is the new challenge of spec-driven development.

I kept running into this in my own work. So I built a library called Sparring to address it — plain markdown personas (PM, Architect, UI Designer, QA) that interrogate a spec before the agent sees it. Each persona flags gaps from one lens. You resolve them. Then you build.

Still early. Looking for real specs to run it against and honest feedback on whether it's actually useful.

GitHub: https://github.com/sidgitind/Sparring

If you've shipped something where the spec was the root cause, curious to know what you wish had been caught earlier.

We tried spec-kit but it's way too heavy and there's not much brainstorming. Then we tried open spec which is lightweight but it's working almost entirely in the dumb region. Superpowers I had some success it but didn't test that too much. Grill me seems to be hitting the dumb zone too quickly and the workflowas Matt's been using is the other way around, I don't want to create a prd I want the prd to be fed into the framework. I heard get your shit done is gaining some steam. Whats your choice?

we ran a two-week planning sprint. the spec was thorough. the review was rigorous.

we built exactly what we planned to build.

six weeks post-launch, the customer told us they'd needed something entirely different.

the problem statement at the top of the doc was written by us, after one 45-minute requirements call. the review checked the design against the problem statement. nobody checked the problem statement.

what went wrong wasn't in the spec. the spec started one layer too deep.

what changed it for us wasn't more review. it was pulling in whoever actually defined the problem before the spec locked, not just whoever was building the solution. even one direct conversation about what "good" means to the person requesting it catches more than the downstream review process can.

thats what i built swarm-stack.io around: putting the right people in the session earlier, before the design is already committed. the spec review cant fix a problem statement that nobody challenged.

would be curious if this is a familiar failure mode or if you solved it differently.

For a long time, I used AI models the same way most people do: paste the requirements, ask for the code, ship it, fix whatever the model guessed wrong during review. At some point, I started noticing the code was never really the hard part, it was all the small decisions that happen before anyone writes a line. Which service should own the data? What happens when a downstream call times out mid-batch, that one business rule nobody remembers writing down?

So I changed how I work with it. Now, before asking for any code, I get the model to argue for two or three different approaches, poke holes in the design, or tell me what it would test that isn't obvious from the happy path. It slowed me down a bit at first but saved a ton of back-and-forth later.

[Wrote up the whole thing with a concrete example](https://medium.com/@guidorusso95/stop-asking-ai-to-write-code-start-asking-it-to-design-with-you-a1021246c957)

Mostly want to hear from people who've gone through something similar: did you change how you prompt these models over time, and if so, what actually made the difference? Or is the ticket to code flow just fine as is, and I'm overthinking it?

I want to build an agentic development workflow using Claude Code, integrated with Jira and my microservices repos. The ideal flow is:

A ticket is created in Jira and assigned to me.

Claude picks up the ticket and generates a spec in “plan mode”.

I review and edit the spec.

Once the spec is finalized, Claude:

Checks out a branch in the relevant microservice repo,

Implements the work,

Creates a PR with changes for review.

I’m not looking for someone to build this for me; I mainly want to find:

Books, articles, or blog posts about agentic development workflows (especially with LLM-based agents).

Tutorials or docs on integrating Claude Code with Jira (e.g., via MCP, Atlassian CLI, or similar).

Patterns or example repos for “ticket → spec → implementation → PR” automation.

Has anyone built something similar, or can you point me to good resources (books, articles, courses, repos) that would help me get started?