In my last post, I offered a bleak outlook on the future of developers. The truth is simple: today’s LLMs pose a serious threat to software startups.
We ended our free online service for several reasons, but two were decisive:
hacking attempts, license violations, and covert use of our product by scam aerospace startups in Korea; and
a surge in LLM-driven intrusion attempts.
Our product, DEEP BLOCK, is a web app with a JavaScript frontend. That’s the structural weakness: browser scripts can’t be hidden; they must ship to the client. Meanwhile, the internet is saturated with open frontend code. Obfuscated code is the exception, not the rule, so LLMs have had no shortage of training material.
We’ve invested several million USD in the frontend alone. DEEP BLOCK isn’t “just frontend,” but building a GUI that handles massive images and supports a no-code workflow took years of trial and error. Realistically, at least half of our total effort went into the frontend. The codebase is now too large, and maintaining it is hard.
LLMs, however, have absorbed the world’s web stack. They can use most frameworks, libraries, and TypeScript with striking fluency. The confidence we earned by shipping complex web software is eroding as LLMs keep improving. In time, small companies that once sold “software prowess” may find they hold no meaningful technical edge.
Look at ChatGPT: the core inference and their business logic runs on the server without showing their code on the frontend; most user interaction is just a text input.
By contrast, pushing our entire workload to the backend would damage our product performance, so we’re forced to expose implement frontend code. And once we put a free web app online, that code is crawled and ends up training the very models we compete with.
It’s an asymmetric game. LLM service vendors can hide their crown jewels behind APIs; companies like us, who invested heavily in the client, lose our business secret the moment we open the door for end users. Maybe our code’s edge is already gone anyway; LLMs may have surpassed it. But this isn’t just our dilemma—it’s a systemic problem for many small software firms.
Coding is now democratized. People who couldn’t code can now build things. They can’t yet assemble complex product easily, but the trajectory is clear: the code quality of LLMs will get better and better.
Smaller firms—constrained by scale—will struggle to keep an advantage. Less experienced teams can use LLMs to accelerate implementation, compressing the gap between “strong CS” engineers and everyone else.
Some will disagree. But the last two years of progress are hard to dismiss. LLMs don’t sleep, and code is also tokenizable text.
In this world, my remaining strengths are:
I can give more complex instructions, read dense generated code, and deliver rapid feedback.
Yet even that makes myself miserable.
To increase my productivity, when I push myself to the limit while using prompts, I often feel like a driver or pilot, skimming vast streams of tokens and reacting in real time. After a day of that, the dizziness sets in—and I feel like GPT’s assistant, not its master.
I applied to Google Korea when I was about to graduate and was rejected; I wasn’t smart enough for Google, and I knew it.
Now, though, both Google’s engineers—and bootcamp juniors who never studied computer architecture—can’t out-code LLMs and can’t work comfortably without them.
The gap between a Google engineer and me—and between me and someone who’s only studied for a few months—has shrunk dramatically.
The one hopeful angle is this: the knowledge gap between me and a Google engineer is smaller than the gap between me and a non-coder. That means our prompt quality isn’t worlds apart.
Meanwhile, big software firms are raising productivity while laying people off. Survival gets more and more difficult: either be massive—or be a small, hyper-efficient team that squeezes LLMs to the limit. Everyone else gets squeezed out.
Ever since I was young, my father, teachers, and professors instilled in me the importance of working hard and staying diligent.
But after more than twenty years of grinding to learn and stay competitive in jobs, business, and software, I’m no longer sure effort means what it used to.
For now, my experience, habits, and knowledge still help.
But will they, two years from now? Ten? I’m not certain.
This isn’t just my worry. It’s the question every small founder who invested heavily in software must ask.
Going forward, the winners in software may be determined less by technology and more by business models, efficiency, and economics.