One day. One room. Date and city to be announced.
Code is cheap now. Agreement is not.
SpecDevCon is the one-day conference for engineers and leaders turning intent into production software. You will see the specs, plans, tests, and operating systems that make agent-built code survive production.
Presented by Agent Driven Development.
Get the conference date
One confirmation request. One date announcement. No list sales. Unsubscribe in one click.
Date notifications are not accepting requests yet.
- Intent contracts
- Design constraints
- Executable acceptance
- Brownfield delivery
Why this room
You do not have a code-generation problem.
Your agent can write the code. That part keeps getting cheaper.
The hard part is deciding what the code must do, which constraints it cannot violate, how the work fits the system you already own, and what evidence proves the result is correct.
Most teams still carry that intent through tickets, meetings, chat threads, architectural folklore, and one engineer who remembers why the billing service behaves that way. Then they point an agent at the repository and call the output acceleration.
Spec-driven development changes the unit of work. The specification becomes the contract. The plan preserves the architecture. The task graph makes execution visible. The tests prove the behavior.
That is the discipline this conference is built to advance.
Program standard
No demo theater. Bring the artifacts.
Every session must leave you with something you can inspect: a constitution, a requirement set, a design decision, a context boundary, a task graph, a property test, a review gate, or the production result that proved the method worked.
We will cover the tools. We will spend more time on the judgment required to use them well.
Program selection is based on practitioner relevance, inspectable evidence, and fit with the continuous track. Commercial participation will be labeled and reviewed separately. Buying a commercial package will not buy a session.
- 01
Intent
Turn a business outcome into requirements an agent cannot politely misunderstand.
- 02
Context
Preserve architecture, constraints, and operating knowledge across long-running work.
- 03
Execution
Move from specification to plan, tasks, implementation, and review without losing the contract.
- 04
Proof
Connect acceptance criteria to tests, telemetry, risk controls, and production evidence.
- 05
Maintenance
Keep specs alive when the repository, team, model, and business rules change.
- 06
Operating model
Decide who owns the spec, who approves exceptions, and how teams measure whether the system works.
Method before machinery
The tool is not the discipline.
Some teams need a lightweight change proposal and explicit acceptance criteria. Others need a constitution, requirements, design constraints, task dependencies, and automated proof.
The right amount of structure depends on the risk, age, and reach of the system you are changing.
SpecDevCon puts those tradeoffs on stage. You should leave knowing when structure protects the work, when to adapt the method, and when another Markdown file is only creating better-organized theater.
- Outcome
- A customer can retry a failed payment without receiving a duplicate charge.
- Constraint
- Every attempt uses one idempotency key. Existing ledger entries remain append-only.
- Acceptance
- Replaying the same request returns the original result and creates no second charge.
- Proof
- Randomized retry tests and production telemetry detect any duplicate ledger write.
This is an example of the evidence standard, not a confirmed session or conference result.
Illustrative program — not a confirmed schedule
One system, followed from intent to proof.
This illustrative program follows one delivery system from intent to proof. You never have to choose between sessions that depend on each other.
Opening
Host framing
Code Is Cheap Now. Agreement Is Not.
A shared definition of the discipline and the day’s contract.
Morning
Keynote
The Spec Is the Product Before the Product Exists
Anatomy of an executable, testable specification.
Morning
Case study
The 14-Year-Old Service the Agent Could Not Understand
Brownfield context map, constraints, and final delivery evidence.
Late morning
Technical session
From Constitution to Implementation Without Losing the Contract
Constitution, spec, plan, tasks, and cross-artifact checks.
Lunch
Artifact gallery
Inspect the Work
Requirements, verification, governance, and platform tables.
Afternoon
Live build
From One Sentence to One Proved Pull Request
Intent, spec, plan, tasks, implementation, and evidence.
Afternoon
Verification session
Acceptance Criteria Your Agent Cannot Charm Its Way Around
Structured requirements, property tests, and production assertions.
Late afternoon
Failure session
When Spec-Driven Development Becomes Better-Organized Theater
Anti-patterns, abandonment criteria, and recovery moves.
Closing
Working session
Bring One Spec Monday
Leave with one 30-day adoption experiment.
Who it is for
Come if you are accountable for what ships.
You might write the spec. You might build the platform that carries it. You might approve the architecture, defend the risk, lead the team, or explain the production result to the board.
Your title matters less than the accountability. If generated code reaches a customer and you own part of the consequence, this room is for you.
The format
One track. No hallway regret.
The first SpecDevCon is a single curated track. You should not have to choose between the requirements session and the verification session when the entire point is that they belong to the same system.
Talks stay concise. Breaks stay long enough for the useful argument after the talk. Lunch includes an artifact gallery. The day closes with a working session that turns what you heard into one change you can make Monday.
The operator
Presented by Agent Driven Development
Agent Driven Development is run by a senior engineering leader who still writes code. The work starts where the tool demo ends — operating models, engineering economics, governance, team design, and software that has to survive production.
SpecDevCon exists because the conversation has moved past whether agents can write code. The question now is whether you can tell them what matters and prove they delivered it.
The date notification
We are building the room now.
Ask for one notification when the conference date is announced. This request does not enroll you in a newsletter or authorize speaker, ticket, sponsor, partner, or parent-brand email.
Date notifications are not accepting requests yet.