Your AI agent is making 50 implicit decisions per task. You see zero of them.

Tell Claude Code or Copilot to "build a REST API for a todo app." It'll do it. You'll get working code.

But along the way it silently chose: the framework, the ORM, the naming convention, the error handling strategy, the test structure, the validation approach, the status codes, the folder layout. Fifty-plus decisions. You saw none of them.

Three features later, you notice your tests are inconsistent. The auth middleware uses a pattern that conflicts with the error handler. The folder structure doesn't scale. You didn't choose any of this, the AI did, and it never told you.

This is the actual problem with agentic coding. Not that the code is bad. It's that you lost control of the architecture without realizing it.

So I built Defer.

Defer is an open-source CLI that sits between you and your AI. You describe a task. The agent decomposes it into explicit decisions with concrete options and tradeoffs. You choose how much you care about each domain, mark it auto (agent decides, you challenge after) or review (you confirm before execution).

Every decision gets an ID (@STA-0001), a category, and a record of who decided; you or the AI. Change your mind mid-execution, and the agent re-implements. High-impact changes cascade: switch from Go to Python and every Go-specific decision gets invalidated automatically.

The output is a DECISIONS.md, a complete record of every architectural choice that shaped your project.

| ID        | Category | Question               | Answer              | Source |
|-----------|----------|------------------------|---------------------|--------|
| @STA-0001 | Stack    | Backend language        | Node.js (TypeScript)| user   |
| @DAT-0001 | Data     | Database                | PostgreSQL          | auto   |
| @NAM-0001 | Naming   | Route naming convention | camelCase           | agent  |
| @ERR-0001 | Error    | Validation status code  | 422                 | agent  |

What it's not: a prompt optimizer, a framework, or a wrapper. It's a decision protocol. The AI still does all the work; you just see and control every choice it makes.

Works with (probably): Claude Code, OpenAI, Groq, Mistral, Together, Ollama, any OpenAI-compatible provider. Or skip the CLI entirely, run defer init cursor to inject the philosophy into your existing tool's config.

I tried my best to make this more than a PoC, but it's definitely not a complete tool just yet. Most of my testing was done using the CLI + Claude Code, so if that is what you're running on your setup, I highly recommend you stick to it. But if you do see a bug, please share!

I'd appreciate any early feedback, this has been consuming me for some weekends and I'm excited to finally get this out there.

brew tap defer-ai/tap && brew install defer
defer "build a REST API for a todo app"

GitHub: https://github.com/defer-ai/cli
Site: https://defer.sh

Comments

[leob]

Fascinating, but how does it work? How do you "coax" the LLM or the agent (e.g. Claude Code) to make those decisions explicit? Or is your tool an agent which "sits before" (kind of like a filter, or in 'pipeline fashion') Claude Code etc?

[Gabriel Manhães]

This is the biggest issue I'm having so far, honestly 😅

I've tried multiple approaches, I don't see value in the tool only decomposing decisions before implementing, I also want to make it to decompose smaller and smaller subsets of a feature, for example, consolidate a decision to be made (and the possible choices for each decision) and log that decision in real time. And this is tougher than I imagined initially, right now I'm testing with dspy to try and get "better" prompts while also exploring which hooks achieve this "decision stream". The best so far has been a pre tool call hook, specifically for writes and edits made by the executor agent, but the tool doesn't follow the "stop and decide" loop perfectly every time, in fact, I'd say about 50% of the time it ignores it.

[Gabriel Manhães]

Thank you for trying it out and giving me feedback!

My only plans other than what I'm already tackling is that I really want this to be a mainstream step for CI pipelines out there. I believe that by having a "decision check" running after a merge could be really useful to track whether or not a decision was lost during the implementation process. Also, having a DECISIONS.md diff can be really useful to understand past decisions.

About making it a paid pro tool in the future... I'm not sure yet. I'd love to monetize it, but I need to solve the current issues I'm having and also think about how to make this useful for teams, not just solo devs.