The Bit Shift

The Border Station

Fri, 25 Sep 2026 00:00:00 GMT

The train from Antwerp crosses the Dutch border on the left-hand track, waits at a signal in Roosendaal, then slides across to the other track and carries on to Rotterdam. Belgian trains run on the left. Dutch trains run on the right. Both countries drive their cars on the right, and in nearly two centuries this has confused precisely nobody, because a train and a car have never once had to agree on anything.

Belgium runs left because the first line opened in 1835 (opens in a new tab) with three locomotives shipped from Stephenson’s works and two Belgian engineers who had gone to England to learn how it was done and copied what they saw. The reason was gone within a generation. The convention stayed. It’s still there under every commuter in the country.

We’d call that technical debt and open a ticket.

When two parts of an estate disagree about something structural, the reflex is to pick a winner and normalize. Same error envelope everywhere. Same retry semantics. Same date handling, because it’s embarrassing that the billing service and the reporting service still argue about what a month is. The project gets a name. It gets a quarter. It usually gets a second quarter.

What the railways worked out is cheaper. The inconsistency is real and permanent, and it can’t travel. The whole price of disagreeing gets paid at three crossovers on Dutch soil, a signal in Roosendaal, a flyover south of Rotterdam, and one at Maastricht that nobody outside the signalling office thinks about.

That price isn’t nothing. Somebody has to know both rulebooks and be awake at the seam when it goes wrong. But it stops there. Belgium never had to change. The Netherlands never had to change. Somebody built the crossovers and went home.

AI flipped the math on the windows that were actually broken. It didn’t flip anything here, because there was never a bill to pay.

An inconsistency that can’t leave its own network isn’t debt. It’s geography.

Ask that before the normalization project gets funded. Does anything actually have to cross between the two halves, and what does it cost to handle it right at the crossing instead of everywhere at once? Sometimes the glass genuinely needs breaking. Most of the time you need one crossover and the discipline to stop.

Consistency is what you buy when containment isn’t available.

Nobody Asked You to Read It

Fri, 18 Sep 2026 00:00:00 GMT

The implementation took an afternoon. The review took most of a week. I have stopped being surprised by that ratio and started being annoyed by the reason we all give for it. Someone has to be accountable. A human has to look at it and say the words. That is the rule, and the rule is why work now sits in review longer than it took to build.

I went looking for the rule. It does not exist, not in the form anybody means. There is no statute, standard, or framework in general commercial software development that requires a human being to read the lines of a change before it ships. What the regimes that actually bind you ask for is something narrower and much cheaper to provide: a documented control that operated, and a named person answerable for the outcome. We have been paying for the expensive version of a requirement nobody made.

Does the EU AI Act require human code review?

The EU AI Act comes up first in every one of these conversations. Its human-oversight duty is Article 14 (opens in a new tab). It binds high-risk AI systems, and what it asks is that a person can oversee such a system while it runs, understand its output, override it and stop it. It has nothing to say about using a coding assistant to write an ordinary service. If you are building a system that screens job applicants, you are in scope for what that system does. You are not in scope for how you typed it.

The high-risk obligations are also not live yet. The Digital Omnibus on AI (opens in a new tab), adopted in July 2026, moved Article 14 and the rest of the high-risk requirements out to December 2027 for standalone high-risk systems and August 2028 for the ones embedded in regulated products. The stated reason was that the standards and the national authorities were both late.

Two provisions come close. Paragraph 5 of Article 14 does mandate human verification, but only for remote biometric identification, where at least two trained people have to separately confirm a match before anyone acts on it. Unless it is a policing or border case, where the law can decide that is disproportionate. And Article 17 (opens in a new tab) requires a quality management system covering design control, design verification and development, for high-risk systems only. That one makes your verification process an auditable artifact. Neither provision says a human must read the code.

The new Product Liability Directive (opens in a new tab) is the better guess and it is still the wrong one. For products placed on the market from 9 December 2026, software is explicitly a product and whoever develops it can be treated as a manufacturer. That sounds like it lands squarely on this argument until you notice it is strict liability. Defect, damage and causation are the elements a claimant has to prove. Negligence is not one of them, so nobody needs to show your team was careless.

