January 16, 2026
Over the past year, Liis Laulik and I have been working with teams integrating AI into their software delivery process. Through direct engagements and interviews, we’ve separated signals from noise, identified what actually works for teams versus what works for individual developers or hobbyists. This blog post introduces Dialog Driven Delivery: a methodology that emerged from watching teams succeed (and fail) with AI-enabled development.
Everyone has access to AI coding assistants such as GitHub Copilot, Codex, Claude Code, Cursor. Yet we hear a familiar refrain: “We have the tools, but we’re not seeing the productivity gains we expected.”
AI tools evolve weekly, not yearly. Teams need to figure out what works now, while juggling delivery deadlines. Working with organizations from global enterprises to startups, we’ve observed patterns in what works and what doesn’t. These observations led us to develop Dialog Driven Delivery.
Teams complained AI-generated code was “not quite right.” When we looked closer, the problem was almost never the AI’s capabilities, it was the inputs.
Thin context (vague user stories, no architectural constraints, weak or overly complex coding guidelines) produces weak output. Rich context (detailed specifications, clear constraints, established patterns) produces significantly better output.
Think of AI models as highly capable engineers who have zero context about your specific situation. They need to understand the business context, technical constraints, architectural decisions, and coding standards. With that context, they excel. Without it, they struggle.
This led to our most surprising insight: valuable context lives in conversations, not documentation or backlogs. The tacit knowledge that surfaces during conversation is essential.
When product managers, engineers, and designers work through a problem together, assumptions surface, constraints become clear, and shared understanding forms. The problem was that conversations were ephemeral—notes and tickets always lost something in translation.
AI changes this fundamentally. We can now capture conversational context and use it directly in development. The conversation becomes the main specification source, the foundation of shared understanding. From one rich conversation, you can generate multiple artifacts, then enrich them with additional context from other sources: API documentation from external providers, design mockups, technical constraints, user research, existing architectural patterns, etc.
Dialog is where the main collaborative understanding forms. Everything else, technical docs, designs, integration specifications, enriches that foundation.
Once we understood that dialog was the main source and context quality mattered, we needed a format that could capture conversational richness in a way AI could work with effectively.
Specifications turned out to be that bridge. They are (should be) structured for AI to parse and reason about how a system should work through: clear requirements, explicit constraints, defined acceptance criteria.
There is no specification format that is the best for all environments, but there are some principles that should be followed: best specifications are behaviour-oriented and express how a system should work.
When AI generates code in minutes instead of days, real constraints become impossible to ignore.
Architecturally: tight coupling, infrastructure bottlenecks, slow builds, fragile tests. Organizationally: unclear requirements, delayed decisions, stakeholder unavailability, approval processes. These constraints were always there and AI just makes them obvious in days instead of weeks.
The most common mistake: giving teams AI tools and expecting immediate productivity gains without changing how work is structured.
Tools don’t magically make teams faster. If requirements are unclear, AI writes code making assumptions, resulting in incorrect implementation that requires rework. If architecture is tightly coupled, AI-generated code is too. The real work is to figure out how the teams (not individuals) use the tools.
Since AI generates documentation effortlessly, people tend to create loads of it: architecture docs, architecture diagrams, API specs, Implementation plans, Implementation tasks, etc.
We’ve observed a tendency to generate more documents than needed as document generation has become a lot cheaper with AI. Yes, we ourselves have been guilty of this sin in the past! If you look at Spec Driven Development tools like spec-kit or others, the amount of documentation auto generated is overwhelming. And documentation needs to be reviewed!
Moving all specification work into markdown in Git forces product managers, designers and other stakeholders to learn Git workflows. And we get it, it’s good to keep them under version control and near the code, although anything that makes collaboration harder is hardly worth it.
Meet people where they naturally collaborate. Connect AI tools to Confluence, Figma, Miro, Slack, wherever collaboration actually happens.
Spending more time refining AI workflows than shipping features. Constantly experimenting with approaches, switching tools, tweaking processes, without focusing on delivering instead.
You need delivery to create feedback. Pick a simple approach, deliver something, learn, then adjust. Don’t let process refinement consume most of your delivery time.
Specifications become hundreds of lines trying to capture every discussion, architectural decision and tangential conversation.
Specifications should capture how a system should behave: requirements, constraints, and decisions directly relevant to implementation. Architectural decision details should live in ADRs. Technical spikes get separate docs. A focused spec is far more valuable than a comprehensive one that buries context in noise.
Set up loops where AI-generated code goes through automated refinement before human review. Linting catches style issues. Type systems catch type mismatches. Tests catch logical errors.
Let deterministic checks fail, let AI review and fix its own failures, let them pass. Then bring humans in for architectural review and whether code solves the right problem. This respects everyone’s time. AI can iterate on its own output based on objective feedback, reserving human attention for higher-level concerns that require judgment.
This assumes you have these systems in place: if your project lacks automated tests for instance, you’ll need to invest in that infrastructure first.
Successful teams capture context from cross-functional conversations systematically. They maintain team conventions in documented formats. They make architectural decisions explicit.
They build context iteratively, not upfront. Start small, add rules as you encounter real problems. Let PR feedback reveal what’s missing. Good context engineering puts what’s needed in context—no more, no less.
This is harder than it sounds. Teams often struggle to know what context is “enough.” Too little and AI makes wrong assumptions. Too much and you create noise that obscures the essential. It takes several iterations to find the right balance for your codebase. Again, iterate, keep delivering and learning.
Traditional spec-driven development assumes complete specifications before implementation. This falls apart when you start building—implementation reveals edge cases, simpler approaches, requirements gaps.
Treat specs as best current understanding, not contracts. When engineers discover during implementation that something doesn’t work as specified, these learnings update the spec. Build feedback mechanisms to capture discoveries and let specifications evolve.
The Principles
Five principles ground the approach:
Capture – Start with cross-functional conversation. Product, engineering, design, together. Capture the dialog where shared understanding forms.
Refine – Context comes from everywhere: dialog, slack threads, designs, prototypes, technical decisions, user feedback. Specifications evolve through inputs. Resolve open questions and validate assumptions. As implementation reveals insights, learnings flow back to the specification.
Decompose – Turn shared understanding into deliverable work. Break features into smaller deployable pieces with clear acceptance criteria connected to source context.
Implement – Context flows to code. Learnings flow back to specifications. Implementation reveals gaps, edge cases, better approaches. These discoveries update the specification, keeping it current.
Dialog Driven Delivery is tool agnostic. You will need:
We chose Claude Code with Atlassian tooling, Confluence for specs, Jira for stories. We have refined commands/prompts (create_spec, refine_spec, decompose), adaptable templates for feature specs and user stories, and a few other utils to streamline the process.
Yes, it’s essentially transcripts → specs → multi-modal refinement → stories, with enrichments to follow our principles like “Make uncertainty visible” and a few other practices.
We deliberately leave implementation flexible. Use the spec and story as context to create an implementation plan, review it, then ask AI to implement it. There are numerous ways teams are using AI agents for implementation. Some use multi-agent approaches with parallel work streams. Others prefer single-agent, sequential execution. We’ve experimented with both and complexity isn’t always better.
Start simple, add complexity only when you’ve identified a specific need for it. Whatever approach you choose, we recommend following the patterns we shared, avoid the pitfalls, set up feedback loops for AI self-review, build context iteratively, and let specifications evolve.
Consider the human factor: your team needs to want to work this way. The emphasis on cross-functional conversations and explicit context requires buy-in from product, engineering, design and other key stakeholders. Collaboration increases, more mobbing, more crossed role boundaries. It’s a different way of working.
You also need organisational support for time investment. Building good context takes upfront effort. Optimisation is iterative, things start slower and move fast after shipping a few features.
What success looks like: Teams practicing Dialog Driven Delivery report fewer implementation surprises: code matches intent because intent was captured clearly. Cross-functional alignment improves because everyone participated in the same conversations that generated the specs. Quality increases because AI has the context to generate appropriate code, and humans review with full understanding. Most importantly, the pace accelerates after the first few features as the team builds up reusable context and patterns.
We’re still in the early stages of understanding how AI changes software delivery. Dialog Driven Delivery represents our best current thinking based on what we’re seeing work and not work across client engagements.
What won’t change: AI amplifies the quality of your inputs. Rich context, clear specifications, and explicit decisions produce better output. Thin context and vague requirements produce code needing extensive rework.
Teams that succeed won’t be the ones with the best tools – everyone will have access to the same AI assistants. They’ll be the teams who collaborate effectively as humans first: structuring work to create rich context, making uncertainty explicit, maintaining review discipline, and treating context engineering as a core skill.
At Equal Experts, we work with organisations to adopt and scale AI-enabled Delivery practices like Dialog Driven Delivery. Whether you’re starting with AI-enabled delivery or improving existing practices, we can help navigate the transition.
If you’re interested in learning more about Dialog Driven Delivery or discussing your experiences, reach out. We all learn faster by sharing what works and what doesn’t.
Equal Experts Netherlands AI Labs is a workshop where product and engineering teams learn how to apply AI-enabled delivery practices, like Dialog Driven Delivery, across the entire software development lifecycle. Find out more.
Cláudio is Head of Data and AI at Equal Experts, helping organisations embed AI across the SDLC. With 14+ years in tech, he advises global teams and builds AI products himself. He’s passionate about using AI-enabled engineering practices to accelerate delivery and empower teams through practical workshops and implementations.
Liis brings deep experience in software delivery and organisational change, helping organisations navigate complex technical and cultural shifts. She focuses on how AI will transform delivery and operating models, working with teams across Europe to align AI adoption with capabilities and business outcomes.
This blog is a record of our experiments and experiences with AI. It reflects what we tried, learned, and observed, but does not represent Equal Experts’ official practices or methodologies. The approaches described here may not suit every context, and your results may vary depending on your goals, data, and circumstances.
All business models have their pros and cons. But, when you consider the type of problems we help our clients to solve at Equal Experts, it’s worth thinking about the level of experience and the best consultancy approach to solve them.
If you’d like to find out more about working with us – get in touch. We’d love to hear from you.
