GPT-5.6 Is a Real Leap, but Its Enterprise Story Is Unclear

I’m a software engineer at a fairly large US tech company. My day job involves building servers and backend infrastructure for a product with a large concurrent user base.

At the same time, I would not pretend that all of my engineering experience comes from working on massive company codebases. A lot of what I consider my own experience comes from personal projects, and those projects are obviously smaller and less complex than what I deal with at work.

As for my LLM background, I have used Codex cloud, several open models, and, strangely enough, quite a lot of Grok. I have taken a few sips of AI psychosis myself, but I have never fully bought into it. My actual day-to-day work is not particularly AI-friendly.

Until very recently, I thought you were living in a fantasy if you believed LLMs were going to replace a significant number of engineering jobs.

I still do not think that is happening anytime soon. But GPT 5.6 is the first model that has made me understand why some people believe it might.

The output is finally reviewable

The biggest difference for me is the output.

One thing I have always hated about LLM-generated code is how verbose it is. People often say that you do not need to read the code anymore. You describe what you want, let the agent build it, run the tests, and move on.

Sure. That might work for an individual project. It might work for an open source project where mistakes are relatively easy to reverse. It might even work at a very small startup where speed matters more than process.

But most professional engineers do not work like that.

Most of us work on codebases where failure has consequences. The specific skills may differ from company to company, but the basic expectation is the same. You need to understand what you are shipping. You need to review the code. You need to know what it changes and what could break.

If you are careless, stop reading the code, and have no idea what your tools are producing, you are eventually going to cause a serious problem. Depending on where you work, you might also get fired.

This is why I have always cared so much about the quality of LLM output. It is not because I expect every generated function to be a work of art. It is because bad output is difficult to review, difficult to maintain, and especially difficult for someone without the original context to understand.

That was the real issue with previous models.

The code often worked, but it was awkward to work with. It contained too many abstractions, too many defensive checks, too many helper functions, and too many attempts to control every possible invariant from every possible location.

The result rarely felt like one cohesive piece of software.

A lot of the time, I ended up rewriting significant portions of the generated code. At that point, the productivity gain became questionable. I might have saved time producing the first version, but I paid for it later through review, cleanup, debugging, and explanation.

Many of my peers eventually gave up trying to force LLMs into their coding workflow. They still used them for small questions or isolated tasks, but they stopped expecting them to produce code that could be merged with minimal changes.

I continued to find value here and there, but that was more or less the story with GPT-5.5 and Opus, regardless of which coding tool was wrapped around them.

The output was not very readable, and it was not what I would call good code.

When I say good code, I do not mean clever code. I mean code that is relatively compact, difficult to misuse, and written as one cohesive unit. It should not create abstractions for problems that do not exist. It should not scatter responsibility across the codebase. It should not try to defend every invariant in five different places.

There is a much longer conversation to be had about code philosophy, but that is not the point here.

The point is that GPT-5.6 feels noticeably different.

I still see places where the code needs to be reworked. It still makes questionable decisions. It still produces things that I would not merge without reviewing carefully.

But for the first time, the majority of the code it produces feels acceptable to me.

Not perfect. Not magical. Just acceptable in the way professional code needs to be acceptable.

I can read it without immediately wanting to rewrite the whole thing. The structure is usually understandable. The pieces tend to fit together. It feels less like a collection of generated fragments and more like someone actually thought about the code as a whole.

That is a significant leap.

It also creates a new problem.

I am now more worried about losing my grip on the codebase because the model can generate code faster than I can properly absorb it. That was not much of a concern before because I was constantly stopping to fix the output. Now it is easier to accept the changes and keep moving.

That is probably where discipline becomes more important, not less.

I still need to read the code. I still need to understand the design. I still need to make sure I am not allowing the agent to create a codebase that I technically own but no longer understand.

I will have to put real effort into maintaining that discipline.

Better code does not settle the economics

There is another side to GPT-5.6, though, and this is where I remain skeptical.

I expected this generation of models to make AI cheaper.

I assumed we would reach a point where smaller models could perform at the level of older large models. Maybe the frontier model would still be expensive, but most practical work could be moved onto cheaper models without losing much capability.

From what I have experienced so far, the opposite seems to be happening.

The results are better, but the cost story is not.

People can talk about subagents, routing, caching, model tiers, and carefully optimized workflows. All of that may be technically true. But most companies are not going to spend their time finding the perfect combination of tools for a platform they are not even sure they will still be using next year.

Engineers are not going to spend every week redesigning their agent setup to save a few cents per task. Operations teams are not going to be excited about a system whose cost depends on model behavior, context size, agent loops, tool calls, and a constantly changing set of pricing plans.

The fact that engineers have to explain all of this to operations and finance teams does not make the adoption story easier.

And in the real world, saying that engineers can now write code in half the time, one quarter of the time, or one tenth of the time does not translate cleanly into a business case.

In fact, unless you are careful, that argument is a good way to turn your colleagues into enemies.

A company cannot simply say that a developer is ten times more productive and expect the math to work out. Software development is not a factory line. Producing code faster does not automatically mean shipping products faster. It does not remove coordination, testing, review, security, compliance, operations, customer support, or organizational politics.

It certainly does not mean the company suddenly earns ten times more revenue.

Productivity is not the same as value

That is where I think a lot of the current AI adoption story falls apart.

The cost of using LLMs is not obviously getting better. Based on my experience with GPT-5.6 so far, it may actually be getting worse.

The model is more capable, so I use it for harder tasks. Harder tasks require more context, more tool calls, longer sessions, and sometimes multiple agents. Better capability does not necessarily reduce spending. It can simply increase how much work we are willing to hand over to the model.

I cannot imagine giving up LLMs for my personal projects. I probably cannot imagine giving them up in my personal life either. They have become too useful.

But business adoption is a different question.

Outside a small number of companies in Silicon Valley, I am not convinced that the economics are clear. Even among large technology companies, becoming more productive does not automatically translate into more revenue.

A company can generate more code, close more tickets, and produce more pull requests without creating significantly more value.

That does not mean the technology is useless. Far from it.

I think LLMs are a genuinely important technology, and GPT-5.6 is the first model in a while that feels like a meaningful improvement in the part I care about most. The code is finally becoming easier to trust, review, and maintain.

But the enterprise story is still weak.

A few dramatic adoption stories from major tech companies are being presented as though they represent the average corporation. I think many of those stories are exaggerated, or at least framed in a way that hides the operational and economic reality.

Most companies are not Silicon Valley AI labs. They have old systems, limited budgets, compliance requirements, internal politics, procurement processes, and employees who cannot simply rebuild their entire workflow around a new model every six months.

Telling them that code generation is ten times faster is not enough.

Showing them more benchmarks is not enough.

Showing them the number of accepted lines of AI generated code is definitely not enough.

The industry needs a different approach. It needs to explain how these tools improve reliability, reduce operational burden, shorten actual delivery cycles, and eventually create more revenue or lower real costs.

Until then, companies are right to remain skeptical.

I am impressed by GPT-5.6. I am using it. I will probably use it heavily.

But I am not ready to buy the broader story being sold around it.