Your review practice still does evidential work on whether the product was defective, but you are not liable for the practice itself. And the damage anyone can actually recover stops at death, injury, physical property and data you were not using for work. That leaves out pure economic loss, which is most of what software failure costs.

So the two instruments everyone reaches for are the wrong ones. The regimes that do set a standard for process turn out to be on your side.

What PCI DSS and SOC 2 require

PCI DSS (opens in a new tab) requires that bespoke and custom software be reviewed before release. Requirement 6.2.3 also says those reviews may be performed using manual or automated processes, or both. The additional conditions about a reviewer who is not the author, plus management approval, hang off 6.2.3.1 and the manual path specifically. A mainstream compliance regime, in force today, already accepts automated inspection plus a documented named approver in place of a human reading the code.

A SOC 2 auditor does not read every change. They request the population and sample it (opens in a new tab), sized to how often the control runs and how big the population is, which for something as constant as change management runs to a few dozen items. No standard sets that number, which is its own tell. Then they test whether the control you described actually operated on the ones they picked. The object of proof is the control, not the code.

Intercom did the sensible thing and asked before scaling rather than after. They engaged their auditors early, across SOC 2, HIPAA, ISO 27001 and ISO 42001, and published what they were told (opens in a new tab): the evidence an auditor expects to see is the same whether a human or an AI approved the change.

The product changes that caused outages in their past were all reviewed and approved by humans. Human review was never a guarantee of safety. It was a guarantee of attribution.

How the Linux kernel handles AI-assisted patches

The Linux kernel is not an organisation anyone accuses of moving fast or trusting machines. Agreed at the 2025 Maintainers Summit and merged in January 2026, its convention for AI-assisted contributions (opens in a new tab) is one line long, and it is the cleanest thing anyone has written about this.

An Assisted-by: trailer discloses that a model helped write the patch. The human still adds their own sign-off, because only a human can certify the Developer Certificate of Origin, and the human takes full responsibility for the contribution. The original proposal used Co-developed-by (opens in a new tab), and the maintainers replaced it, because that tag implies a collaboration between authors and this is assistance. Tools are disclosed, not credited.

They went further in 2026 and stopped recording which model was used (opens in a new tab) at all, on the stated grounds that naming it hands free advertising to proprietary vendors while adding nothing useful. The trailer is now just Assisted-by: LLM. I find that more interesting than the original rule. What they wanted was the fact of assistance and a human willing to sign. The identity of the tool turned out to be noise.

Authorship became machine-readable. Accountability stayed human. The most conservative review culture in software worked out those are two different properties and wrote it down in a paragraph.

Does human code review actually catch bugs?

If the law does not require line-by-line reading, the fair question is whether it works anyway. Meta published the largest answer anyone has put numbers to, in May 2026.

Their system auto-approves low-risk changes behind a risk score, hard exclusions, and a model reviewer that has to state its own confidence (opens in a new tab), and at its peak it handled twenty-five thousand changes a day.

331,720 changes landed on the machine’s approval, out of 535,290 it inspected

1/3

the revert rate of the diffs it did not handle

1/50

the incident rate of the diffs it did not handle

25,000

changes a day at peak

Meta’s automated code review, reported May 2026. The two rate comparisons are against the diffs the system did not handle, which are not a matched group. Of the production incidents that did get through, domain experts judged that none would have been caught by a human reviewer. The paper does not say how many incidents that was.

The rate comparisons are the weaker half of that. The system takes the lowest-risk slice by design, so of course the diffs it handles go wrong less often. The finding no comparison group can rescue is about the incidents that did get through:

All PIs were manually reviewed by domain experts and none were deemed to have been detected by a human reviewer.

Examined afterwards by the people best placed to judge, no incident would have been caught by the reviewer whose approval everyone was waiting for. The paper never says how many incidents that was, which is the one number I wanted and could not get.

Bacchelli and Bird (opens in a new tab) saw the same gap at Microsoft in 2013, well before any of this. They watched seventeen developers across sixteen product teams, then hand-classified five hundred and seventy comments drawn from reviews across dozens of Microsoft products. Developers named finding defects as review’s purpose. Defects came fourth out of nine categories. What dominated was code improvements, and after that, people asking what the change was even for.

