This edition is the second in a series of periodical articles chronicling the things I’m learning and creating right now—I’m still finding the right name, cadence, and scope of content to include, and want your feedback!

Subscribe now

Volume as a Proxy for Productivity

A colleague recently shared an article with me about output-competence decoupling: It’s the idea that the quality (and perhaps quantity) of a work is no longer a reliable indicator of its producer’s competence.

My favorite excerpt from the article:

I’m seeing this exact failure mode of AI-generated content every day in my own work. So often, someone gives me a ten-page document with content equivalent to ten concise bullet points.

I wish they’d just given me the bullet points.

I’ve been tempted to say the root cause is people using AI to generate docs, but that isn’t quite it. I think a skilled writer can use AI and produce fantastic work.

Instead, I think it’s an issue of empathy.

Writing is not the act of generating text. Writing is the process of creating text with empathy for a reader, in large part by having understanding and accountability for what’s being written.

When someone delegates their writing to AI on a new topic or for a new audience, they rob themselves of the experience of writing—of the opportunity to create a meaningful work.

Increasingly, if anyone gives me a long-winded document for human consumption, I insist they take the time to rewrite it by hand—even if they’re just paraphrasing the AI—so that they internalize and understand what they’re writing about, and ensure I read exactly what they want me to care about.

The Trust Factory

I believe products created with empathy are more valuable to whoever interacts with them. But more than value, empathy also builds trust.

Last week, Kent Beck wrote about the Trust Factory—about how we (as engineering teams) are accumulating code faster than we’re accumulating trust.

With so much of engineering work happening in “single-player” (engineers creating code with AI with minimal interaction with other engineers), the interactions that once built trust within teams are fading.

The answer to this problem of trust is still murky. However, I think it’ll start with slowing down: In the same way I think it’s important to hand-write (certain) docs intended for humans, I think it’s important to still be hands-on with (certain) code intended for production.

In a recent experiment I did while building a personal project with minimal AI help, Opus 4.7 generated 3x as much code as my hand-written implementation—and it concurred that my version was better. The root-cause seemed to be a lack of long-horizon thinking from the agent, which is a consistent problem.

I’m very optimistic about how these AI “Genies” (as Kent calls them) can take over the boring parts of coding, particularly where the human cost of failure is low.

But I’m not quite at a point where I would entrust my or my team’s reputations to the outputs of these coding agents.

Enthusiastically Skeptical Feedback Loops

Also last week, published an article breaking down the breakdown in trust between AI optimists and AI skeptics.

Within the software engineering discourse, there are two big camps of thought:

• AI optimists, who are excited about the value they can unlock with AI.

• AI skeptics, who worry about what happens after that value is unlocked.

As Charity so perfectly notes:

I think the right answer is somewhere between skepticism and optimism.

It’s easy to be a fervent skeptic. Particularly when you see Claude produce 3x as much code as you, 3x as fast.

But it’s just as easy to feel optimistic: Just weeks ago, Claude was able to review one of my distributed consensus patents, and identify a slew of improvements and corner cases I missed in the original specs.

Part of the challenge is that optimistic voices are everywhere right now: Back in March, Rathin Shah on X shared his takeaways from nearly 200 Y-Combinator pitches. 60% of the pitches were AI-first, while only 14% of the pitches had no AI.

I’m not sure which camp I fall into: I’ve been working in AI engineering since before ChatGPT was a thing, and before that I operated some of Wayfair’s most valuable production infrastructure (advertising…) where AI’s unreliability would be a liability. I’ve experienced the limits of what AI can do, but also the benefits it unlocks when used well.

Right now, my personal take is that AI is perfect for situations where the problem is intractable or desperately boring for a human to solve, and where the human cost of failure is low.

In other words: I’d happily vibe code a prototype for any app, ever. But if I’m building a system that could cause substantial loss of revenue—or worse, loss of life—I would prefer to use AI as a partner, and not as the principal creator.

Speaking of substantial loss of revenue…

The Human Cost of Failure

Charity’s analogy of feedback loops reminded me of my first production incident at Wayfair.

My staff engineer mentor and I had just finished running a load test of a new distributed data processing pipeline. I was quite proud of it. It was the first time I got to put my theoretical knowledge of distributed computing to the test, and it worked marvelously: Millions of ads for millions of products were generated in under an hour, beating the existing solution by an order of magnitude.

