The central theme of LeadDev Berlin 2026 was that code production is beginning to outpace the organizational judgment and customer learning available to many companies. I’m filled with gratitude as I reflect on my time there. It was a wonderful group of engineering leaders all wrestling with the seismic shifts happening in our industry around AI.

For my own direct participation, I had a blast chatting with Meri Williams, Sayak Saha, and Rachael Wonnacott on a panel about the role of software craftsmanship in the age of AI. My favorite part of our discussion was on how junior engineers develop a sense of craft in an AI world. Rachael highlighted the importance of getting depth early and the role that AI can play there. I really liked the tactical piece wherein we can review Claude transcripts after the fact, which can more easily surface misconceptions or gaps in knowledge than the rendered output does.

Michael Hill led a discussion with me, Laís Oliveira, Bartosz Ocytko, and Shadi Sharaf about how folks can prepare for the role of Principal Engineer. I also had a great principal engineer peer hangout session with Bartosz, Shadi, Laura Ureche, and Laís (among others who also joined).

Standout talks#

Escaping the AI Speed Trap#

I loved Laura Tacho’s talk “Escaping the AI speed trap” where she talked about measurement. The framing of “measurement as codified strategy” was choice. She also shared her mental framework for measurements in the acronym PACT.

  1. Purpose: Is there a goal or is it just easy to measure?
  2. Audience: Who is looking at these metrics?
  3. Cadence: How often are they being collected and reviewed?
  4. Tension: Are tradeoffs visible? Does it tell me what not to do?

I especially liked “audience” as a frame as I tended to think of metrics as sort of a fractal/KPI-tree type structure.. rather than just a set targeted to specific audiences.

Her talk was also the first time I’d heard someone point out the incongruity between the AI dark factory (where you give a Jira ticket/problem to the AI and it solves it autonomously.. which people seem excited about) and a feature factory (which people seem to think is bad).

Great Debate: Are we measuring what AI produces, or just how much of it we’re using?#

Randy Shoup led a great discussion with Kimberly Schmitt, Laura Tacho and Brenn Hill. Brenn called out that he’s seeing that engineers are expected to go 10x faster, but the organization isn’t actually set up to allow that to happen, which causes frustration and burnout. Laura talked about how releasing the coding bottleneck has revealed that folks aren’t as good at strategy as they might think. When given the opportunity, they just spam code rather indiscriminately. This is further exacerbated by the fact that many companies aren’t good at talking with customers to figure out what to build.

Acceleration with AI#

Darragh Curran (Fin CTO) gave a talk claiming that engineering leaders aren’t taking the disruption that AI brings with enough gravity. While his talk had lots of numbers and a compelling narrative of improvement, that wasn’t quite what stood out. The hardest part of their transformation seemed to be finding an executive who was willing to jump in with both feet and eyes open. The commitment to wholeheartedly try it out (even if it was eventually determined to be wrong) seems impossible in some organizations.

I also really loved his phrasing of “attack coarse goals”, wherein he describes picking somewhat arbitrary, blunt, but directionally correct goals and going after them aggressively.

Talks I missed but want to see#

Themes#

AI SDLC#

There were many folks asserting that they have made great strides in the AI SDLC.

Dave Loker (VP of AI for CodeRabbit) talked about how 90% of their code now ships without human review, while their revert rate has dropped by 4x. In particular, I liked his quote “Trust used to be a side effect of effective code, now you have to build it”. Their work is primarily focused on AI code review as a significant tool to ensure this trust. I’ve been looking at the CI/CD portions of the quality/trust of AI output on the software observatory.

Roman Musatkin (Head of Product for Swarmia) had a quote: “build before you prioritize”. In the highlighted example, he described a meeting where the engineer just implemented the code rather than going through a lengthy debate. I’ve seen this in my own work where Mohsen Bostan shipped a service as a proof-of-concept just to fix the logjam of a discussion about how to do something at my day job. This is in clear tension with what Laura said earlier around spewing software because implementation is inexpensive. I think the underlying difference is a distinction of how we use the code. We now have more access to experimental/prototypical software to prove a point or explore an idea behind the disagreement. It’s much easier to settle a debate if you can just implement it in both ways in less time than the 1-hour meeting.. then schedule a 15-minute discussion about which path to take. It’s worth mentioning that this doesn’t answer all questions, especially those around maintenance, costs, and customer demand.

Bhavana Hindupur talked about the tactics they used at Airbnb to make sense of AI-authored code, especially how to make the output coherent with the global whole. The big standout for me in this was that AI will copy the patterns it sees. This puts a disproportionate emphasis on removing negative patterns from your existing code, else they will propagate throughout.

Reflections#

Walking into the conference, I felt like I understood the broad strokes of the problems we faced and had some directional ideas for what we should do about it. The discussions I had highlighted potential I hadn’t considered and gave a useful change in perspective. I’m so excited to figure this puzzle out with all of my industry peers.

During the conference, I saw a lot of folks who are platform-oriented pushing the narrative that the future is platforms. They believe a great lever of the moment is to make the production of software more effective and efficient. As one of these people, I believe this is true.

There’s a second, less discussed side. I think a different pathway is that of product engineers. Instead of working on the efficiency of the platform as the means to impact, they’re iterating even more closely with customers. I think this is a fascinating area of exploration: AI code is so fast and inexpensive, we can iterate with much lower latency with our customers to get rapid feedback. I’m thinking this tighter feedback loop will allow us to build something more delightful in less time overall.

One thing I hadn’t considered until Laura Tacho mentioned it is that these programmers working closely with customers might not be traditional software engineers at all. They may be the domain experts who used to depend on engineering teams and now have coding tools of their own. What changes in our world when those with the most tacit knowledge of their problems are equipped with tools to directly explore solutions without needing to convince a dev team to work on it? How do we then take that exploration and transition it to working, production-grade software?

Either way, the bottleneck has moved: it’s no longer writing the code, it’s knowing what to build and finding out fast whether we were right.