I used to read that as an indictment, and I now think that is the wrong reading. Those comments are not a failed search for bugs. They are somebody holding a codebase together and teaching the person who wrote the change, and the paper says so directly, listing knowledge transfer and alternative solutions among the outcomes it actually observed. AI did not break code review. It raised the volume until the pretence that review is a defect filter became too expensive to maintain.

When you do still need a human reviewer

In April 2026 the FDA issued a warning letter (opens in a new tab) to a drug manufacturer that had used AI agents to draft specifications, procedures and master production records without qualified review. Challenged on distributing product without validation, the firm explained that the AI agent never told them validation was required. The FDA rejected that outright, and said any output from an AI agent has to be reviewed and cleared by an authorised human in the quality unit.

Under DO-178C (opens in a new tab), review of source code is a certification objective rather than a preference. At the highest assurance level, three of the six source-code review objectives have to be met with independence, meaning somebody other than the author, and one of those still applies a level down. Then there is the part I did not expect. The standard’s own definition of independence lets a tool stand in for the human. Qualify the tool and it counts. So even in avionics, the requirement is separation of responsibility rather than human eyes, and AI-generated code gets no special treatment in either direction.

So the boundary runs between compliance regimes, which have always tested controls and are comfortable with this, and safety regimes, which mandate inspection and show no sign of moving. If you build avionics or drug manufacturing systems, stop here. Everything above is for someone else.

Where auto-approval fails: new joiners and slow rot

Review is not only a filter. It’s a conversation. Why did you do it this way. Did you know we already have a library for that. This is a hand-rolled version of something the framework does out of the box. A senior reading a diff diagonally, at speed, catches a wrong pattern before it takes root. None of that is defect detection or shows up in a revert rate, and none of it means the reading skill stopped mattering. It is the judgment you only get from having survived your own outages, and it is the scarcest thing the team owns.

The trouble with Meta’s numbers is what they cannot see. Reverts and production incidents are fast signals. Rot is a slow one. It does not arrive as a revert, it arrives eighteen months later as a codebase where every change costs more than it should, and no instrument in any study I found can see it. The strongest numbers in this post are silent on the strongest argument against it.

A new joiner does not mainly need their code checked for bugs. They need to be told how we do things here, and review is where that happens. Auto-approving their work would be the most expensive item on this whole list, because you would save a review and buy a year of drift.

The answer is not to go back to reading everything. If judgment is too scarce to spend evenly across changes, it is also too scarce to spend evenly across people. A senior reading a dependency bump at the same depth as a change to the money path is not being rigorous, and the same waste applies to reading a tenth patch from somebody reliable at the same depth as a first one from somebody new. Tier on the author, not only on the diff. Somebody with no track record in this codebase gets read, every time.

For rot, the mechanism is sampling, and it is what auditors already do. Nobody reads every change. Somebody senior reads a random slice, diagonally, looking for drift rather than defects. Unlike a gate it blocks nothing while they get to it. The gate was always a poor instrument for this anyway, because somebody looking at one diff cannot see drift. Reading five unrelated diffs on a Friday afternoon can.

What happens when review thins out

The best-designed study in the field partly contradicts me. Researchers at Carnegie Mellon and Stanford followed 802 developers and 196,212 pull requests (opens in a new tab) at a company that mandated doubling merged changes per engineer. Throughput reached 2.09 times baseline and the load on each reviewer doubled with it.

The reading disappeared. The rubber stamp did not.

Out of every 100 pull requests, what kind of human attention it got before it merged.

Before the mandate

After the mandate

Somebody wrote a comment 39 → 21 Approved in silence 50 → 50 No human looked 11 → 29

802 developers and 196,212 pull requests, Carnegie Mellon and Stanford, 2026. The paper reports each share as approximate and gives the combined human-review share falling from 89 to 68 percent, so the third band is the remainder. Over the same period merged output per engineer reached 2.09 times its baseline. Merge and revert rates did not move.

The system thinned review out and nothing visibly broke, which is either reassuring or the most worrying sentence in the dataset depending on how much you trust reverts as a proxy for harm. Look at which band moved. Silent approval did not budge. Nobody gave up the habit of waving things through. What the mandate squeezed out was the half of review where somebody actually said something, and where it went was to changes no human opened at all.

