Beyond the Hype: Lessons from Pragmatic Summit

There's something about being in a room with people like Gergely Orosz, Laura Tacho, Martin Fowler, Kent Beck, and Steve Huynh that you simply can't replicate through blog posts and Twitter threads. The summit struck a nice balance: small enough that you could actually have meaningful conversations during breaks, large enough that there was a constant stream of sessions to attend and ideas to absorb. I wasn't there to speak or present; I came as someone who's spent the last year deep in the world of GenAI tooling in developer experience at Booking.com, wanting to see how our experiences and challenges compared to what's happening across the wider industry.

What struck me most wasn't any single quote or revelation, but rather the overall tone of the conversations happening. While the rest of the tech world seems to oscillate wildly between "AI will replace all developers by next Tuesday" and "this is all just hype that will blow over," the people in that room were having much more nuanced discussions. They were talking about real implementations, real challenges, and real results. The hype machine is still running at full speed outside these walls, but inside? People were focused on actually making this technology useful. I guess the hint was in the title: "Pragmatism".

The Hype Machine is Still Running

I wrote about the dangers of hype last year, and if anything the noise has only gotten louder since. If you've been following the tech press over the last year, you'd be forgiven for thinking that by the end of 2026 all developers will be an extinct species. The headlines keep coming: "AI will write all code by year's end", "Junior developers obsolete", "Software engineering jobs at risk", etc. It's the same cycle we've seen before with every transformative technology, but this time it feels more insistent, and frankly, more exhausting.

The disconnect between what's being promised and expected in boardrooms and what's actually happening on the ground is vast. There is a consensus that the big investments are still targeting anything with "AI" in the pitch deck. Companies are under immense pressure to demonstrate their AI strategy, often before they've figured out if they actually need one. I've lost count of how many product announcements I've seen where "AI-powered" has been slapped onto features that would work just as well—or better—without it. AI is a solution to a swathe of problems, so we're told.

What struck me at the summit was how little time people spent talking about this narrative. Not because they were ignoring it, but because they'd already moved past it. When you're actually building and using these tools day-to-day, the gap between the hype and the reality becomes impossible to ignore. Yes, LLMs can generate code. Yes, they can be remarkably helpful. No, they're not going to replace the need for engineers who understand systems, make architectural decisions, and know when the generated code is leading you down a terrible path.

The hype persists for predictable reasons: investor pressure to justify valuations, competitive positioning (nobody wants to be seen as falling behind), and genuine excitement about the technology's potential. The reality, as ever, is that meaningful change happens gradually, messily, and with a lot of trial and error along the way.

Seeing Through the Fog

Once you get past the noise, there's actually something substantial happening. The statistics shared at the summit were surprisingly consistent: most companies are seeing around a 10% productivity increase from developers using AI tools day-to-day. That's not the revolutionary 10x improvement that the hype promised, but it's also not nothing. More importantly, the companies seeing real benefits aren't the ones treating GenAI as magic: they're the ones building deliberate platforms and workflows around it.

Uber's approach particularly stood out. Rather than just giving developers access to ChatGPT or GitHub Copilot and hoping for the best, they're investing in tooling that makes it easy to use AI while being explicit about the trade-offs. Code generation platforms that integrate with their review processes, systems that help developers understand what they're accepting when they use AI-generated code. It's not about replacing developer judgement; it's about augmenting it with better tools and clearer guardrails.

Hearing these examples was genuinely heartening, because it confirmed we're on the same journey at Booking.com. We've been experimenting with similar platforms over the last year, and seeing other mature engineering organisations grappling with the same challenges, and arriving at similar solutions, was a fantastic reinforcement. It's easy to second-guess yourself when you're deep in the work, wondering if you're overthinking things or moving too slowly. But the pattern across companies was clear: the ones succeeding are the ones being thoughtful and deliberate.

The specific workflows where AI is proving valuable are more targeted than the broad "write all the code" narrative suggests. Code generation, yes, but in specific contexts. Migrations and transformations, where an agent can handle the tedious mechanical work of updating APIs or refactoring patterns across a codebase. Test generation, where AI can produce the scaffolding that developers then refine. Code review summarisation, where multiple agents can analyse changes from different angles and consolidate their findings into something actionable.

These aren't wholesale replacements of developer work. They're accelerators for specific, often repetitive tasks within the software development lifecycle. The difference matters. When you frame AI as a tool for particular jobs rather than a general-purpose developer substitute, you can start to measure and evaluate it properly. You can ask: is this agent actually helping with test coverage? Is this migration tool producing code that meets our standards? Is the review summarisation catching things human reviewers would miss, or just adding noise?

And that's where things get interesting, and a bit uncomfortable. Because while the productivity gains are real, some companies are starting to notice something else: a drop in code quality as the volume of AI-generated code increases. It's still early, the data isn't conclusive, but it's a pattern worth watching. The tools are excellent at producing code that works, less good at producing code that's maintainable, readable, and aligned with a team's existing patterns. Standards and quality remain as hard to measure as they've always been, but now there's an additional variable in the equation.

Something I predicted in my previous article is playing out clearly: code fungibility is increasing. Despite the volume of AI-generated code continuing to grow, the amount being replaced on a per-PR basis is also growing — diffs are getting larger, and code is being treated as more disposable. It's a trend that has real implications for how we think about maintainability and code ownership going forward.