The funny thing about ads is that they need images, and the not-so-funny thing is that (at that time) all images at Wayfair were served from an existing service monolith (which supported the vast majority of our back-end workloads).

In short, our shiny new pipeline denial-of-service’d the Wayfair monolith for an hour, and brought many internal workloads to a halt. It was my first P1 incident.

During the ensuing post-mortem, I gained a deep appreciation for observability and site reliability engineering as a discipline. But I learned something else, too.

For the hour that our systems were down, our frontline support teams couldn’t do their jobs. Because their performance hinged, in part, on how many tickets they fielded, their compensation was directly impacted by my team’s mistake.

Through this incident, I learned the human cost of our systems’ failure. A cost that I couldn’t see from my ivory tower while I was blazing a trail of innovation.

Since then, whenever I’m building or rebuilding a system—with or without AI—my first question is always “Who cares about this system?”

This might seem like a silly and fundamental question, but every system we build (whether directly or indirectly) serves a human purpose.

For decades, we software engineers have benefited from the prestige of professional engineers’ titles (think: people who design bridges). However, we’ve not consistently taken on the mantle of responsibility that comes with this title.

Ergo, I believe the purpose of a software engineer is not merely to produce code—it’s to be accountable for our systems’ purposes, and the lives impacted by them.

What’s Next

---

Last month, I published my first article after a months-long break working on my mechanical sympathy article with Martin Fowler: Defining Innovation. Next week, I’ll be publishing a follow-up to my innovation article chronicling my takes on AI’s impact on open source.

Also: Twice a year, I create a game from scratch in a weekend. This April, I created my third game (”in:frequency”). Why not give it a try in your web browser, and read about how I made it, in this behind-the-scenes article?

Acknowledgements

---

Queenie Ho, for sharing with me the delightful quote from Joanna Stern’s book “I Am Not a Robot: My Year Using AI to Do (Almost) Everything”.

---

During my editing process, I used Anthropic's Claude Opus 4.8 to review my drafts for grammatical errors, and to give feedback on the structure and accuracy of my claims. AI was not used to generate any text.

That’s Bananas

Let’s start with an analogy of bananas.

Bananas growing on a tree are very much like novel inventions: Fascinating to look at, and potentially useful…but not immediately valuable.

The cost for someone to harvest one banana is small (picking it from the tree), and the benefits are similarly small (briefly sating hunger). If we define value as benefits over costs, “small over small” isn’t particularly valuable or innovative.

But if someone comes along and finds a way to harvest and distribute bananas for sale to customers in markets across the world—particularly markets where bananas don’t naturally grow—the bananas become quite valuable.

Delivery is central to innovative value creation: The same banana that’s worth $0.50 in a market can be worth $6,000,000 when taped to a gallery wall.

Innovation isn’t the banana itself. It’s in who you deliver it to, and how.

Inventions Aren’t Innovations

Innovation is the delivery of a novel solution to a customer, which creates value by providing benefits in excess of costs, in a way that’s superior to alternatives.

Inventions are often conflated with innovations. Most innovations involve an invention, but few inventions are by themselves an innovation.

Here are some examples of inventions and the innovations they led to:

• Touchscreens were invented in the 1960s, but only became innovative when packaged up and delivered as part of the first iPhone in 2007.

• The computer mouse was invented in the 1960s, too—but wasn’t innovative until it enabled Apple’s (then revolutionary) graphical user interface for the Macintosh in 1984.

Most recently, the transformer architecture (the foundation of most large-language models today) was published in Google’s now-famous 2017 paper, “Attention Is All You Need.”

While transformers enabled spectacular progress in AI research, they weren’t widely recognized as an innovation.

Not until ChatGPT packaged up a transformer model—the Generative Pre-trained Transformer (GPT) 3.5—in an accessible, web-based chat interface that enabled users across the world to ask the AI questions.

Today, I’d be hard-pressed to pick a bigger innovation of the 2020s than ChatGPT.

Now for the practical bit: How can you create valuable innovations of your own?

The NABC Framework for Value Creation

In 1998, the Stanford Research Institute (SRI) was on the verge of bankruptcy.

Over the next 16 years, SRI tripled in size, creating a range of innovations like Siri and the da Vinci Surgical System. What happened?