Steve Fenton offers a test that will falsify this post for most readers (opens in a new tab) in thirty seconds: count the changes that have passed review but are not yet deployed and enabled for users. If that number is large, your constraint is downstream and none of this is your problem. I suspect that describes more readers than would care to admit it.

METR’s 2025 finding, that experienced open-source developers were 19 percent slower with AI (opens in a new tab) while believing they were 20 percent faster, is the number everybody still quotes. METR have retired it. Their 2026 follow-up (opens in a new tab) has confidence intervals that include zero, because enough developers declined to submit tasks rather than do them without AI, and the authors’ own reading is that AI helps more now than it did then. It settles nothing about review.

Simon Willison (opens in a new tab) got here first, and his framing is the one I keep returning to. The skill is being able to instruct an agent confidently and then verify confidently that the change was made correctly. Sometimes that means reading every line. Often it does not, because eyeballing every line of code has never been the most effective way to validate a change to a piece of software.

How to tell whether your own review gate is leaking

Latency is the wrong first metric. It is the one that will send you hiring. Look at these instead, per reviewer, over time, and look at them together.

Approval rate. Rising is the warning sign, not the reassurance.
Comments per review, normalised for change size. Falling while approvals rise is the leak.
Share of changes merged with no review at all. Faros found this rising 31 percent (opens in a new tab) as teams moved from their lowest to their highest AI adoption.
Size distribution at the 90th percentile, not the median. The median will tell you everything is fine.
Time from approval to deploy. If this is your biggest number, stop here and go fix that instead.
Recall, not precision, on any review tool you buy. On the one benchmark built from 118 real production bugs (opens in a new tab), the best tool caught 48 percent and the weakest 18. It was run by one of the vendors in it, and that vendor won.

The part I cannot answer

Peter Naur argued in 1985 that the durable artifact of programming is not the program but the theory of it (opens in a new tab) held by the people who built it. The uncomfortable part is what he says next. Reading the program text is explicitly not how that theory transfers. It passes between people who work in close contact, which means the gate was never the mechanism we told ourselves it was. Sampling keeps the theory alive in somebody. At three in the morning six months later, the person on call is whoever is on call, not whoever happened to draw the lucky diff.

The people in the most pain went the other way entirely. Facing a flood of machine-generated contributions, open-source maintainers throttled arrivals instead of relocating the gate. Daniel Stenberg closed curl’s bug bounty (opens in a new tab) after nearly seven years. GitHub shipped limits on open pull requests per user (opens in a new tab). They asked for fewer arrivals and more funding, not for a smarter gate.

If Naur is right, what replaces the gate is contact rather than inspection, and a change reviewed as it is written by somebody sitting alongside has no queue to sit in at all. I cannot point you at a study proving that works in the agent era. I looked.

The law never asked you to read it. It asked you to be answerable for it. For thirty years, reading was the cheapest way to be answerable.

The most useful mechanism I found is one clause in Meta’s eligibility rules (opens in a new tab). Automated approval requires that the author have an associated operational on-call rotation. The machine may approve your change only if you are the person who gets paged when it breaks.

Everything else in this debate tiers on properties of the change. Size, path, risk score, blast radius. That one tiers on a property of the human, specifically whether they are exposed to the consequences. If review’s real product is accountability rather than defect detection, a second pair of eyes is a remarkably indirect way to buy it and the pager is a direct one. It also answers the FDA’s implicit question better than any attestation format, because “the agent never told us” is a defence only available to someone insulated from what happens next.

What to have in place

Write the exclusions as code, not as culture. Auth, secrets, tenant boundaries, money, and migrations always get a human. Everything else earns its tier.
Name the approver in the record, every time, whether the approval came from a person or a system. Attribution is the thing auditors sample for.
Disclose machine authorship in the commit trail. The kernel’s one-line trailer is the pattern.
Gate the automated path on the author carrying the pager for what they just shipped.
Tier on the author as well as the change. No track record in this codebase means a human reads it.
Sample. Somebody senior reads a random slice of merged diffs, looking for drift rather than bugs.
Ask your auditor before you scale, not after. Intercom’s whole advantage was sequencing.
Put recall next to every precision figure a vendor shows you. These are filters, not substitutes.
Keep a human reading anything irreversible. Rollback substitutes for review right up until the money has moved.

