On Thursday 25 September 2025 I went back to the Datadog office in Amsterdam for the Datadog User Group Amsterdam meetup. Iâd been there a year earlier for the user groupâs GenAI evening with AWS and Cloutive. This time there were two talks. The first was about running engineering at a company built from acquisitions. The second was AWSâs case for moving from âvibe codingâ to spec-driven development, with a live demo of Kiro.
This is a throwback built from my photos and a few short video clips, so Iâve stuck to what was on the slides and what was said on stage.
Before the doors opened: the Datadog User Group Amsterdam slide and a room still waiting for its audience.
The agenda
The organisers opened at 18:30. Talk 1 was by Brent McLean, starting at 18:40, and Talk 2 was by Gunnar Grosch, from 19:30 to 20:15. Networking and drinks followed until the doors closed at 21:00.
The running order and the two talk titles, with the Datadog User Group logo in the corner.
Talk 1: operational excellence in an inherited environment
Brent McLeanâs talk had a long title: âChasing Operational Excellence in an Inherited Environment: Knowing What Good Looks Like Doesnât Always Make It Soâ. The slide introduced him as ex-CPTO at eBay and Group CTO at AVIV Group.
He started with the eBay Classifieds Group (eCG) background. Classified ads businesses, he explained, are hyper-local. Many started as a paper product that moved online, and the market leader in a country often has 15 or 20 years of history. Through acquisitions you end up with about ten very similar businesses, each with its own tech stack. His job grew from re-platforming one of them into a group role across roughly ten businesses around the world, with an obvious question: do you move them all onto one platform?
âeCG - Multiple Product Lines on a Global Platformâ: thin product lines on top, shared capabilities and infrastructure underneath.
The eCG slide was his answer, drawn as a platform. Three product lines sat at the top: Horizontal, Motors and Commercial. Each had its own web, iOS, Android and API front ends. Underneath sat shared capabilities: user and identity, search, listings, category attributes, chat and e-mail communication, SEO, data products, image recognition, search intelligence and fair value. Below that was infrastructure: CI/CD, security, databases, queues, logging and orchestration. A resource-allocation axis on the left put 20% against the product lines and 80% against the capabilities and infrastructure. The diagram was also split into commodity and differentiating parts.
His other point was one I agree with. Even as a technologist, you need to understand what makes your business commercially viable. If you donât, youâll make decisions that seriously damage it while thinking youâre building something great.
AVIV: principles and an architecture dashboard
The second half moved to AVIV. The âFoundational principles at Avivâ slide read: one roadmap for all of Aviv, business processes and practices made global, the product and technology (P&T) teams combined into one global team, and private equity investing in the transformation. The result would be a platform that can host all Aviv brands, make it quick to integrate M&A acquisitions, and support a product that beats the competition through innovation.
The architecture dashboard: everything an architecture team knows about an inherited estate, pulled into one place.
This was the slide I photographed twice. A central Architecture Dashboard (âcuration, aggregation, visualization, automationâ) pulled in:
- Source code: AVIV GitHub, MA GitHub, IWT TFS, IWT GitLab and IWT Bitbucket repositories, GitHub Copilot metrics and Snyk security reports.
- Workforce data: Beebole time tracking, Workday team lines and Slack analytics.
- Planning data: Jira tickets for planning and bugs.
- Documents: Confluence (ADRs, diagrams) and Atlassian Intelligence AI summaries.
- Cost: AWS Cost Explorer.
On the output side were curated data sets (a capabilities map, a legacy map, the product portfolio, AVIV brands, a developer who-is-who, AWS domain maps, an incidents index and a golden path index) and expert material such as talking points, deep dives, product reviews and expert talks.
My take: this is what âknowing what good looks likeâ means in practice when you inherit five Git platforms. You canât run a golden path programme until you can see which teams, repositories and incidents belong to which capability. A dashboard built from data you already have is a cheaper first step than a reorganisation.
Talk 2: from vibe coding to spec-driven development
After the break, Gunnar Grosch, Principal Developer Advocate at AWS, gave a talk called âFrom vibe coding to spec-driven developmentâ.
Gunnar Groschâs title slide.
He started with a timeline called âAI is changing softwareâ:
- 2023, auto-complete: helping developers write code faster.
- 2024, assistants: generating larger pieces of code and answering questions.
- 2025, agents: completing development tasks end to end, with a human in the loop.
Three years, three modes: auto-complete, assistants, agents.
Then came the comparison the talk was built on. Vibe coding means natural language prompts, fast prototyping and intuition. The output is messy and fragile, and itâs âgreat for 0 â 1â. Engineering means specifications and design, reliability and scaling, testing and verification, security and maintainability. Itâs âessential for 1 â Nâ.
Vibe coding gets you from 0 to 1. Engineering gets you from 1 to N.
The next few slides explained why that still matters. âWhy engineering mattersâ listed four properties: correct (the system behaves as expected), efficient (it uses resources wisely and scales as users grow), secure (it can withstand attacks, protect data and build trust) and maintainable (the next developer can read it, improve it and keep it alive). The âNew developer skillsetâ slide had four items: critical thinking and verification, reading and debugging AI code, prompt specification, and ethics and system design.
âThe rise of agentic AIâ placed three stages on a line from more human oversight to less:
- Generative AI assistants follow a set of rules and automate repetitive tasks.
- Generative AI agents achieve a singular goal, address a broader range of tasks and automate entire workflows.
- Agentic AI systems are fully autonomous, use multi-agent systems, and mimic human logic and reasoning.
The spec workflow
The core slide was one line: Prompt > requirements.md > design.md > tasks.md > code.
The spec chain, with Kiro showing the tasks.md of a âlive-emoji-reactionsâ spec.
The screenshot under it showed Kiro with a spec called live-emoji-reactions. The editor had three tabs, 1 Requirements, 2 Design and 3 Tasks. The tasks.md implementation plan had checkbox tasks with a âStart taskâ action, such as âSet up project structure and core componentsâ and âImplement EmojiButton component with basic functionalityâ. Each task listed sub-steps and ended with references to the numbered requirements it covered. The sidebar had sections for Agent Hooks (âAutomate repetitive tasks with smart triggersâ), Agent Steering (âGuide agent behavior and responsesâ, with a âGenerate Steering Docsâ button) and MCP Servers, including fetch, strands and two awslabs servers for CDK and front-end work.
That traceability is the point. With pure prompting, the first thing you review is the code. With a spec, you review requirements and a design first, and every task points back to the requirement it implements.
âItâs about architecture, not promptsâ
An agent, a gateway, an authoriser and an MCP server: the spec ends in an architecture diagram, not a prompt.
The slide I liked most showed a small architecture. An Agent built with Strands Agents talks over sHTTP to API Gateway. Requests go through a Lambda Authorizer, and API Gateway forwards them to an MCP Server running as a Lambda function. The title made the argument: âItâs about architecture, not prompts.â The model writes code, but someone still has to decide where authentication happens and what sits behind the gateway.
My take: I read âsHTTPâ as MCPâs Streamable HTTP transport, which is what lets you put an MCP server behind a normal API gateway with normal auth. Thatâs exactly the sort of decision that belongs in design.md and shouldnât be left to whatever the agent picks.
The live demo
Gunnar then switched to Kiro itself. He explained that Kiro is built on Code OSS, so it looks familiar, and that AWS built it around spec-driven development because editor extensions only go so far. He also said the idea wasnât AWSâs alone, since other frameworks work the same way. At the time Kiro was in preview, and it also supported plain vibe coding, which you can mix with specs.
In spec mode he asked for a user authentication system with login, logout and password reset. The model picker showed Claude Sonnet 4. Kiro generated a requirements.md with user stories, and he pointed out what was missing: âSince this is a Datadog meetupâ, there was nothing about observability. A chat message later, the requirements included OpenTelemetry tracing for all authentication operations. He noted that you can review the document with your team and keep it in Git for versioning.
The design step used MCP tools to look up how to implement the tracing. He showed a fetch server, an AWS documentation server, and said you could add the Datadog MCP server too. Later in the demo, the Kiro explorer showed a .kiro folder with the spec (design.md, requirements.md, tasks.md) and three steering files: product.md, structure.md and tech.md. The generated tech.md listed TypeScript, Vitest for testing, and @opentelemetry/* packages for observability instrumentation.
The demo project: a spec plus three steering documents, with OpenTelemetry listed under dependencies in tech.md.
A question from the audience
During the design step, someone asked whether organisations would build more of their own software now that itâs easier, and how much theyâd still buy. Gunnar said companies are currently trying to build everything themselves with generation tools such as Lovable. He expected that to decline, because a lot goes wrong: in Sweden heâd noticed ads from people looking for engineers to finish projects theyâd started building themselves. His answer was a mix: companies doing some things themselves, such as dashboards and tools for business decisions, and a risk of data leaks when people connect what they build to internal systems.
Kiro today
A year on, a few details from that evening have changed. Kiro left preview: AWS announced general availability on 17 November 2025, adding a Kiro CLI, checkpointing, property-based testing and team management through IAM Identity Center. The concepts from the demo match the current docs:
- Specs produce
requirements.md,design.mdandtasks.md, the same three-phase flow as on the slide. - Steering uses
product.md,tech.mdandstructure.mdin.kiro/steering/, included in every interaction by default. - Hooks run shell commands or agent prompts when events happen in a session, such as running a linter when the agent saves a file.
My take: the tool matters less than the habit. The same pattern works in other coding agents too. In Claude Code, for example, itâs a written spec, a CLAUDE.md memory file and hooks, and it works for the same reason. Reviewing a page of requirements is faster than reviewing a thousand lines of generated code, and itâs the only review that catches a missing requirement, like observability, before the code exists.
Also on the table
The sign-in desk had a stack of Datadog stickers and a flyer for Cloud Native Community Days Amsterdam 2026, on 21 and 22 May, at cloudnative.amsterdam.
Stickers and a save-the-date for Cloud Native Community Days Amsterdam 2026.