When Curtis Carlson joined SRI as its CEO in 1998, he drove a cultural transformation for the company.

This transformation was driven by the NABC framework, which tasks inventors with answering four questions:

• Need: What’s the most important thing to the user and the market?

• Approach: What’s your unique approach, and your key insight into the need?

• Benefits: What is the value to the user, in terms of the benefits over the costs?

• Competition: How does the value differ from alternative approaches?

These answers are combined with an attention-grabbing hook and a call-to-action to form a complete NABC Pitch, tailored to a specific stakeholder.

Using the NABC Framework

I’ve the rare privilege of calling Curt my mentor. For more than two years as part of my innovation fellowship at Worcester Polytechnic Institute, Curt met with me (and multiple other founding teams) weekly to drill us on our NABC pitches.

To give you an idea of what this framework can produce (with enough iteration), here’s a subset of actual slides from the last deck I created and pitched with Curt:

To me, the most important part of an NABC pitch is the key insight: The idea that connects the need and the approach.

In the example pitch above, our key insight was twofold:

1. Most engineering work is “plumbing” data between formats and systems.

2. Most API failures happen because of this plumbing, and the rest happen because of centralized cloud outages.

We realized a decentralized platform with a unified data model could solve both problems simultaneously, and thus Alicorn was born.

Unfortunately, Alicorn struggled to become innovative: We had no delivery mechanism apart from open source, which is notoriously tricky to commercialize—though that trickiness is a subject for a future article.

Wrap-Up

So, are LLMs innovative? I argue no. The real innovation is in the products that package them and deliver them to customers in ways nothing else can.

What invention have you been treating as the destination, when it’s actually the start of your journey towards an innovative product?

I’ve traveled to more places and created more things in the past few months than I have in the past few years--yet none of it’s on Substack!

To break that tragic streak, I’m launching a series of periodical articles aggregating the things I’m learning and creating to bridge the gaps between my longer-form articles.

In this edition: Writing about Mechanical Sympathy with Martin Fowler, reading Crisis Engineering, and exploring how people in tech hubs are using AI.

Writing With Martin Fowler

I’ve spent the past three months working with Martin Fowler on an article about a topic near and dear to my heart: Mechanical Sympathy.

This article represents a special milestone in my story: Martin was the first creator I followed when my software engineering journey began, and mechanical sympathy was the first concept I learned about from his writing.

His writing, and the concept of mechanical sympathy, would go on to shape much of my early career--from my university theses and patents on distributed systems, to the AI and microservices training I developed for Wayfair.

But I digress--here’s the abstract:

Modern hardware is remarkably fast, but software often fails to leverage it. Mechanical sympathy - a concept borrowed from racing and popularized in software by Martin Thompson - is the practice of creating software that is sympathetic to its underlying hardware.

This practice can be distilled into a set of everyday principles: Predictable memory access, awareness of cache lines, the single-writer principle, and natural batching. Together, these principles can be used to optimize everything from an AI inference server to a distributed data platform.

Go read the article on Martin Fowler’s site.

As a fun aside: My last article even made it into Martin’s “Fragments” series!

Reading About Crisis Engineering

Since its release ~10 days ago, I’ve been fervently reading “Crisis Engineering”.

This book was written by Layer Aleph, a small team who’ve solved some of the biggest systems failures you have--and have not--heard of.

Though the title might seem dramatic, I’ve found it rather fitting. They define a crisis, roughly, as the short window of time when the critical thinking part of our brains (“System 2”) is able to reprogram the autopilot part (“System 1”).

While the book is, quite literally, about leveraging crises as catalysts for radical change, it is so much more--it also teaches ways of thinking about systems regardless of the state they’re in.

I’m only ~40% of the way through the book, so I’m sure I’ll have more to share in the coming weeks. But I already consider it essential reading for anyone who works on or within complex systems--which is everyone today.

Exploring Innovation in Tech Hubs

Since the start of the year, I’ve traveled to San Francisco, Seattle, and New York City. Something all these places have in common: My friends live there, and they’re major innovation and product development hubs.

These trips have given me several articles’ worth of content, but there’s a theme: AI is enabling anyone to build products at a rapid pace. My core hypothesis is that the only way to differentiate products in a market that’ll be flooded with them will be a strong value proposition.

But what does a good value proposition look like? Inspired by my travels, I published my first evergreen article on the NABC framework for value creation.