The Convention Lied

Fri, 14 Aug 2026 00:00:00 GMT

The rule had been true when someone wrote it. “All new services go through the shared gateway.” It sat in the conventions file for a year, accurate and unremarkable, until the day we moved off the gateway and forgot the file existed. The sentence never changed. The world underneath it did.

Nobody noticed, because nobody reads the conventions file. That was always its quiet mercy. A human joining the team would have skimmed it, felt the dust on it, and asked someone which way things actually work now.

The agent didn’t skim. It read the line, believed it, and wired a brand-new service straight through a gateway we’d spent a quarter tearing out. It worked flawlessly, right up until the new service’s calls started vanishing into a gateway we no longer ran, and a customer noticed before our dashboards did. It never hesitated, because the file gave it no reason to.

Rot isn’t gradual. A document stays perfectly fine right up until the instant something acts on it, and then the whole cost of its being wrong arrives at once, with interest.

It did careful, competent work in service of a fact that had died three months earlier.

We used to treat old docs as clutter, a mess to tidy up eventually. That framing is finished. An old doc is now a loaded instruction sitting in the path of a tool that does exactly what it says.

The fix isn’t heroic. Keep the files that matter small enough to actually maintain, close enough to the code that changing one means changing the other, and let the agent that reads them also check them. Turn the reader into the proofreader.

Three months. That’s how long a good rule stayed true before it started lying, and how long it took anyone to notice.

The docs didn’t fail the day they went stale. They failed the day something believed them.

The Whiteboard Test

Thu, 09 Jul 2026 00:00:00 GMT

We’ve all sat in the meeting that refuses to die. Not one meeting, technically. The same discussion reincarnated across three calendar invites, each one ending in a warm, useless consensus that evaporates the second everyone leaves the call. And the strange part is that nobody in the room is wrong. That is exactly why it won’t end. Everyone is describing a slightly different system living in their own head, and the words are close enough to hide the fact that they don’t match.

Then somebody gets tired, shares their screen, and starts drawing. A box. Another box. An arrow that a colleague objects to before it’s even finished. And somehow the fight that survived three meetings is settled in ninety seconds.

We love to credit the picture. A diagram is clearer than words, we say, a thousand words and all that. That’s not it. The clarity was never in the image. It was in the drawing.

Because you cannot draw a system you haven’t actually thought through. Speech is generous with ambiguity. You can say “and then it talks to the payment service,” and every head nods, each person quietly picturing a different handshake. The sentence costs you nothing. But the moment that sentence has to become a line between two boxes, the loan comes due. Sync or async. Who owns the retry. What the caller sees when the whole thing times out at the worst possible moment.

This is where the innocent little arrows betray you. The one connecting two services that turns out to be a distributed transaction nobody agreed to own. It hid comfortably inside the words “talks to” for three meetings. It took a single stroke on a shared canvas to drag it into the light, and suddenly the room is arguing about the thing that actually matters instead of the thing everyone assumed was fine.

That is the quiet violence of a good drawing. It refuses to let you stay vague. It turns opinion into geometry, and geometry has nowhere to hide.

The value of a drawing isn’t that other people can finally see your idea. It’s that you finally have to.

So the next time a discussion has gone three rounds without drawing blood, stop talking and pick up the pen. Not because a picture is worth a thousand words, but because it’s worth one honest admission.

If you can’t draw it, you don’t understand it yet. You’re just describing your confusion in higher resolution.

Broken Windows, Healed

Mon, 08 Jun 2026 00:00:00 GMT

The first shortcut shipped on a Tuesday. A service reached straight into another service’s database because the proper call was slow and the deadline was real. Reasonable, at the time. By Friday two more services had copied it, because it was right there and it worked. Nobody decided this. It just spread. That’s a broken window. Hunt and Thomas named it decades ago. Leave one cracked pane unrepaired and you signal that nobody cares, so the rest cost nothing to break. The whole building decays on an exponential ramp.

