Architecture

The internet is filling with AI-written text faster than anyone anticipated. The next generation of models will train on it. The researchers who study what happens when models eat their own output are not optimistic. The labs are not talking about it.

Ask any AI team if they evaluate their models properly and they will say yes. Ask them what their eval set looks like, how often they run it, and what happens when it fails. The conversation gets very quiet very fast.

For two years the constraint was the model. Not smart enough. Not fast enough. Not cheap enough. The models got smarter, faster, and cheaper. Now the constraint is the humans reviewing what the models produce. Nobody planned for this.

Every AI lab is racing to ship agentic frameworks. Every conference talk shows impressive multi-agent demos. Behind closed doors, the teams that shipped these systems to real users are having a very different conversation about what actually works.

Confabulation. Hallucination. Fabrication. The AI industry has cycled through three names for the same problem in three years. The problem has not been solved. The newer models make it harder to detect. That combination is more dangerous than most teams realise.

Every time Meta releases a Llama model, the frontier labs reprice their APIs within weeks. The cycle is accelerating. The companies caught between are the ones nobody is talking about. They are the ones most at risk.

The AI coding tool market just crossed a threshold nobody planned for. Enough developers are using these tools in production that the second-order effects are now visible. The velocity is real. So is the damage accumulating underneath it.

In 2024, every company needed an AI engineer. Salaries went to $400k. Candidates changed their LinkedIn titles overnight. Now the companies that hired them are quietly asking what they got for the money. The answer is complicated.

The headlines say AI is either the greatest technology shift in history or a massive overhyped bubble about to collapse. Both are wrong. Something more interesting and more consequential is happening. The market is splitting in two.

Every frontier model has read the internet. None of them have read your internal docs, your customer history, your pricing logic, or the decision your founder made in 2019 that still shapes every product call today. The gap between what models know and what your business needs is where most AI projects quietly fail.

Every company wants AI agents to automate their operations. Most of them are discovering the same thing: the process they wanted to automate does not exist in any form an agent can follow. The AI did not find the problem. It revealed it.

In the last eighteen months, 'AI-first' went from a differentiator to a requirement. Every company is one now. The problem is that almost none of them can explain what changed beyond the press release.

OpenAI cut prices again last week. Anthropic followed. Google matched. This is the third time in eighteen months. The teams celebrating the cheaper inference are the same teams whose revenue models quietly stop working when the cost of the underlying technology approaches zero.

Hundreds of AI companies raised money in 2023 and 2024 on the strength of demos that worked beautifully. Many of them are quietly winding down right now. The reason is not what most people think.

The new Claude models think differently from their predecessors. The prompting patterns, the agent architectures, and the orchestration assumptions that worked six months ago are quietly breaking. Here is what changed and what to do about it.

Extended thinking. Deep reasoning. Chain of thought. The labs are racing to ship models that think longer before they answer. Most teams are applying them to problems that do not require thinking at all. The invoice is extraordinary.

LangChain. LlamaIndex. AutoGen. A year ago every team picked one and built fast. Right now, quietly across the industry, those same teams are ripping them out. Here is what happened and why nobody is talking about it.

Every major AI lab is racing to expand context windows. Gemini hit two million. The assumption is that bigger is better. The reality, playing out quietly inside engineering teams right now, is considerably more complicated.

Every productivity metric is up. Velocity is up. Features shipped is up. Lines of code is up. The one number nobody is tracking is the one that determines whether any of this compounds into something good or collapses into something expensive.

Model accuracy in staging means almost nothing. The real number, the one that determines whether your product actually works, lives in production and most teams have never measured it. Here is what is actually happening inside deployed ML systems right now.

The most powerful AI company in the world quietly changed its story last month. What they stopped saying tells you more about where this industry is going than anything they actually announced.

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.