Your competitor has the same Claude, Codex, Copilot, or Cursor you have, and the same upgrade landed on their machines the same morning it landed on yours. But they're getting more out of it, and it isn't because their developers are better or because they found a smarter large language model. It's because when a new model shows up at their shop, it already knows how they build. At yours, every developer teaches it again, alone.

Your AI keeps getting better. Your organization isn't keeping up. There is one real reason AI isn't paying off for your team, and you can see it in three places. I'll walk you through all three, and what the teams that are keeping up do about each one.

The Three Places It Shows Up

You keep teaching it the same thing

You told the AI how you do auth last Thursday. Today it's a new chat, or a new model, and you tell it again. So you do what most of us do. You add an AGENTS file, a few skills, some comments in the code, maybe a markdown file with the rules, and you check them into the repo so the whole team gets them. That helps, and most teams stop there. But a file in the repo only works when the tool reads it, the session has room for it, and nobody pastes in a prompt that outranks it. So you still re-explain the parts that didn't stick, and so does everyone else, each in their own chat where the rest of the team never sees it.

Every developer's AI builds a little differently

Even with the same files in the repo, five developers get five versions of the system, because each one prompts differently, loads different context, and corrects the AI in a chat nobody else can see. So the AI writes five ways to do the same thing, and it writes them faster than any of you could have by hand. The code review catches some of it. The rest ships, and the next developer's AI copies whichever version it finds first.

Either someone reads every line, or nobody does

Nobody can tell you whether the AI's work is right without reading it. So your shop lands in one of two places. Either one of your best people reads every line it writes, which means the AI just made your senior engineer the bottleneck. Or nobody reads it, and code the AI wrote goes to production because it said it was done and the build compiled and the tests passed.

Kent Beck, the man behind Extreme Programming, calls the version with no human check the dark factory. He says it always goes off the rails, and that it looks amazing right up until it does.

Most teams ping-pong between the two. Something slips through, so everyone reads everything for a month. That gets slow, so the reading stops. And every swing gets blamed on how smart the model is that week.

But the large language model was never the problem. The AI does not know what done means in your org, so a human has to be the check, or there is no check. All three of these places point at the same gap. Nothing in your organization makes the AI start from how you build software, every session and every tool, and nothing proves it did. That is the one real reason, and it's about to get more expensive.

Why the Gap Widens With Every Release

Every upgrade makes every private copy a little better. Your copy, your teammate's copy, each one separately. The gap between the copies stays, and the organization gets nothing it can keep. Meanwhile, the shop that has its way of building software written into the system gets the whole upgrade, for the whole team, the same morning. So the gap widens with every release, and the releases are coming faster than ever.

The shops that learn this grow a lot faster than their competition. The shops that don't are building a decade of technical debt in a few months.

Now, you can argue that when it gets ugly you just have the AI rewrite it, and that can work. If you're on microservices or a modular monolith, you can rewrite a piece without wrecking the rest. But that only proves the point. When a piece gets rewritten, how do you know nothing else broke, or nothing got left out? The fix I'll get to in a minute doesn't take the rewrite away from you. It keeps you from being forced into one every time the system gets more complex.

Kent Beck put it this way. It used to take a hundred people ten years to get a system to the point where nobody could change anything without breaking something else. Now, he says, one person with AI can get there in a week. I'll be a little more generous and say a handful of developers get there in six months. Every feature you add burns a little of what you could build next, and AI burns it faster. And while you're having the AI rewrite your software, your competitor is getting the AI to build the features their customers asked for.

So how do I know this is the real cause and not just a story about your team? Because I lived the other side of it, as the person building the thing the model was supposed to make pointless.

The Day Codex Shipped

In August of last year I was three weeks into building a system that gives the AI the decisions behind my code. On September 15th, OpenAI shipped GPT-5-Codex, with a web UI, a CLI, and a VS Code extension, and I spent that afternoon running it on my own code wondering if what I was building had just become pointless.

It wrote good code. But it did not know how I handle data access, or auth, or why I split projects the way I do, unless I told it. And it did not remember the next day.

That happened again with the next release, and the one after that, and every time the answer was the same. The model got better at writing code, and it still knew nothing about how my shop builds. I incorporated the company on September 30th anyway, because what I was building had stopped being a tool that competes with the model. It had turned into a way for engineering teams to work in the AI era, with any model.

The large language model is the part everybody has. The decisions around it are the part that survives an upgrade.

Organizations Don't Need Better AI. They Need a Better Operating Model.

Intelligent Engineering is the operating model for engineering organizations in the AI era. It enables organizations to encode their best engineering decisions into reusable systems so AI and people build software consistently, safely, and at scale.

It has seven pillars. Three of them are the answer to the three places above, so I'll name those three.

Prescribe your architecture so the AI never guesses. When the way you build software is built into the system the AI starts from, there is nothing left for each developer to re-explain. Every developer's AI builds the same way, in every tool and every session. That is what the Prescribe pillar is about.

Retain context across sessions so work never restarts from scratch. What the team learns this week has to end up next to the code, where every session starts, not in a chat that closes at five. The code wins on the what. The docs next to it hold the why. There is a Retain pillar for exactly this.

Safeguard every output with checks the AI has to pass before it says done. None of your engineering standards go away. The AI is the one held to them. It knows what done means in your org, it runs the checks itself, and it does not call the work finished until they pass. So trust comes from the check, not from one of your best people reading every line. That is the Safeguard pillar.

Teach it once. Every AI, every session, every builder creates software your way. And the next model release lands on all of it, the same morning.

"We Already Have an AGENTS File"

You might be thinking, we have an AGENTS file. Good. That is the first step, and most teams stop there. A file describes how you build. It does not make anything build that way. I learned that one with a database.

On December 2nd of last year I kicked off the integration tests for a client project and walked away, because I expected them to run without me watching. The test setup drops and recreates a database on each run. This time it used "ELS" instead of "IntegrationTest_ELS," so it dropped my local database. It had done exactly what the code told it to do, just against the wrong name. It was local, so no customer lost anything, but a different connection string would have made it a very different day.

The rule was in the README. The check was not in the code. An AGENTS file is the README.

So here is the test. Three questions, one for each place the gap shows up.

  1. A developer who joined last month opens the AI for the first time. Does it build your way on day one, without a developer teaching it?
  2. A new model is available in your organization this morning. Does the whole organization get the upgrade the same day, or does each developer re-tune their own setup?
  3. The AI says a task is done. What ran to prove it, other than someone reading the code? "The build compiled and the tests passed" is not a yes.

Which of the three came back no for you? I'd like to know in the comments, because the no is where the work is.

If any of those came back no, that's where your organization isn't keeping up. The Intelligent Engineering Assessment is free. It tells you where the gap is and what to do about it. Your organization may be one small step away from shipping faster than your competitors.

All That to Simply Say This

Your AI keeps getting better. Your organization isn't keeping up. The difference between the engineering organizations that are winning with AI and the ones that aren't keeping up comes down to the operating model they use to build software.

You have seen the three places that gap shows up, why every new model release makes it wider, and the three questions that tell you where yours is. The large language model is the part everybody has. Go put the part that's yours into the system the AI starts from.

Chad Carter is the creator of DevNitro, the Intelligent Engineering platform. He's spent 29 years building software, served as CTO at multiple companies, and was a Microsoft MVP from 2009-2019.