Here’s the part everyone misread. We never lived with broken windows because we couldn’t see them. We lived with them because fixing them never penciled out. Boarding up every window across a million-line codebase costs years no budget will approve, so the ramp only ever ran one direction. Down. The decay had a clock and the repair didn’t.

AI just put a clock on the repair too. Airbnb (opens in a new tab) had thirty-five hundred test files written against Enzyme, a framework they adopted in 2015 that stopped fitting React by 2020. Classic boarded-up window, too expensive to revisit, too risky to delete without losing coverage. By hand they estimated a year and a half. They pointed a model at it with retry loops and real context, and finished in six weeks, ninety-seven percent automated, the original test intent intact.

The same machine speed that spreads a bad pattern is the speed that finally undoes it.

The decay was never the surprising part. The surprise is that the ramp is symmetric, and for the first time the cost of doing the right thing dropped below the cost of ignoring it. The ramp was always exponential. AI just handed you the button that runs it backward.

The Wish List

Thu, 07 May 2026 00:00:00 GMT

Every architecture document we read sounds the same. Microservices because scale. Kafka because events. Kubernetes because production. Service meshes because security. Forty pages, twelve diagrams, and three quotes from a Netflix blog post written when the company writing them was still a slide deck.

This isn’t architecture. It’s a Christmas list to Santa Cloud.

It’s also the easiest document to write. The pressure to adopt is everywhere. Vendors, conferences, hiring posts, all rewarding the architect who said yes. We get it. We’ve written that document too.

Real architecture is the list of things you refused to add. The list of yeses is everyone’s job. Product wants the new framework. The senior engineer just got back from a conference and wants what they saw work at a much bigger company. The platform team has three open tabs about a service mesh and a free trial that expires Friday. Saying yes is the path of least resistance, the path of not derailing the meeting, the path that gets the architect promoted to “facilitator.”

Saying no is the part of the job nobody trained you for.

Look at OpenAI. They run ChatGPT on a single PostgreSQL primary (opens in a new tab). Eight hundred million users. Nearly fifty read replicas. They never sharded Postgres. They peeled the write-heavy workloads off to a separate sharded store and ground out optimizations on the primary instead.

The investment was real. Connection pooling. Caching with locking. Workload isolation. The kind of work that doesn’t show up in keynotes.

One SEV-0 in twelve months. Five-nines availability.

The architectural decision wasn’t “use Postgres.” Postgres is a default. The decision was refusing to shard the primary when the write curve got scary, and grinding through the optimizations that kept that refusal alive.

That’s the work. The diagrams are decoration.

The architecture you ship is the wish list you survived.

Audit your next design doc by what’s missing. Which popular technology did you consider and decline? Which framework did you protect the team from? If the answer is “none,” that’s a chance to start practicing. The framework you don’t adopt this quarter pays you in operational simplicity every day after. Nobody will thank you. The team that runs faster on Tuesday morning won’t know why.

Architecture is what survived your refusal. Refuse more.

The Postmortem Theater

Sun, 12 Apr 2026 00:00:00 GMT

The pager goes off at three in the morning. We spend four hours chasing a race condition through a distributed system that seems designed to spite us. By dawn the checkout service is breathing again, but the real toil is just beginning. We face the blank page of the postmortem document, reconstructing a timeline from a thousand fragmented Slack messages while our brains are still foggy from the adrenaline crash.

This is where the theater starts, because we are too exhausted to be accurate and too hurried to be deep.

We gather the stakeholders. We write the document. We assign the action items. We feel productive. Six months later the exact same service falls over for the exact same reason, and we realize the first document was just a very expensive piece of fiction. Blamelessness (opens in a new tab) has morphed into a shield for inaction. We’re so committed to not pointing fingers that we forgot to point at the problem. If our action item completion rate is below fifty percent, we don’t have a learning culture. We have a writing assignment.

The fix is less clerical work. We spend eighty percent of our postmortem effort documenting the past and nearly zero percent engineering the future. That ratio needs to invert. Let AI be the fly on the wall in our war rooms, capturing the raw logic of the fix as it happens. Correlated logs and a reconstructed timeline, ready before the meeting even starts. The engineer still does the engineering. They just stop doing the reconstruction work that kills a learning culture.

The value of incident review is not the document. It is the change.

