Five themes dominated the sessions I attended, below are my thoughts.
- Vibe coding: proven for prototypes, unproven at scale
The sessions on AI-assisted development confirmed something I’d already tested myself. I’ve published small apps this way, but the real value for me is speed to a working artifact — a demo, a prototype, a proof of concept I can put in front of someone the same day. The significant part for our context is that it doesn’t consume development capacity. No new ticket, no backlog negotiation, no waiting for a sprint boundary to validate an idea.
The open question, which none of the sessions fully answered, is what happens after the prototype lands well. When a throwaway becomes something people depend on, it inherits real requirements: complexity, scale, maintainability, security review, someone owning it at 2am. Whether AI-generated codebases hold up under that is genuinely unsettled, and I’d treat anyone claiming otherwise with caution.
My read: vibe coding is excellent for the discovery phase and should stay there for now, with an explicit handoff point where something gets rebuilt properly if it graduates.
In short: “stop writing specs (?), stop structuring, stop pretending you know what you want before you see it” (quote from article ‘Spec-Driven Development Isn’t Broken. It will collapse.‘ on Medium).
- Spec-driven development: familiar concept, new consumer
The pitch: write structured specifications, get agreement on them, and treat them as the source of truth that AI then generates code from.
I spent most of the session thinking we’ve been doing a version of this for decades. Requirements, specifications, acceptance criteria, agreement before implementation — this is the discipline we already have, or at least the one we already say we have.
What I think is actually new isn’t the concept but the audience. The specification now has two consumers: humans and AI coding agents. That changes the cost of ambiguity. A vague requirement used to get caught by a developer who’d come back and ask. An agent won’t ask — it’ll fill the gap with a plausible guess and produce confident, wrong output. So the payoff for precise, well-structured specs goes up considerably, which is arguably good news for how we already work.
SSD is a great add-on to Vibe Coding… adding governance, structure, scoping, etc. — without this nobody owns the part that explains “what ‘right’ means”.
In short: turn feature requests into specs, specs into tasks, tasks into code.
- The “end of apps” question
A recurring thread was whether we’re moving away from apps as the primary interface. Probably not the end of apps, but plausibly the start of a different interaction model: instead of opening an application, navigating menus and clicking through screens, you state an intent and an assistant or agent determines which systems to call and in what order.
The implication for anyone who builds interfaces is worth sitting with. If agents become a real consumption path, the interface stops being the product and the underlying capability does — which puts a lot of weight on how cleanly our systems can be invoked programmatically. It connects directly to the MCP theme below.
- MCP is where the attention is
Model Context Protocol came up repeatedly: wrap a standard interface around your existing APIs and let agents call them directly.
This is the item I’m going to investigate further. At first glance it looks like a credible path to modernizing legacy applications without a rebuild — you leave the system as it is and expose its capabilities through a layer agents can consume. That’s a meaningfully different cost profile from replacing anything.
Caveat: I saw it demonstrated, not operated. The questions I’d want answered before we commit to anything are authentication and authorization, audit trails, how you stop an agent from doing something destructive, and what the maintenance burden of the wrapper actually looks like a year in.
- The biggest takeaway: AI is already normal
The most convincing argument wasn’t in any single talk. It was watching how the speakers used AI in passing — for coding, research, automation, routine work — without remarking on it. It’s simply part of how they work now. We knew this, but seeing it as ambient practice rather than a topic is different from hearing it claimed.
The lesson I took isn’t “use AI for everything.” It’s narrower and more useful: automate the repetitive, eliminate the manual, and protect your time for the work that genuinely requires you.
And finally, there were plenty of great slides at the conference, but this one stuck in my head, so I’m reposting it here. 👇
Leave a Reply