davidpoll.com
Building systems, writing about engineering, and learning in public.
Posts
-
Code Review Is Not About Catching Bugs
Continue reading →My former Parse colleague Charity Majors – now CTO of Honeycomb and one of the strongest voices in the observability space – recently posted something that caught my attention. She’s frustrated with the discourse around AI-generated code shifting the bottleneck to code review, and she argues the real burden is validation – production observability. You don’t know if code works until it’s running with enough instrumentation to see what it’s actually doing.
She followed up by endorsing Boris Tane’s piece arguing that the entire SDLC is collapsing, with monitoring as the only stage that survives. Boris goes further than Charity – he argues the pull request flow is a relic, that human code review should become exception-based, and that clinging to it is “an identity crisis.”
She’s right about that. And I’d go further: if your primary strategy for knowing whether code works is having other humans read it, you have bigger problems than AI-generated code.
But I think the “code review is the bottleneck” crowd and the “no, validation is the bottleneck” crowd are both working from the same flawed premise: that code review exists primarily to answer “does this code work?”
To be fair, finding defects has always been listed as a goal of code review – Wikipedia will tell you as much. And sure, reviewers do catch bugs. But I think that framing dramatically overstates the bug-catching role and understates everything else code review does. If your review process is primarily a bug-finding mechanism, you’re leaving most of the value on the table.
-
The Temporary Ignorance Superpower
Continue reading →I’m about to start a new role leading a team I’ve never worked with. After a decade at Google, I’ll be the person who doesn’t know where anything is again.
I’m genuinely excited about that.
There’s a window when you join a new organization – maybe 90 days, give or take – where being new is actually a superpower. You can ask the questions everyone else stopped asking years ago. You can wander into long-standing debates and poke at assumptions without anyone assuming you have an agenda. “Don’t mind me, I’m new here” is a surprisingly effective shield for what would otherwise be career-limiting curiosity.
I’ve come to think of this as the temporary ignorance superpower, and I’ve learned to use it deliberately.
-
The Constraints That Create Autonomy
Continue reading →The conventional wisdom about autonomy is simple: remove constraints. Get out of people’s way. Let them figure it out. Trust them to run.
But this often backfires in a specific, predictable way. Teams think they have autonomy. What they actually have is ambiguity.
-
Orderly API Evolution: How to Break APIs Without Breaking Trust
Continue reading →I spent my baby bonding leave this summer with my newest kid — which was the point. But between feedings and naps, I also found myself trying to deeply understand coding agents and the new developer landscape. I wanted to see where this was all heading.
Building MCP servers was one of the experiments that surfaced something I hadn’t fully appreciated: MCP servers have wildly different audiences with wildly different expectations.
Consider the use cases:
- An end user uses a chatbot hooked up to an MCP server to accomplish some task
- A developer uses their coding agent hooked up to an MCP server to help them build something
- A developer builds an agent that uses an MCP server to accomplish something useful, potentially entirely under the hood
- A developer uses an MCP server’s tools directly as an API, bypassing the agent layer entirely
Not all of these may be good ideas, but Hyrum’s Law applies: with enough users, all observable behaviors will be depended on by somebody. That’s an overloaded interface. And when you start thinking about versioning an overloaded interface, suddenly questions like “what constitutes a breaking change?” get a lot messier.
-
The Difficulty Cliff: Why Building Software Has Never Been Smooth (Until Maybe Now)
Continue reading →How every abstraction in software creates walls, and why AI might finally demolish them
The learning curve for building software is a lie. It’s not a curve at all—it’s a jagged mountain range with sheer cliffs where the trail suddenly ends.
You’re cruising along with your no-code tool, dragging and dropping your way to success. Everything’s great until you need that one custom calculation, that one specific integration, that one behavior the platform didn’t anticipate. Suddenly you’re not climbing anymore—you’re standing at the base of a cliff, staring up at “real” programming.
Welcome to the difficulty cliff. After so many years building developer platforms, I’ve come to believe these cliffs aren’t bugs—they’re the fundamental challenge of software abstraction. Every tool that makes development easier eventually hits a wall where its abstraction breaks down.
But what if AI could finally smooth this curve? Not by building better walls, but by eliminating them entirely?
subscribe via RSS