Nobody is building armies of agents that rewrite production Kubernetes clusters at lunch. That only happens on Twitter.

What is actually happening, every single day, across tens of thousands of developer teams right now, is a messy, unglamorous set of tradeoffs that no keynote will ever show you. People are fighting token bills. They are spending 5 hours debugging a one line bug that AI generated in 30 seconds. They are watching Google ship an AI API directly into Chrome while every other standards body screams. They are building weird little personal bots that work far better and far worse than they expected.

This is not the future we were promised. It is the future we got. And it is far more interesting.

The greenfield / legacy productivity split

This is the single most consistent observation across every developer report and comment thread. AI works unbelievably well on greenfield code. It works unbelievably badly on code that has existed longer than 18 months.

It is not about how old the code is. It is about how much unwritten context lives inside it. The weird decision the junior made in 2019 because the payment gateway had an undocumented bug. The dependency that cannot be upgraded because one critical customer is still running Internet Explorer 11. The architectural compromise everyone agreed to at 2am on release night that was never written down anywhere.

You cannot feed that context to an agent. It lives in the heads of the people who have been working on the system. For this class of code, senior developers are already faster than AI. Not because they are smarter. Because they carry the scars.

This split is almost never mentioned in marketing material. It is the single most important fact about AI productivity today.

We already hit peak AI enthusiasm

Twelve months ago every company was handing out unlimited enterprise Copilot licenses and telling people to use as much as they wanted. Management did not ask about cost. They did not set limits. This was revolutionary.

That phase is over.

Every large company that rolled out AI tools is now doing cost optimization. Teams are getting token quotas. Managers are running reports on usage per developer. There are internal Slack threads debating whether interns are actually cheaper per token than Claude Code. Meta even introduced an internal reward system for engineers who use fewer tokens per task.

The hype cycle flipped faster than anyone expected. We went from "AI will make us all 10x engineers" to "can you please stop generating boilerplate it's costing us $1200 a week" in about 9 months.

The 10x debug ratio

AI writes code 10x faster. You will debug that code 10x slower. This ratio is consistent enough that you can plan around it.

It is not that AI writes worse code than humans. It writes different bad code. Humans make stupid obvious typos. AI makes perfect looking code that contains one invisible unstated assumption that will only fail in production for 1% of users.

The worst example on record: a developer generated a three line function that passed every test, worked perfectly locally, and crashed production two weeks later. The fix was one missing null check. Debugging took five hours. That is a 60:1 ratio of debug time to saved write time.

Nobody counts this. No productivity metric includes this cost. It is the silent tax on every AI generated line of code shipped today.

You will not see this mentioned in any vendor case study. You will see it mentioned in every private developer Slack channel.

The LLM API is just HTTP

If you have only ever used an LLM SDK, you have probably never noticed that the entire thing is just a POST request with three fields.

There is no magic. There is no state. Every single call sends the entire conversation history every single time. Every response has a stop_reason field that 90% of developers ignore until it causes a production bug. Output tokens cost 3-5x more than input tokens. That is the entire pricing model. Everything else is abstraction.

Most production agent failures are not failures of the model. They are failures of developers who never looked past the SDK. They did not log usage. They did not check why the model stopped. They did not notice that they were resending the same 10kb tool schema on every single call.

You can learn everything you need to know about production LLM usage in 20 lines of raw Node.js code. Do this before you build anything non trivial.

Google already won the browser AI war

On May 5 2026 Google shipped the Prompt API in Chrome 148. Every other major browser vendor, the W3C TAG, Mozilla and Apple all objected.

None of that matters.

Chrome runs on 65% of global devices. Google just installed a 4GB local LLM on 4 billion devices and gave every website on earth the ability to call it for free, with no API key, no latency, no data leaving the device.

This will follow exactly the same arc as PWAs, Web Components and Service Workers. Google ships it. Developers adopt it. Everyone else complains about standards for 3 years. Then they implement a compatible version. Then it retroactively becomes a standard.

The only interesting question is not if this will happen. It is what people will build with free zero marginal cost local inference that was never economically viable before.

Most AI intelligence is just retrieval

If you ever want to stop anthropomorphizing LLMs, build a simple RAG bot trained on your own bookmarks.

You will get something that sounds exactly like you. It will have your opinions. It will make your arguments. It will sound far more intelligent than any general purpose model. And you will be able to see exactly what it is doing: it finds three old bookmarks that are semantically close to your query, and writes a fluent paragraph combining them.

That is it. That is 90% of what every LLM does. The illusion of reasoning comes from the quality of the retrieval. The model is just a very good compositor.

This is the dirty secret almost no one will say out loud. Almost all impressive AI demos are good retrieval demos. The model itself is almost interchangeable.

Vague variable names are a security vulnerability

AI will always name a variable data. It will never name it raw_unvalidated_user_input.

This is not a minor readability annoyance. This is a security problem. Vague names hide state. No one reading the code six months later will know if that value has been sanitized. No one will notice that it contains user input being passed directly into a database query.

This pattern is so consistent that it can be used as a lint rule. If you see a variable named data, result or value in AI generated code, treat the entire block as unreviewed. Do not ship it until every identifier tells you exactly what it contains.

Personal AI is the good part

All of the boring frustrating corporate AI workflow stuff overshadows the actually fun part that is happening right now.

Developers are building weird little personal AI tools for themselves. They are building assistants that respond to hand gestures. They are building bots that know every bookmark they ever saved. They are building HUD overlays and wake word triggers and custom automation loops that no product team would ever ship.

None of these tools will ever be a unicorn. None of them will be on the front page of TechCrunch. They are just good. They run locally. They do exactly what the builder wants. They have sarcastic personalities. They have bugs that only the builder finds funny.

This is the actual healthy future of AI. Not agents replacing teams. Not billion dollar model launches. Just developers building weird little tools that make their own lives slightly better.

The tradeoff no one tells you

AI does not eliminate work. It moves work.

It moves work from writing code to debugging code. It moves work from implementation to review. It moves work from the start of the project to three months later when the unstated assumptions finally blow up.

This is not good or bad. It is just a tradeoff. For throwaway scripts, for prototypes, for greenfield code with good documentation, it is an overwhelmingly good tradeoff. For core production logic that someone will have to debug at 2am six months from now, it is usually a bad one.

The mistake almost everyone made over the last two years was treating this as a universal upgrade. It is not. It is a tool. Some jobs it makes faster. Some jobs it makes slower. Your job as an engineer is to know which is which.

What comes next

We are done with the hype phase. We are now in the boring adjustment phase.

Developers are learning the ratios. They are building the guardrails. They are working out what AI is actually good at, and what it is terrible at. They are learning to budget for the debug tax. They are learning to log token usage. They are learning not to trust a variable named data.

None of this will make for good keynote speeches. None of this will go viral on Twitter. But this is the part where the technology actually becomes useful.

The revolution was not robots replacing all developers. The revolution was a bunch of very normal developers quietly working out exactly how to use this weird new tool, one production bug at a time.

That is the actual state of AI for developers right now. It is messy. It is imperfect. It is full of hidden costs. And it is here to stay.