The mood in the industry is anxious, to put it mildly. Panic spreads across the ranks, from junior developers to CEOs, manifesting in public freak-outs amplified by CEO-superstars’ somewhat repetitive claims that these next six months will surely be the end of your job and your business. One of the many ironies of the current situation is that those who believed they were creating the future have instead received a future shock.
The impact on developer productivity is real, and our own results at Globberry are quite impressive (see how we started using LLMs for coding in this post).
A crisis itself is not as scary as waiting for it or anticipating it. I can say that confidently, as a Ukrainian. But in order to relieve that anxiety, let’s first figure out how we got here in a world of AI software development.
How Software Development Became Too Focused on Coding
From the very beginning of my career in software development as a junior developer, the industry became increasingly competitive. Demand for software grew exponentially, yet was still outpaced by supply. The pressure to deliver more and more features, faster and faster, turned many projects into true panic-stricken, hysteria-prone nests of overwork and burnout. No need to explain further — each of you has been there many times.
Those standing on the critical path of such projects were coders; they became the most valuable resource. Managing their tasks became the main focus, while all other roles became auxiliary. In the minds of many, software development slowly became synonymous with — or even reduced to — writing code. Hence the fear: if you automate coding, you automate software engineering itself. Hence the fear: if you automate coding, you automate software development.
It was not particularly good for coders either. Their work became less creative over time, gradually evolving into something closer to an assembly-line position, where they were evaluated by lines of code, commits, and pull requests — grinding through overtime, unrealistic commitments, and worst of all, useless work building products or features that no one used. In many companies, coders, if not directly prohibited from doing anything but code, are actively discouraged from broader engagement, as it is considered wasteful and delegated to auxiliaries such as business analysts and QA engineers. In older times, such experiences were called alienation. I understand the term has fallen out of fashion.
AI and a Return to the Real Meaning of Software Development
In very old times — at the dawn of my career — when far less software existed and was being produced, I witnessed a quite different approach to software development. Developers were not prohibited from learning the subject matter; they were encouraged to research, analyze problems, and engage in deep thinking. Those who were good at coding were promoted into roles that involved less coding and more design and reflection (myself included). Can you imagine this now?
It produced less stress and burnout, and despite the process appearing slower, it arguably yielded better results in terms of software quality, feature adoption, and overall success rate.
Why Domain Knowledge and Customer Understanding Still Matter
So here is my first takeaway: the key opportunity of the AI revolution in coding — and in AI software development more broadly — is a return to a more holistic understanding of software development, with emphasis on quality of deliverables, understanding customer needs, and deep domain knowledge as the primary success factors, rather than shipping useless features faster.
Value is created by understanding precisely how software can solve real — not imaginary — needs, and by aligning software quality with real customer needs.
I see this as a potentially liberating experience for everyone, developers first among them. Maybe it will even reduce the corporate productivity theater — that strange role-play everyone hates, probably even more than working weekends.
The Risk of AI-Generated Complexity in Software Ecosystems
It should not surprise anyone that the software ecosystem in our industry is already extremely fragile, raising real questions about long-term software sustainability. The reasons are partly objective — management systems grow complex because networks and processes are complex — but they are also partly human-made.
For years, vendors kept shipping more despite declining adoption rates and the obvious uselessness of many features — sometimes entire systems. Customers encouraged this by requesting features “just in case” or because “we might need it someday,” driven by procurement processes rather than real necessity. What often went unnoticed was that every additional supported feature or rare use case imposes a real, if invisible, complexity tax on the ecosystem — one of the emerging AI coding risks in modern software environments — making it brittle, fragile, expensive to own, and difficult to change.
This new abundance of coding — vibe coding, AI-generated code, and shipping in minutes — risks creating even more nightmarish environments that no one will know how to maintain, troubleshoot, or restore after failure.
What AI Can and Cannot Replace in Software Engineering
Have we finally reached the full reversal of the “Learn to code” meme? Should those at whom this phrase was once thrown feel satisfaction and reply with “Learn to drive a truck”?
Before rushing to final judgments, I suggest everyone familiarize themselves with two things.
First: the principles and high-level mathematics of transformer architecture behind LLMs for coding. Why is this helpful? Because our brains naturally anthropomorphize. We cannot help but see LLMs as something like us — conscious, understanding, even possessing character. Realizing that an LLM is fundamentally a brute-force statistical matrix multiplication engine operating at colossal energy expenditure — and nothing close to a human brain — is clarifying.
Second: the book Seeing Like a State, which explains how underestimating practical experience and local knowledge repeatedly doomed ambitious one-size-fits-all projects. LLMs and AI coding assistants are wonderful, almost magical productivity boosters. They contain generic knowledge of coding. But do they understand what your customer truly needs? No. Are they bug-free? No. Do they hallucinate? Hell yes.
The Future of Software Development After the AI Shift
If we refocus on customer needs, software quality, and deep domain knowledge, we can provide real guidance to our customers. We can build robust software and protect them from overreaching — from wishing for everything they can imagine.
But first, of course, we will have to clean up part of the mess that AI coding is about to create in their software ecosystems — which is also part of the broader future of software development. 🙂

