A friend who runs engineering at a fintech told me something strange last month. His team has not opened a JIRA ticket in eight weeks. They still ship every Friday. They still hit their quarterly goals. They still hold a small standup. The thing they stopped doing was writing tickets.
What they write instead is a short document for every change. They call it a spec. It explains what the change is, why it matters, what the success criteria look like, and which files or systems are involved. Anyone on the team can read one and understand the work. The team's AI coding agents can read one too, and that has changed everything.
This shift has a name now. People are calling it spec driven development. It is not a tool, not a framework, and not a new flavor of Agile. It is a quiet rewiring of how a team plans, communicates, and builds. By the end of 2026, I think most serious engineering teams will be doing some version of it. Here is why, and how to do it well.
The Ticket Was Designed for a Different Era
The JIRA ticket, the Trello card, the GitHub issue. All of them came from the same idea. A small unit of work, a short title, a longer description, an assignee, a status. It worked beautifully for a long time. When most engineers were juggling many small changes and managers needed visibility, the ticket gave the team a shared language.
The ticket was never the work, though. It was a pointer to the work. The real plan lived in a Slack thread, a Google Doc, a Figma file, and three meetings that nobody recorded. The ticket said "add filter to invoice list" and trusted the engineer to fill in the rest from memory.
That worked when the engineer was the only consumer of that ticket. It does not work when an AI agent is also a consumer. An agent has no Slack history. It cannot ask the product manager a follow up over coffee. It cannot read your mind. If you give it a vague ticket, it will write vague code. If you give it a clear spec, it will write code that often does not need much rewriting at all.
The ticket optimized for the human asking the question. The spec optimizes for everyone who has to answer it.
What a Spec Actually Is
Strip away the jargon and a spec is a one or two page document that describes a single change to your product. It is shorter than a design doc, longer than a ticket, and far more concrete than either.
A good spec answers six questions in plain language.
What is changing. The smallest possible description of the change a user will see or feel.
Why it is changing. The problem this solves or the bet you are making. One paragraph, not a strategy memo.
Who it is for. The user, the role, or the system that benefits.
What success looks like. The concrete signal you will use to know it worked. A metric. A behavior. A test that passes.
How it should behave. The shape of the solution at the level of a thoughtful pull request description. Edge cases. Error states. Empty states. The boring stuff that quietly defines whether the feature feels finished.
What to touch. The files, services, or systems you expect to change. Not a complete plan. A starting map.
That is it. The spec is short on purpose. If it grows past two pages, you are probably hiding two changes inside one document.
The format does not matter. Markdown in your repo. A page in Notion. A short doc in Linear. What matters is that the spec is the source of truth, the same way the ticket used to be, and that anyone or anything that needs to understand the change can read it without asking.
Why It Suddenly Works in 2026
Specs are not new. Engineers have been writing them for decades. What is new is that the cost of writing one just collapsed, and the value of having one just exploded. Three forces met in the middle.
The first is that AI coding agents finally became reliable enough to do real work, but only when they have real context. A vague prompt to an agent in 2024 produced a mess. A clean spec to an agent in 2026 produces something that often works on the first run. The team that writes good specs gets a compounding boost from every model release. The team that hides the work in tickets and Slack threads does not.
The second is that writing the spec is no longer the slow part. With a model assisting, a product manager and an engineer can draft a tight spec in twenty minutes. The model asks the obvious questions. The humans make the decisions. The output is a document that would have taken an afternoon to write by hand a few years ago.
The third is that teams are tired of the ceremony. Backlog grooming. Refinement. Estimation. Replanning. All of it was scaffolding around a unit of work that never carried enough information on its own. When the unit of work is rich, the scaffolding can shrink. The standup gets shorter. The estimation argument disappears. The retro stops being about misunderstandings.
The ticket made the meeting necessary. The spec makes the meeting optional.
This is the part that surprises people. Spec driven development is often pitched as a way to use AI better. That is true, but it is not the main win. The main win is that the team finally has a clear written record of what they are building and why, and that record is useful to every reader, human or otherwise.
The Anatomy of a Good Spec
After looking at dozens of teams trying this, the same shape keeps showing up in the specs that work. It is worth being explicit about it, because the temptation to over engineer the format is real.
A short title that names the change in five to ten words. Not a feature codename. The actual change.
A single paragraph problem statement. What is broken or missing today. What will be true after this ships. Concrete enough that a new engineer would understand the gap.
A success section with one or two measurable signals. A target conversion rate. A page that loads under a second. A workflow that completes without manual cleanup. If you cannot describe success in a sentence, the spec is not ready yet.
A behavior section that walks through the change at the level of an experienced reviewer. The happy path. The two or three edge cases that matter. The error and empty states that are often forgotten. Screenshots or sketches if the change is visual.
A scope section that says clearly what is in and what is out. The out list is the most useful part. It prevents the spec from quietly absorbing every nice to have idea that surfaces during the work.
A starting map of the code. Not a full implementation plan. A set of pointers to the files, modules, or services that the change will touch. This single section is often what makes an AI agent useful instead of dangerous. It anchors the work in your real codebase rather than a generic guess.
A tiny risk section. The two or three things that could go wrong. The migration that needs care. The downstream service that needs a heads up. The customer who has special handling and might break.
The whole thing fits on one screen for small changes and two screens for bigger ones. If it does not, you have a project, not a spec, and it should be split.
What Changes for the Team
The shift looks small from the outside. Underneath, it changes a few things at once.
**Roles get sharper.** Product managers spend more time writing and less time chasing. Engineers spend more time deciding and less time decoding. Designers attach mockups to the same document as the engineering plan instead of a separate Figma link nobody opens. The spec becomes the meeting place for the disciplines that used to talk past each other.
**Standups shrink or disappear.** When the spec is the source of truth, the daily question of "what are you working on" mostly answers itself. Most teams that go full spec driven keep a short weekly review for surprises and kill the daily standup within a few weeks.
**Estimation stops being theater.** A clear spec is much easier to size than a vague ticket. Most changes fall into a few obvious buckets. Half a day. A day or two. A week. Anything bigger gets split. The spreadsheet of story points retires quietly.
**Code review changes shape.** Reviewers stop reading the diff cold. They open the spec first, then read the diff against it. The question stops being "is this code clean" and becomes "does this match the spec, and is the code clean." The bar goes up without the review getting longer.
**The roadmap becomes browsable.** Specs sit in a folder, not a tracker. New hires read the last twenty specs and understand more about the product in a day than they used to learn in a month. Investors and partners can read a spec and understand what shipped without a slide deck.
**AI agents get genuinely useful.** This is the obvious one, but it is worth being precise about. With a clean spec in front of it, a coding agent can draft the change, run the tests, fix the obvious failures, and open a pull request that is often most of the way there. The engineer reviews, refines, and ships. The cycle from idea to merged code shrinks from days to hours for the kinds of changes that used to take a sprint.
Where Teams Get This Wrong
Spec driven development is simple enough to describe and surprisingly easy to mess up. The teams that struggle usually fall into one of a few traps.
**They write specs that are too long.** A ten page spec is a design document. A design document is fine, but it is not a spec, and it slows the team down. If a spec needs ten pages, the change inside it is too big and should be broken into pieces that each get their own short doc.
**They write specs that are too short.** A two sentence spec is a ticket with a new name. The agent will guess. The reviewer will guess. The result will look like the old workflow with extra steps. The point is to write enough to remove the guesswork, and no more.
**They skip the success criteria.** Without a clear definition of done, the change drifts. Engineers add scope. Reviewers ask for more. The PR sits open for a week. A single sentence of success criteria saves all of that.
**They treat the spec as a one way document.** A good spec is updated as the work uncovers things. The PR is reviewed against the final spec, not the original draft. Teams that lock the spec on day one end up shipping code that no longer matches the document, and the document becomes useless.
**They expect the AI to write the spec.** It will not, not well. The spec is where the human judgment lives. The model can help draft, ask questions, and tighten the language. The decisions are still yours. Teams that try to outsource the thinking get specs that read smoothly and fall apart in review.
**They roll it out by mandate.** A leadership memo that says "we are spec driven now" usually fails. The change works when one team tries it, ships faster, and other teams notice. Pull, not push.
A Pragmatic Way to Start
You do not need a new tool, a new methodology, or a leadership offsite. You need a folder, a template, and one team willing to try it for a month.
Start by picking a single squad and a single project. Write the next ten changes as specs instead of tickets. Keep a one page template handy and stick to it. Use whatever format your team already reads, whether that is markdown in the repo or a doc in your project tool. Do not invent new tooling on day one.
Pair the spec with your AI coding agent of choice. Hand the spec to the agent and let it draft the change. Review the output against the spec, not against your own memory. Keep notes on where the agent struggled. Most of those notes will point at parts of the spec that were not clear enough.
After a month, look at three numbers. The time from idea to merged code. The number of follow up changes per spec. The amount of meeting time the squad spent. If those three numbers move in the right direction, the experiment worked. Roll it to the next squad.
The teams that we have seen do this well treat the spec as a living artifact. They keep an archive. They review the last quarter's specs in their planning sessions. They notice patterns. The spec library becomes a kind of institutional memory that survives turnover, onboarding, and the next reorg.
If you are wondering how this fits with [vibe coding](/blog/vibe-coding-what-it-is-and-how-to-use-it-without-building-a-mess), the honest answer is that spec driven development is the grown up version. Vibe coding is what you do when you are exploring. Spec driven development is what you do when you are shipping. Most teams need both, and the spec is the bridge between the two.
The Bigger Pattern
Step back and the trend is bigger than tickets versus specs. Software teams are moving from oral and chat based coordination to written, structured coordination. The reason is simple. Models, agents, and automation can read writing. They cannot read a Slack thread you forgot to follow up on, a hallway conversation, or a half remembered decision from last quarter.
The teams that write things down win twice. They get an AI workforce that can actually help them, because the inputs to that workforce are clear. They also get a human team that argues less, ships faster, and onboards new people in days instead of months. Both of those wins compound.
This is the same pattern that played out a generation ago when engineering teams started writing tests. At first it felt like extra work. Then it was how the best teams shipped. Then it was the default. Specs are on the same arc. Five years from now, a team without specs will look the way a team without tests looks today.
The good news is that you do not need to commit to anything dramatic to find out if it works for you. Pick a project. Write the next ten changes as specs. See what happens. The cost is one template and a little discipline. The upside is that you start the next chapter of how software gets built with a real head start, instead of waiting to copy someone else's playbook.
The ticket served us well for twenty years. It is okay to thank it and move on.