Did you know that roboticists don’t always build robots? We’ll get back to why that’s relevant, but first…
Let’s chat about what I learned during the 2026 Pragmatic Summit in San Francisco (hosted by Gergely Orosz), and how AI has sparked an existential crisis for some engineers.
Note: I say “AI” a lot in this article, but what I’m really talking about are Large Language Models (LLMs), and the myriad tools built around them: Almost everywhere I say AI, I could have easily said “Claude Code.”
Change Management
Organizations are constrained by human and systems-level problems. We remain skeptical of the promise of any technology to improve organizational performance without first addressing human and systems-level constraints.
We remain skeptical, and we remain human.
— Kent Beck, Laura Tacho, and Steve Yegge chatting at the Future of Software Development Retreat in Deer Valley, Utah.
AI is an amplifier: Depending on the team that uses it, AI can deepen their dysfunctional culture, or accelerate their high-functioning operations.
Laura Tacho (CTO of DX) shared a swathe of data reflecting this amplification, showcasing a DX study of ~121K developers across ~400 companies. In one cohort studied by DX, some organizations achieved 50% fewer production incidents, while others saw a twofold increase in incidents.
Nicole Forsgren (Senior Director of Developer Intelligence at Google) attributed this divide, in part, to the difference between adopting AI (”are we using AI?”) and engaging with it (”how deeply and effectively are we using AI?”).
An MIT report highlighted this divide last year, and Laura’s data reinforced it:
Adoption: 92% of developers use an AI assistant monthly, 75% use one weekly, and 26% of new production code is AI-authored.
Engagement: Onboarding time (between a developer’s 1st day and 10th code deployment) has been cut in half, and incidents are down 50%, at organizations engaging with AI effectively.
To stay on the positive side of this divide, Laura encourages teams to not only measure whether they’re using AI (“adoption”), but also whether it’s positively changing outcomes (“engagement”) and whether it’s economically sustainable.
“Organizations that win set goals and measure progress.”
— Laura Tacho, CTO of DX
From what I’ve seen working with AI organizations of all shapes and sizes, the biggest indicator of dysfunction is a lack of observability. Teams that don’t measure and validate the inputs and outputs of their systems are at the greatest risk of having more incidents when AI enters the picture.
Beyond metrics, Nicole emphasized that psychological safety is a prerequisite for AI adoption. Teams with high safety adopt AI tools faster, experiment more freely, and share learnings more openly.
Psychological safety goes beyond just AI: In my, and many others’ experience, the most high-performing teams have deep reserves of trust and safety within their cultures.
One of the best things we can do as leaders is to give our teams explicit permission to play with AI--and any new technology--and celebrate the learning that comes failures and successes alike.
Developer and Agent Experience
“The Venn diagram of developer experience and agent experience is a circle.”
— Laura Tacho, CTO of DX
When teams deeply engage with AI, a new problem emerges: The agent and developer experience.
The same things that benefit human developers--frictionless feedback loops, easy-to-navigate codebases, and straightforward execution environments--directly benefit agents.
However, that means developer experience debt is becoming AI adoption debt.
In her recent book, Frictionless, Nicole highlighted that the faster feedback loops of AI paradoxically make developers work harder. Thus, teams that have robust investments in the entire developer experience will find AI engagement easier and more sustainable.
In a world where AI can create anything in minutes, I believe the internal processes and systems that support developers will become a competitive “moat” for every organization.
What’s Your Value Proposition?
“I need to let go of my obsession with the craft.”
— Kent Beck, Creator “Rediscoverer” of Test-Driven Development
Thomas Dhomke (former CEO of GitHub) and Rajeev Rajan (CTO of Atlassian) claimed the real constraint of teams’ success will soon shift from engineering capacity towards product judgement.
This claim was reflected in a chat I had with Nicole about the overlap between the work of a founder--talking to customers, finding product-market fit, and identifying the real unmet need--and the work engineers need to take on.
Our conclusion: If AI can create everything we want, whenever we want it, we need to think hard about what we should be creating.
In her late-2023 article on GenAI and software delivery, Birgitta Böckeler highlighted the need to focus on product value, calling it “building the right thing” instead of merely “building the thing right”.
During their fireside chat at the Pragmatic Summit, Martin Fowler and Kent Beck observed this product focus “shrinking the middle” of engineering: Experienced coders who’ve built their careers on the craft of code, rather than the art of modeling business domains. These coders are at the highest risk of being displaced by AI.
In that vein, Vijaye Raji (CTO of OpenAI) and Tibo Sottiaux (Codex Engineering Lead at OpenAI) claimed the line between their own software engineers and product engineers is blurring. Thomas and Rajeev took it one step further, observing that many product managers are becoming product engineers.
In other words, everyone’s becoming a product engineer.
Documentation Over Code
“I don’t care as much about code—I care about capturing the intent behind it.”
— Thomas Dhomke, former CEO of GitHub and founder of Entire
If everyone becomes a product engineer, I expect we’ll see less of a focus on 1337-code, and more on modeling business domains and decomposing problems into value propositions that serve those domains.
This shift reminded me of a line from the Agile Manifesto: “Working software over comprehensive documentation”.
25 years later, we may finally see a slight inversion of the manifesto. Code is becoming much less interesting than documentation for engineers to manage.
What matters now is the intentions behind code: The conversations that created it, the context they happened in, the specifications that constrained them, and the reasoning and product concepts that inspired them.
Roboticists Don’t Always Build Robots
For a long time, writing code was a defining activity of software engineering.
But engineering is scarcely about how we create--it’s about why we create.
Though most of my work is in software engineering, I’m also a roboticist: I used to build towering robots for international competitions, and play with run experiments on swarms of hundreds of tiny robots.
One big part of robotics is mechanical engineering--AKA, building robots. But what does it mean to build a robot?
If I calculate the load requirements for a robot’s chassis, 3D model it, and then have it 3D-printed, did I build a robot? Or did the 3D printer build the robot?
Most people I ask seem to think I still built the robot, and not the 3D printer.
Like early 3D printers, I think AI is becoming fantastic for throw-away prototypes (“disposable code”), but perhaps less great for production runs (“durable code”). Last year, Charity Majors wrote a great article on this difference.
But today’s 3D printers are used for all kinds of production runs--including critical components in medical devices. As AI advances (I’m looking at you, Claude Opus), I think we’ll see a similar increase in the share of AI-generated code in production settings.
Now, if I craft the intent and design for a system, but AI generates the code to glue it all together, have I created a system? Or did the AI create it?
At least for now, I find that question is a bit like asking if a submarine can swim.
Interesting! Thanks for sharing the highlights from your time there. A couple of weeks ago I was speaking with a Head of Tech at a large scale company, and he gave me almost exactly this advice. He asked me to position myself at the intersection of product engineering and AI, because in his view the lines between development and product thinking are going to blur very soon.
This shift lands at the individual level. The organizational data is compelling, but for someone early in their career the question becomes more personal: what do I actually build toward now?
His framing stayed with me. He advised me that a mere "learn AI tools" was not enough, it was "develop the product judgment to know what's worth building in the first place." Reading this piece, especially the point about product managers becoming product engineers and everyone meeting in the middle, I think that advice was pointing at exactly this moment.
Still figuring out what that path looks like in practice, but articles like this make me feel like the direction is right.