TIBs and the End of Execution

How agentic coding pushed us from ADRs to Technical Intent Briefs, and why the shift hints at something deeper.

By Gareth on 6th May, 2026

In my 10+ year engineering career I've worked in a variety of engineering teams of different scales. Technical documentation has always been light, unstructured and scattered across code comments, external docs and planning tools. Agentic coding has changed everything.

First came Claude Code and the CLAUDE.md file. I believe this was the aha moment for many developers. The first time agentic coding as a replacement for the old ways started to become real. With iteration came spec-driven development, a loose documentation-based workflow that worked well with LLMs. At Morpho we followed these trends within a growing monorepo. Slowly we converged on ADR-driven development, a more specific form of spec-driven development. The velocity and ability to one-shot reasonably complex features went through the roof. But the system was not perfect. ADRs were designed in an age without LLMs. They are structured to help humans reach consensus on an architectural decision or direction. We needed something that described technical intent precisely enough that an agent could run with it. We wanted something that would capture the value ADRs were providing in our agentic workflows but be better structured to accommodate agents and humans when context building. We settled on something we called TIBs...

A TIB is an adaptation of common technical documentation, primarily ADRs. Its purpose is slightly different. Instead of trying to capture a decision to help future humans understand how a codebase evolved, it tries to capture a technical intent, such that agents can plan and execute on that intent and future humans can understand how and why the codebase evolved in the way it did. In case you haven't guessed yet, TIB stands for Technical Intent Brief.

To be clear, ADR-driven development was working very well in our monorepo. Agents are very good at inferring intent. The motivation to define something different came from the traditional ADR structure being a bit too restrictive on the context we could include. We'd find ourselves wanting to add sections, and at some point it's no longer an ADR.

## Diff

- **Renamed**
  - `ADR-NNNN` → `TIB-YYYY-MM-DD` (sequential → CalVer)
  - `Decision` → `Proposed Solution`
  - `Alternatives Considered` → `Considered Alternatives`
- **Removed**
  - `Decision Drivers`
  - `Consequences` (Positive / Negative / Neutral)
  - `Confirmation`
  - Pros / Cons lists inside each alternative
- **Added**
  - `Goals / Non-Goals`
  - `Current Solution`
  - `Implementation Phases` (sub-section under Proposed Solution)
  - `Assumptions & Constraints`
  - `Dependencies`
  - `Observability`
  - `Security`
  - `Open Questions`
  - `Addenda`
- **Unchanged**
  - Metadata table structure (prefix only changes)
  - `Context`, `Future Considerations`, `References`

In general the diff represents the tweak from documenting a decision to documenting an intent. For example, going from "Decision" and "Decision Drivers" to "Proposed Solution" and "Current Solution" is not a substantial change, but the difference in framing results in a different type of document. The latter is more explicitly saying: this is the existing context (Current Solution) and this is the desired state (Proposed Solution). The output of LLMs is directly tied to the English used in the input, and so even though the diff in outline and section titles may seem small or insignificant, they do have meaningful impact on the results.

But TIBs are irrelevant.

The shift from ADRs to TIBs is not really about improving documentation. It's much deeper than that. The programming language is now English, humans collaborate on intent, machines make it real. We are no longer required for execution.