As a solo developer who has shipped SI, MES, and ERP systems and actively integrated AI into day-to-day work, I find myself facing deep skepticism as I watch the recent trajectory of large language models (LLMs). Up through around GPT-5.6, the coding capabilities of AI were genuinely remarkable, and in practice they were the driving force that explosively boosted my productivity and stabilized my revenue. But starting with the latest model, Astra, I have a clear hands-on sense that the current AI architecture has hit a definite wall.
This goes beyond a simple question of performance; it raises fundamental questions about capital efficiency (ROI), the maintainability of system architecture, and the very nature of what we have been calling "intelligence."
Structured State Spaces and the Overwhelming Efficiency of AI
Real-world programming is a different beast from the OS kernels or complex algorithm design you encounter in university. Most in-house ERP and MES systems are, at their core, a battle over N+1 query optimization, UI/UX responsiveness improvements, and how well you can assemble well-defined structures within a framework, things like Inversion of Control (IoC), Hexagonal Architecture, and MVVM. Excluding domain logic, roughly 70–80% of the work is essentially repetitive CRUD application development.
The crux lies in architectural decisions such as which layer to place Validation in and how to verify data modeling. Once the skeleton and the work-order modeling are established, AI produces far more precise and clean code than most human programmers when implementing functions or classes within a constrained search space.
That much is undeniable.
The End of Scaling Laws and the Collapse of ROI
The problem is that meaningful macro-level improvements in the coding domain have stalled since GPT-5.3. In particular, the arrival of Astra, with token costs 2.5 times higher than the previous generation, starkly exposes the contradiction at the heart of current LLM scaling.
I always run a standard set of basic tests whenever I try a new AI model for the first time.
I put together 10 tests and run each of them 10 times.
Two of them are as follows.
Closed State Space and Invariant Verification (State Machine with Strict Invariants)
Tests whether the model copies learned boilerplate or can enforce domain invariants through the type system
Required task: Implement a Finite State Machine (FSM) that manages a payment or order lifecycle.
Constraints: No use of runtime exceptions (
throw/catch). All failures must be returned asResult<T, E>.
Invalid state transitions (e.g., transitioning from
CancelledtoShipping) must be made impossible at the compile-time type level, before any runtime if-statements (using Phantom Types or Tagged Unions).
Write a chaining structure that guarantees a rollback transaction when an asynchronous timeout occurs.
Zero-Allocation Spatial Partitioning Data Structure (Data-Oriented / Memory)
Verifies whether the model considers hardware memory layout and heap allocation optimization, not merely syntactic knowledge.
Required task: Implement a static grid or Quadtree for collision detection in 2D/3D space.
Constraints: Zero heap memory allocations (
new) during each frame's update/query loop (Hot Loop).
Ensure memory contiguity using index-based structures (Array-of-Structures or Struct-of-Arrays) instead of object references.
Apply the swap-back (RemoveAtSwapBack) pattern for compact memory maintenance when removing elements.
Running all 10 tests revealed that Astra actually produced a higher volume of lower-quality outputs than GPT-5.6 Sol. And this from a model that costs 2.5 times as much.
Astra is said to have improved multimodal capabilities such as 3D asset and mesh generation, but its code generation quality has in fact regressed compared to the previous model, Sol. From the perspective of an engineer who needs to build pure B2B backend systems or enterprise ERP services, there is no reason to pay 2.5 times the API cost for 3D art features that are completely useless for the business. In fact, the moment you incorporate 3D assets, user purchase rates drop. The irony is palpable.
To use an RPG analogy, it is as if you have fully equipped the "meta BiS" gear set and are now entering the phase where upgrading to the next tier costs exponentially more while the performance gain becomes barely perceptible. It feels like a threshold of inefficiency where logical reasoning ability no longer rises in proportion to the computing resources being poured in. The current approach attaches a multimodal encoder to the Transformer architecture of the LLM. By design, a model's weights are not infinite. When computational budget and parameters are allocated to rendering 3D space and mapping image pixels to text, the resources that should be dedicated to maintaining programming logic and type-system context are inevitably taken away. This is known as Negative Transfer.
The Transformer architecture is ultimately a structure that predicts sequences of one-dimensional tokens. Attaching multimodal capability means the forms of input and output have become more diverse, but conversely, the model has grown that much larger and more expensive as a result.
Conversely, adding multimodal inputs can yield Positive Transfer. Spatial relationships, object relationships, and causal structures learned from images can benefit text-based reasoning as well. But this inevitably makes the model larger, and the larger the model, the higher the cost.
In other words, while the performance of an LLM as an alignment machine can grow enormously, the input cost rises proportionally. At that point, there is ultimately no economic case for using the machine at scale.
The Work-Density Dilemma and Codebase Contamination
Since adopting AI, the workload a solo developer must handle has risen to an abnormal level. As AI raised the floor of development quality, project delivery timelines compressed to roughly half of what they used to be, yet the actual hours of labor have increased.
More damaging is the collapse of maintainability. When human-written code and AI-generated code begin to mix inside a massive codebase of 100,000 lines or more, a serious architectural incompatibility emerges. Working programmers do not code by rote-memorizing algorithms; they carry habits infused with the "human scent" of team conventions, ease of management, and domain-specific context. AI, by contrast, generates the most average and fragmented logic possible. Left unchecked, this erodes the overall integrity of the system and drags the team into an endless swamp of bug fixes.
The Illusion of Intelligence: "Logic" or "Serialization"?
Looking at all of these phenomena together, I have deep doubts about whether what an LLM performs is actually a stepping stone toward Artificial General Intelligence (AGI).
Human intellectual work is nonlinear. You conceive A, attempt C, return to B, and create something new from that process. Then you serialize that experience into a logical A-B-C structure for a paper. In other words, a "logical structure," when you think about it, is serialization.
AI is simply a tool that is extremely optimized for "serializing" dirty data and fragmented information into clean, sequential A-B-C data.
The reason AI is perfectly replacing so much office work and routine coding is that those tasks, which we mistakenly regarded as high-level intellectual work, were in fact products of this serialization all along. But I believe that is still far from true "intelligence" in the sense of designing structures that do not yet exist by crossing between dimensions of thought.
The Era of Specialized Models and Decelerationism as a Moat
Ultimately, the future AI ecosystem has no choice but to move away from solving everything with a single massive generalist model and toward an approach that orchestrates multiple lightweight, domain-specialized models, such as coding-specific and 3D-specific variants, in combination. Without that shift, the business model simply cannot absorb the exploding token costs.
The "safety" and "decelerationism" that big tech companies have recently been advocating also looks, to me, like nothing more than building a capitalist Moat: blocking the pursuit of innovative smaller companies armed with new architectures while cementing their own oligopoly, one that only they can sustain given the enormous sunk costs of the infrastructure they already operate.
Astra costs 2.5 times what GPT-5.6 Sol costs. Yet in my actual work, the code it produces is worse. So is there any reason to use this model?
My sense is that this trend will persist for a long time. Perhaps this is the ceiling that LLMs inherently possess.
When cost is factored in, I believe there is a real possibility that specialized models will regain their importance in the future.
A model specialized for coding.
A model specialized for 3D mesh generation.
A document processing model.
A mathematics and scientific exploration model.
And an orchestration layer sitting on top to combine whichever models are needed.
It may well be that progress stalls around that point, and the programmer's choice ultimately comes down to selecting the cheapest machine suited to their work and satisfying the client with that.