Acceleration Without Compromise

The phrase "without compromising quality" gets thrown around a lot when talking about GenAI in development, but what does it actually mean in practice? From the conversations at the summit, it's clear that this is where the real work lies, and where many organisations are still figuring things out.

The reality is that GenAI works best as a productivity multiplier for tasks that developers already know how to do. It's excellent at generating boilerplate, scaffolding out tests, handling repetitive refactoring patterns. These are the areas where it genuinely shines, where the time saved is substantial and the risk is manageable. A developer who understands what good test coverage looks like can use AI to generate the structure and then refine it. Someone who's done a dozen API migrations can use transformation agents to handle the mechanical bits while focusing on the edge cases and architectural decisions.

But human judgement remains absolutely critical. Architecture decisions, system design, understanding the business context behind technical choices—these aren't areas where AI adds much value yet, and trying to force it into these spaces is where quality starts to suffer. The best implementations I heard about were the ones that were explicit about this boundary. They made it easy to use AI for the repetitive, well-understood tasks while keeping humans firmly in control of the decisions that actually matter.

Developer Experience plays a crucial role here. If your AI tooling is cumbersome, slow, or produces output that takes longer to review than it would to write from scratch, developers won't use it, or worse, they'll use it incorrectly. The platforms that work are the ones that integrate seamlessly into existing workflows, that respect developer agency, and that make it obvious when AI is helping versus when it's getting in the way.

The measurement question keeps coming up, and it's clearly something that the wider industry is still struggling with. How do you know if this is working? "Percentage of AI-generated code" is a terrible metric — it encourages quantity over quality and doesn't tell you anything about whether the right code is being generated. Better metrics focus on developer satisfaction, cycle time for specific tasks, and crucially, the quality of the output. Are bugs going down or up? Is technical debt decreasing or accumulating faster? These are harder to measure than lines of code, but they're what actually matter. It was refreshing to see the latest industry-led data from Laura Tacho at DX and how it correlates with what we're seeing from our own engineering teams at Booking.com — it's reassuring to know we're not alone in finding this difficult, and that the best approaches are converging on similar signals.

The Developer's Evolving Role

There's a lot of anxiety in the industry about what AI means for developer jobs, and I understand it. But the conversations at the summit painted a different picture than the "junior developers are obsolete" narrative you see in the press.

Skills are shifting, not disappearing. Yes, prompt engineering is becoming part of the toolkit, and knowing how to frame a problem to get useful output from an LLM is genuinely valuable. But it's not replacing the fundamentals; it's augmenting them. You still need to understand systems, design patterns, trade-offs. You still need the same foundations. In fact, you might need to understand them better, because now you're responsible for evaluating AI-generated solutions rather than just implementing your own.

Code review is becoming more important, not less. When a significant portion of code is coming from AI tools, the ability to quickly assess whether that code is good, maintainable, and aligned with your system's architecture becomes critical. This isn't a skill that junior developers typically have, and it's not one that AI can replace. The best code reviewers I know aren't necessarily the fastest coders - they're the ones who can spot problems, ask good questions, and understand the broader context of a change.

The pattern I've observed throughout my career holds true here: the best engineers automate away repetitive tasks so they can focus on where they add the most value. GenAI is just a new tool in that long tradition. What's changed is the scope of what can be automated and the speed at which it's happening. Developers who embrace this and figure out how to make the tools work for them will thrive. Those who resist or who rely on AI without developing the judgement to use it well will struggle.

Experience matters more than ever. Knowing what to ask for, knowing when the AI's suggestion is leading you down the wrong path, understanding the implications of architectural decisions — these come from years of building systems and making mistakes. The idea that AI will replace experienced engineers is particularly absurd when you consider that the tools are only as good as the judgement applied to their output.

Looking Forward

Flying back from San Francisco, I found myself reflecting on what made the summit valuable. It wasn't any revolutionary insight or dramatic announcement. It was the reassurance that comes from seeing other people grappling with the same challenges you are, arriving at similar conclusions, and sharing their learnings openly.

The difference between hype-driven adoption and thoughtful integration is stark when you see them side by side. Companies rushing to "do AI" because they feel they have to are building on shaky foundations. The ones taking the time to understand where these tools actually help, building proper platforms around them, and being honest about the trade-offs—those are the ones that will get lasting value from this technology.

We're still early in this journey. The hype cycle will eventually subside, as it always does, and we'll be left with whatever actually works. My sense from the summit is that GenAI will settle into being a valuable tool in the developer's arsenal—significant, but not revolutionary. It will change some aspects of how we work, make some tasks faster, and create new challenges around code quality and maintainability. But it won't replace the need for developers who understand systems, make thoughtful decisions, and know when to trust the tools and when to ignore them.

For now, I'm taking what I learned back to my work at Booking.com, grateful for the privilege of spending a few days with people who are thinking deeply about these problems, and optimistic about where we're headed—not because AI will solve everything, but because the industry seems to be moving past the hype and getting on with the actual work of making these tools useful.

And yes, it was absolutely worth the trip to San Francisco. Though I was very happy to get home to my family.