Code got easier, reality stayed hard
The volume of bold claims surrounding LLM powered engineering has gone vertical lately. Every week brings a new prediction about instant products, infinite roadmaps, and software that builds itself. These make for catchy headlines that power cool newsletters, but they also sidestep the deeper realities of how durable, market ready products get built and how stubborn the market is when you actually engage it. Instant code does not mean instant product.
The problem is not the tools. It is the way we seem to be talking about them. The current narrative frames LLMs as the missing key that changes the physics of product development and makes old constraints irrelevant. That framing feels off and willfully oversimplified.
There is no question that LLMs are a breath of fresh air for engineers. They remove tedious work we are all happy to lose. They help with boilerplate, refactoring, tests, documentation, and cleanup. Some companies are collapsing entire layers of internal engineering and review with these tools. It is real progress and it makes the work nicer. But the rhetoric seems to continue to position "the coding" as the historical bottleneck to innovation. It is fun to say that because anyone can now code, hyper-targeted products will appear instantly, fill every gap, and fundamentally change the economics of technology. Maybe... But the code has not really been the barrier for years. The real hurdles are everything that surrounds it:
architecture
state
integrations
infrastructure
security
QA
compliance
scaling
reliability
release management
and above all the long, slow loop of getting real paying customers to adopt something and stay.
AIs speed up the edges, but they do not collapse these constraints. They do not move procurement. They do not fix broken workflows inside hospitals or banks. They do not create trust or manifest credibility. They do not give you the market signal that keeps a business alive.
I will gladly acknowledge push back from those who point to modern models that eliminate the need for traditional APIs or tools that scaffold full microservices or agents that can write and repair their own code and even synthesize market data. All of it is useful in the right context. These shortcuts help during prototyping and exploration. They remove ceremony. They accelerate early scaffolding. They make certain internal tasks faster. But production software still needs predictable boundaries. It needs correctness, versioning, observability, security, market fit, and long term maintainability. The shiny parts do not remove the physics underneath. There is still engineering on every front.
This is why the fears and fantasies of a market flooded with instant weekend products feel misplaced. People do not buy products because they were built quickly. They buy things that fit into their world, work as promised, and do not break the things around them. The same stubborn barriers that have always mattered will keep mattering.
What excites me is not the idea of instant, economically disposable products. It is the idea of removing enough friction that smart people can go solve smarter problems. Engineers get to engineer. Medical professionals get more time to provide care. Teams get more cycles to do the work that actually moves society forward. And if, as part of that, we get a deluge of noisey, half-baked products, I am equally confident they will collaps and fade away the same way all bad products fade away.
I don't know what will happen next, but I do know no one wants to pay for something that was built in a weekend.