When I first learned about this framework, I had my doubts: “Can you really create a rigid discipline around something as unpredictable as innovation?” After several years of practicing this framework, I’ve decided: You can.

This is the framework I use whenever I’m evaluating a startup or pitching an idea to somebody.

What’s Next?

This weekend I’ll be competing in the 59th biannual Ludum Dare event: I’ll be creating a video game from scratch in ~72 hours. I’m sure I’ll have some fun learnings to share, but in the interim, why not try my most recent game in your browser, or read about the first game I made?

Let’s chat about what I learned during the 2026 Pragmatic Summit in San Francisco (hosted by ), 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

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.

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

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?

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

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.

So, instead of resolving myself to some specific goal that just might run away from me, I love setting a theme for the year. In the form of display resolutions.

Creating Games

In 2025, my resolution was 160x144--the display resolution of the original Game Boy. My theme for the year was to create interactive media (mainly games) and to meet as many new and interesting people as possible.

Layered

In April, I participated in my first game jam--solo--and created "Layered", placing 529th out of ~1,600 entries.

Layered was incredibly fun and satisfying to create, and it was my first dip into the unending ocean of creating games. Because I was creating it for fun, I had every excuse in the world to use my own game engine.

I write more about the details in my post-jam article (I used Rust, btw), but my favorite part about creating this game was figuring out how to render “waves” in real-time that would be affected by walls. Here’s an excerpt from the article explaining how I got “wave occlusion” working:

To solve this issue, during each frame, I use my naive ray casting to find all tiles between each tile on the “wave front” and the threat origin. If any of these tiles contains an obstacle, that section (tile) of the wave front is marked as “occluded”, and doesn’t get rendered.

Though simple, this logic results in a fairly convincing illusion of sections of the wave being “deleted” or occluded by obstacles.

Open Sauce

In July, I went to my first Open Sauce in San Francisco, meeting and getting inspired by countless creatives, game developers, and system builders. Of course, no visit to the Bay Area (for me) would be complete without seeing the redwoods for myself with my friends.

One of the favorite connections I made was with the team at Owl Integrations who created the fantastically-named ClusterDuck Protocol, and mailed me several of their LoRa units for testing (if you’re reading this: I still owe you some demos in 2026…).

Recollect

In October, I participated in my second game Jam--still solo--and created "Recollect", skyrocketing to 60th place for "Mood", 82nd for "Audio", 139th for "Innovation", and 397th overall out of ~1,400 entries.

What I enjoyed most about this jam was creating my own audio for the very first time--it was tricky, but I figured out how to create a custom MIDI engine within my game engine so I could have frame-perfect synchronization of audio to visuals.

This custom engine enabled me to create a series of audio tracks that build on each other, and physically affect the game world as you explore it--why not try it for yourself in your web browser? You can also check out some of the source code here.

Creating Writing

Though much of this article has been about creating games, meeting people, and stalking the redwoods, that’s not all I do.

For the past year, I’ve been a Principal AI Engineer for a consultancy called Thoughtworks.

Before that, I led key parts of Wayfair’s advertising data platforms (I know, please forgive me) and AI platforms. I’ve founded startups and advised numerous enterprises (big and small), and received a few patents and NSF funding for my work in distributed computing. So far, the systems I’ve created have driven around $3B in value for their owners.

I’ve done a lot. But what I haven’t done in a while is write.

Despite majoring in rhetoric and writing (and systems engineering (and entrepreneurship)) in university, the last time I wrote something substantial for the public was the first time I wrote a book on interactive media (more than a decade ago now).

This Year’s Resolution

All this lead up brings me to my resolution--my theme--for this year: 1748x2480.

1748x2480 is the resolution of a piece of A5 paper when it’s printed at 300 DPI. This particular configuration is one of a few standard (ish) sizes used when printing books.

While I don’t plan to publish a book again this year, my theme for the year in general is writing--or rather, communicating.

I intend to take more time throughout this year to write about the exciting things I’m creating, the fun people I’m doing it with, and the most interesting lessons I’ve learned along the way.

This is Chats With Caer

If you enjoyed reading this article--or at least, enjoyed any of the many topics I’ve brushed on in this article--why not subscribe, and follow along with me on my journey through 2026?

I’d love to chat with you, too.