Peter Steinberger dropped a bomb on The Pragmatic Engineer podcast last week. The creator of PSPDFKit, deployed on over a billion devices, just shipped 6,600 commits in January as a solo programmer using AI agents. The episode title alone tells you everything: "I Ship Code I Don't Read." https://www.youtube.com/watch?v=8lF7HmQ_RgY
For anyone paying attention to the AI coding wars, this interview is required listening. Peter's not theorizing about the future of software development. He's living it, at scale, right now. But while Peter and I agree on the fundamentals, we've arrived at wildly different conclusions about what "good engineering" looks like in the AI era.
Where We Violently Agree
Vibe Coding is Dead
Peter draws a hard line between engineers who adapt and those who don't. He's got no patience for the "just paste it into ChatGPT and ship whatever comes back" crowd. Neither do I.
I've been saying for months that there's a difference between vibe coding and actually using AI tools to ship quality software. Peter frames it slightly differently: product-focused engineers thrive while puzzle-solvers struggle. We're talking about the same divide.
Using AI to crank out test cases, catch bugs before clients do, and scaffold boilerplate? Working smart. Accepting whatever the LLM spits out and praying it works? Professional negligence with one extra step.
The Perfectionism Trap
Peter spent years obsessing over every spacing, every newline, every variable name at PSPDFKit. Bike-shedding. I call it the same thing, just with more expletives.
When you're managing a team, you learn fast that your perfect code isn't perfect to anyone else. The variable naming you agonized over? Nobody cares. The "correct" way to structure that class? Five engineers will give you nine opinions.
Peter learned this running a 70-person company. I learned it managing teams the same size, working for dozens of startups and deploying over 100 apps, and realizing the ones I shipped "good enough" are still running, while the ones I over-engineered are dead. Different paths, same lesson: perfectionism kills velocity.
Architecture Matters More Than Ever
Here's where Peter nails something most AI skeptics miss: code reviews are dead, but architecture reviews are everything.
When agents write your code, nobody's checking if you used the right Tailwind class. Instead, you're debating system design, data models, and whether this feature should even exist. Peter says, "I am the architect," and he's right.
I've been preaching boring deployments for the same reason. The complicated stuff (Kubernetes, microservices, custom deployment pipelines) doesn't make you more stable. It makes you slower and more fragile. The architecture decisions that actually matter are the ones about simplicity, not complexity.
Where We Part Ways
The "Ship Without Reading" Philosophy
Peter literally ships code he doesn't read. He treats PRs as "Prompt Requests" and iterates with agents rather than reviewing line-by-line.
I'm not ready to go there.
Maybe it's because I've spent 25 years debugging production disasters caused by code nobody understood. Maybe it's because I still wake up in cold sweats remembering the 2,000-line T-SQL query that only one person understood, and then that person quit.
I use AI to multiply my output. I use it to write dozens of test cases, scaffold database migrations, and generate boilerplate that would take me hours. But I read the code. I review it. I make sure I understand what it's doing before it hits production.
Peter compares working with AI agents to managing imperfect but brilliant engineers. Fair enough. But when I managed teams, I still reviewed their PRs. I still made them explain their decisions. I still caught bugs that multiple reviewers missed, because I actually looked at the code.
The Hiring Philosophy Gap
Peter looks for people who "love the game" and are "infinitely curious." He wants GitHub contributors who treat learning AI tools like mastering a musical instrument.
I want engineers who ship production code that doesn't blow up at 4 PM on Friday.
Maybe I'm jaded. Maybe after watching too many startups die because their CTO was more interested in the technology than the business, I've become allergic to "loving the game" as a hiring criterion.
I don't care if you love coding. I care if you understand the difference between a technically impressive demo and software that actually works. I care if you can take something from 90% to production-ready without turning it into a six-month refactoring project.
Peter's building Moltbot, the fastest-growing GitHub repo by star velocity. I'm deploying MVPs for founders who need to validate ideas before their runway ends. Different problems, different priorities.
The "Let AI Solve It" Mentality
Peter says most code is "boring data transformation" and that the really hard parts were solved by Postgres 30 years ago. He's not wrong, but here's what worries me:
I've seen too many companies treat deployment as an implementation detail. They build beautiful React components in Cursor, get 90% there, then faceplant on the unglamorous stuff: database connections, security, scaling, proper secrets management.
AI can write code fast. It cannot architect deployments, set up CI/CD, or explain why your AWS bill is $400/month for a hobby project. Those aren't puzzle-solving problems. They're experience problems. And I'm not convinced AI agents are ready to handle them yet.
When Peter says he doesn't care which Tailwind class is used, I agree completely. When he says the hard parts are already solved, I get nervous. Because in my world, the hard part is usually getting the damn thing deployed and keeping it running.
What This Actually Means
Peter represents one possible future: solo programmers wielding AI agents to ship at team scale, treating code as a commodity and architecture as the only thing that matters.
I represent a different path: using AI to multiply individual productivity while maintaining the discipline that keeps production systems stable.
Both can work. Neither is obviously wrong.
Most companies will probably end up somewhere in the middle. They'll use AI to accelerate development, but they won't ship code nobody's read. They'll let agents handle boilerplate, but they'll still require humans to understand the system architecture. They'll treat AI like a force multiplier, not a replacement for engineering judgment.
Peter might be building the future at Moltbot. Or he might be building an exception that proves the rule. We'll find out.
In the meantime, I'll keep using AI to write test cases, scaffold deployments, and ship faster. But I'll also keep reading the code, maintaining boring infrastructure, and remembering that the goal isn't to use the most advanced tools. It's to build software that actually works.
Because whether you ship 6,600 commits or 66, what matters is whether the thing runs in production and solves a real problem.
The rest is just bike-shedding.
-Sethers