When the report generates itself, we can spend the postmortem meeting on the remediation items that prevent next month’s 3am call. A recurring outage is a voluntary tax on our engineering capital.

Break the Glass

Mon, 02 Mar 2026 00:00:00 GMT

Some breaking changes are necessary violence. Others are just violence.

The entire industry coordinated to deprecate TLS 1.0 (opens in a new tab) because the protocol had fundamental security flaws that made it a liability to keep breathing. That is an existential breaking change. The cost of not breaking it was higher than the cost of migration. You break backward compatibility when the alternative is systemic failure.

Most breaking changes don’t meet that bar. Renaming a field for consistency is not an emergency, and neither is reorganizing your JSON response for “cleanliness” or bumping a major version because you finally fixed that three-year-old typo in the documentation. That’s pushing work onto your users because you found the old naming convention embarrassing.

The Python 2 to 3 migration is the canonical example of a justified change executed poorly. The improvements to string handling and Unicode support were real. The decade-long fragmentation of the ecosystem was also real. Libraries stopped getting updates because maintainers had to choose between supporting two incompatible versions or abandoning users. The industry paid a steep collective price for a transition that could have been designed with more grace.

Chrome’s Manifest V3 (opens in a new tab) had legitimate security goals but forced extension developers into a rewrite with an aggressive timeline. Tailwind v4 delivered 100x faster builds but left developers staring at breaking changes in their utility classes. Both were defensible, and both hurt.

So before you break anything, ask whether you’re patching a hole or redecorating.

If you’re redecorating, the migration cost belongs to you, not your users.

If it’s redecorating, use the expand and contract pattern. Add the new thing, deprecate slowly, and let your users migrate on their timeline, not yours.

Judgment is knowing when to break the glass and when to just clean it.

Review Taste

Mon, 02 Feb 2026 00:00:00 GMT

We used to spend our afternoons arguing about trailing commas and whether a switch statement was cleaner than a nested conditional. It was a simpler time, mostly because those arguments were easy to win if you had enough gray hair. Now the syntax is flawless because the machine doesn’t make typos. It produces blocks of code that are structurally sound but logically hollow, leaving us with a much more expensive problem.

The machine has solved the “blank page” problem, but it’s created an “almost right” problem in its place. Your Copilot is a hyper-productive intern with a silver tongue and zero accountability. It’s brilliant at syntax and rarely misses a closing bracket, yet it operates within a context window that doesn’t understand your business logic or the quirks of your production environment.

We’ve moved from being editors of grammar to auditors of intent.

This shift requires a level of review taste that isn’t taught in a prompting course. The ability to look at a thousand lines of flawlessly formatted Go and realize the agent used a library method deprecated three versions ago. The intuition to spot a security hallucination where the AI suggests a textbook regular expression that’ll lock up your CPU the moment it sees real traffic. You only get that sense by having lived through the outages, by having seen your own elegant designs collapse under the weight of a three-am production leak.

The bigger problem is that the junior developer is being automated out of an education. They’re being asked to develop judgment through observation alone. It’s also the one case where no gate should ever be automated away, whatever the compliance argument says. We’re building an intellectual debt by trading implementation intuition for immediate velocity. If we don’t start treating implementation as a protected apprenticeship, we’ll end up with a board of directors trying to land a plane they don’t know how to pilot.

Syntax is getting cheaper. Judgment isn’t.

The Universal Remote

Mon, 05 Jan 2026 00:00:00 GMT

The Board wants “optionality” because they’re terrified of pricing power. They want to hear that we can switch clouds over the weekend. It sounds like prudent risk management. In practice it’s one of the most expensive habits in IT. We’re attempting to build an “Esperanto” layer for our infrastructure. We want a universal language that abstracts away the differences between the clouds. The problem with Esperanto is that nobody actually speaks it. When you force your engineering team to write generic code that runs everywhere, you ensure it runs poorly everywhere.

You’re paying for a “Universal Remote” that only supports the Power button. By refusing to use the proprietary features of your cloud provider you’re paying the premium price for the platform but using only the commodity features. You’re giving up execution speed to guard against a vendor pricing change that’s statistically unlikely to kill you. That’s financial anxiety dressed up as architecture.

