Directions Asia 2026 in Ho Chi Minh City was something special. AI was everywhere — sessions, hallway conversations, keynotes. And it makes total sense. The BC community is learning to what agentic development can do, and honestly? It was exciting to be part of it.
But I noticed something.
Many of the sessions were either too generic or focused on one specific step — how to write a better prompt, or how to use a specific tool. All valuable – not questionable. But I didn’t see the end to end story – how to actually build a real BC extension with an agent, from the first line of the customer’s brief to the final merge.
That’s what I set out to do. And to do it properly, during my “Agentic Coding in AL, Done Right” session – the last one at the very last day – I introduced something to the BC community that I’ve been using and refining — Spec-Driven Development.
So what is it?
Let me start with the problem.
Vibe coding is fast. You describe what you want, the agent writes the code, you feel productive. But then three sessions later, the agent has forgotten everything it built with you. It reinvents patterns. It makes inconsistent decisions. Two developers vibe-coding on the same project produce a codebase that looks like it was written by twenty different people ignoring each other.
Spec-Driven Development (SDD) is the professional response to that chaos.
The idea is simple: the spec is the brain, the agent is the muscle.
Before you ask the agent to write a single line of AL, you write a specification. A structured markdown file that captures the key decisions — what the feature must do, how it will be implemented, and how you’ll know when it’s done. Then you hand it to the agent and let it build.
How it works in practice
Every project starts with a constitution — a set of living documents that represent your app at any point of time:
brief.md— the customer requirements with the very hight level description of business processes.tech-design.md— the high-level implementation plan. How you’re going to build it, which standard BC modules to use, and what gaps need custom code. (And yes — the goal is to use as much standard BC as possible. The agent’s first instinct is always to invent. Your job is to pull it back to what’s already there.)roadmap.md— the ordered feature list. What gets built, in what order, and when it’s done.AGENTS.md— the coding rules. The contract between you and every agent that will ever work in this codebase.
Once the app constitution is in place, every feature follows the same loop:
Feature Spec → Implement → Test → Docs → Merge
You write the feature spec first — requirements, implementation approach, acceptance criteria. You hand it to the agent. The agent implements. You test and review. You generate docs. You merge. Then you replan, and move to the next feature.
One chat per feature. Clean context.
Why it works
Three reasons:
- The specs survive session resets. The agent forgets everything when you create new the chat. The spec doesn’t. Every new session opens with the same project memory — brief, tech-design, roadmap, coding rules. The agent is always aligned.
- You stay in control. The spec forces you to think before the agent codes. You decide the architecture. You decide what standard BC handles and what needs extension. The agent executes your decisions — it doesn’t make them for you.
- The codebase stays coherent. Because every agent session reads the same AGENTS.md and coding rules, the output is consistent — whether it’s you, your colleague, or a different model entirely. The spec doesn’t care which harness you use.
The workshop
I ran this also as a full-day hands-on pre-conference workshop — 21 developers – sold out. Every attendee showed up with a different harness, different models, different setup. Nobody had the same combination. And that was completely fine — because I wasn’t teaching a tool. I was teaching the workflow.
The feedback was… kind:
Knowing that the method resonated — that people left with something they can actually use on Monday morning — that’s what makes it worth doing.
What's next
BC TechDays is coming — 9–12 June in Antwerp. The 2-days of the pre-conference workshops are already sold out. But if you missed it, come to the session: “Agentic Coding in AL, Done Right” — where me, Jeremy and Torben will go really deep into the process together.
And I’ll just leave this here: it’s the last session of the very last day. Again 😅.
I’m starting to think the universe is trying to tell me something.
See you there.


