Architecture

The EU AI Act is live. Automated decision systems now carry real legal liability. Most engineering teams have no idea what their agents actually decided or why. That gap is no longer just a technical debt. It is a compliance exposure.

Claude Opus 4.8 dropped last week. Most teams are still paying frontier prices for tasks a Haiku handles in its sleep. This is a five-figure mistake happening silently across the industry right now.

Every codebase has it. The file, the service, the function that everyone knows about and nobody goes near. It works. Probably. And that is the most dangerous sentence in software engineering.

When software stops working, users feel betrayed. The team feels unfairly blamed. Both reactions are understandable and both miss what is actually happening between people and the software they depend on.

The technology industry tells itself a story about quality rising to the top. The actual history of software suggests something more complicated and less comfortable.

Every engineer has watched a system slow down over time despite nobody intending it. The causes are not mysterious. The prevention is not complicated. What is missing is the habit of treating performance as something that requires continuous attention rather than occasional rescue.

Every team adds rate limiting eventually. Most add it after the incident that made it obvious they needed it. The interesting question is not whether to rate limit but what you are actually protecting, which most implementations get wrong.

The curriculum teaches you to code. The job requires something else entirely. After years in this industry, here are the things that determine most of the variation in how careers go and that almost nobody says out loud.

After years of working with engineering teams, the most valuable person is almost never who you would expect. It is not the fastest coder. Not the one who knows the most. It is someone doing something much quieter and much harder.

Most engineering teams are spending serious money on cloud infrastructure and have only a vague idea where it is going. The bill arrives. It gets paid. Nobody asks hard questions until the number becomes impossible to ignore.

Every production system is built on open source software maintained by people working for free. Most companies have never thought seriously about what happens when those people stop. Some of them are about to find out.

Agile promised to make software development more human. For a lot of teams it has done the opposite. Here is what went wrong and why the calendar is not the problem.

Being right all the time is not what makes someone excellent at this work. Knowing what to do when you are wrong is. The engineers who progress the fastest have figured out something that takes most people years to understand.

Engineers talk about technical debt as if it is a technical phenomenon. It is not. It accumulates through decisions made by people with authority over engineering time, and it is resolved the same way.

On-call burnout is treated as a scheduling problem. It is not. It is a systems engineering problem. The rotation is the last place to look. Everything upstream of it is where the damage is actually done.

Bad data in production ML systems almost never announces itself. It arrives quietly, passes validation, and corrupts months of decisions before anyone realises something is wrong. Here is where the lies hide and how to catch them.

Most ML failures in production are not model failures. They are data failures, pipeline failures, and monitoring failures that teams misattribute to the model because the model is the part they understand least and fear most.

The most dangerous systems in any engineering organisation are not the ones that are broken. They are the ones that are working, that everyone depends on, and that nobody is responsible for.

Engineering teams propose rewrites with confidence and complete them with regret. The second system is almost never as much better as it was supposed to be, and the cost is almost always more than anyone planned. Here is why, and what to do instead.

Event-driven systems are elegant in talks and brutal in production. After building and operating them across multiple companies, here is what nobody tells you before you commit to the pattern.

The daily standup was invented to surface blockers and coordinate work. In most teams it has become a ritual performance of productivity. Here is how that happened, what it costs, and what the meeting was supposed to be.

At some point, many senior engineers quietly transition from building things to managing the building of things. This transition is often presented as growth. Sometimes it is. Often it is the beginning of a slow professional collapse.

Every failed microservices adoption I have seen made the same mistake: treating microservices as an infrastructure pattern instead of an organisational one. The technology is the easy part. The hard part is everything else.

Twenty years ago, teams had no idea how to run databases at scale. They made every mistake possible before the patterns solidified. We are now in the same position with GPU infrastructure, making the same mistakes, faster.

We test the wrong things obsessively and the right things barely at all. The unit test orthodoxy has produced codebases with 90% coverage that break constantly in production. It's time to say this out loud.

There are two kinds of code. The kind you write in the daytime, caffeinated, with full context, and tests passing. And the kind that runs at 3am, in production, when everything is on fire and you wrote it six months ago. Most people only think about the first kind.

The user in your head when you make product decisions is not your actual user. The gap between those two people is where most product failures live.

Every serious engineering team runs post-mortems. Almost none of them work. The problem isn't the format or the facilitation — it's that most post-mortems are designed to produce closure rather than change.

Most code can be refactored. APIs are different. The decisions you make when you first expose an interface become the constraints everything downstream is built on. Here's which ones actually matter.

The teams shipping reliable AI products in 2026 have something in common: their infrastructure is aggressively uninteresting.

A passing dashboard and a healthy system are not the same thing, and most teams only find out the hard way.

Engineering teams don't slow down because they run out of ideas or lose good people. They slow down because the path from decision to production gets longer every month. Here's how that happens and what it actually costs.

Flexibility is not free. Every abstraction you add to avoid being locked in has a price, and most teams are paying it without realising what they bought.

Most teams think they have observability because they have logs. They don't. Here's what observability actually means, why the distinction matters, and what it costs you when production breaks and you're flying blind.

Infrastructure as code promised to make infrastructure reproducible, auditable, and safe. Most Terraform codebases I've seen deliver none of those things. Here's what goes wrong and why.

Every week I talk to a team running three services and forty users on Kubernetes. They're solving tomorrow's scaling problem while today's reliability problems go unfixed. Here's what that costs.

A generation of developers learned to treat the database as a dumb storage layer and move all the logic into the application. That decision is quietly running up a tab that production systems eventually pay.

Vibe coding is a genuinely useful tool for getting ideas out of your head and into a browser. It is also producing a generation of production systems that nobody fully understands. That bill is coming due.

Green builds don't mean working software. Most pipelines are optimised to pass, not to catch failures. Here's what a pipeline that actually tells the truth looks like.

Every serious workflow I run on AI has moved to local models. Not because cloud models are bad — because ownership, latency, and privacy compound in ways that matter more than benchmark scores.

Adding an AI button to your product is not an AI strategy. Here's the difference between bolting on a model and actually re-architecting around what AI makes possible.

Everybody is racing to use the best model. The companies that will win are building the thing the model can't replace: the data, the workflow, and the distribution.

Everyone optimised their prompts. The engineers who are actually shipping reliable LLM systems moved on to a harder problem: what goes into the context window, and why.

Everyone's building agents. Almost nobody is shipping them reliably. Here's what actually goes wrong and how to design around it.