Portability you never use is a premium you pay every month.

Worse, you’re crippling your velocity today to solve a problem that’s rapidly disappearing. If the day comes when you actually need to leave AWS then AI agents will likely be able to refactor your proprietary calls into Azure SDKs in an afternoon. The cost of code translation is trending toward zero. You’re optimizing for a future where migration is hard but we’re moving toward a future where it’s trivial.

We often point to 37signals leaving the cloud (opens in a new tab) as proof that we need this agility. They moved because they did the math on renting versus owning, not because they had a perfect abstraction layer. That was a capital allocation decision for a stable business. It wasn’t a feature of their code. Most of us aren’t moving to a datacenter. We’re just moving sideways to another landlord.

The lock-in that actually hurts is data. Data Gravity dictates that where your petabytes live is where your applications live. Moving that mass is a multi-year logistical nightmare. The abstraction layer you’re building is solving the easy problem while ignoring the hard problem. Pick a cloud and commit to it. “Lock-in” is just another word for “Leverage.”

The Greenfield

Mon, 08 Dec 2025 00:00:00 GMT

There’s a specific, intoxicating smell in the software industry. It smells like fresh coffee, whiteboard markers, and the absolute certainty that this time, we’re going to do it right. It’s the allure of the Greenfield project. We look at our existing codebase. We look at that sprawling, patched-together monolith that currently pays our salaries, and we sneeze at it. We call it “legacy.” We call it “tech debt.” We convince management that the only way to move forward is to burn it down and start fresh.

This is the single most expensive delusion in engineering.

Junior developers, in particular, love a Greenfield project, and it makes sense. They haven’t been around long enough to see a “perfect” architecture rot from the inside out. To them, the blank repository is freedom. A chance to use Rust, or Go, or whatever JavaScript framework was invented during lunch. They believe that the messiness of the old system was a result of incompetence rather than the natural accumulation of business requirements. They think they can code their way out of complexity.

You can’t fix a people problem with a new repository.

And the Greenfield doesn’t actually exist. It’s a mathematical limit we approach but never touch. The moment you write the first line of code, literally the first character, you’ve created legacy. You’ve made a decision that someone else will have to understand and eventually curse at three years from now. You’ve imported a library that’s already going out of date. You’ve made an assumption about the data model that’s slightly wrong.

We spend the first month of a Greenfield project engaging in what I call “Architecture Astronauting.” We draw boxes and arrows. We decide to use microservices because we want to be “web scale,” ignoring the fact that we don’t have any users yet. We spend weeks debating the perfect folder structure and the perfect linting rules. We’re optimizing for a future that hasn’t happened. We call this “best practice,” but it’s usually just Resume Driven Development in a trench coat.

And then the requirements change. The business pivots. The perfect, clean architecture you designed for a ride-sharing app suddenly needs to support food delivery, and your elegant abstractions start to leak. You add a hack here and a bypass there. You stop updating the documentation because you’re moving too fast.

Suddenly, your beautiful green field looks a lot like a muddy construction site.

The only difference between your new code and the old code is that the old code has actually survived contact with reality. It’s handled edge cases you haven’t even thought of yet. It’s processed credit cards without crashing. It’s ugly because the world is ugly.

So learn to love the Brownfield. Pull the weeds instead of torching the field. The only code that doesn’t have technical debt is the code that doesn’t exist.

Hello World

Fri, 14 Nov 2025 00:00:00 GMT

Boilerplate is finally somebody else’s problem.

Open your feed and everyone’s shipping something. The days of hand-typing the same CRUD handler for the fifth time are effectively over, and that’s a massive win for anyone who actually loves building products. We can now move about as fast as we can think.

The generator doesn’t care what it’s building on, though. It amplifies good architecture just as easily as bad design. Point it at a shaky foundation and you get a legacy codebase in record time. The faster we build, the more what we’re building matters.

That’s why The Bit Shift (opens in a new tab) exists.

I’m betting big on this future. But the physics of software haven’t changed just because we have better tools. The speed of light still dictates latency. Database locks still dictate throughput. Those foundations decide whether all this new speed goes anywhere useful.

Let the AI generate the functions. We’ll provide the wisdom.