Most content about AI model predictions is not going to age well given how quickly the frontier is moving on what is possible these days. Yet, I find it useful to write such articles as they form the basis of the ongoing conversations about how those models are going to impact all of us in the tech industry.
After my recent trials with vibe coding, I wanted to push the experiment further and apply second-order thinking to project what software engineering will look and feel like in a future in which every software engineer is “augmented” with LLMs.
When you think about it, asking LLMs to write code is not so far from the experience that product managers have today with human software engineers. Most product managers are not technical enough to verify that the products built by software engineers are accurate, correct, and secure. To them, the software is a black box, and they have to trust that the software engineers understood the user stories, and that the QA engineers wrote the right set of tests. This is pretty much what vibe coding is all about, except one asks an LLM to write code instead of a human.
And of course, a product manager might notice bugs or issues, which are logged as tickets for the team to look after. This is similar to the process one has with an LLM, by inputting error logs into the model or asking it to make changes, or even with agentic AI systems that detect error messages and automatically pipe them into additional LLM iterations until the code compiles and the requirements are met.
Software engineering will move away from writing code using programming languages to writing PRDs and acceptance tests, what I call “requirements-as-code.” This is because if you are able to describe your requirements with enough context and details, and if you can correctly describe the expected behaviors to test, then the AI models will be able to both build what you want, and deterministically test all assumptions to guarantee that the code is accurate and correct.
It does not matter what’s in the code as long as you can guarantee that its outputs are what you expect for a given set of inputs. And it might not be entirely correct all the time, just like software written by humans, but if the guarantees are met 99.99% of the time, then they are correct enough to meet commercial standards and be shipped to production.
Just like infrastructure-as-code became a thing over the past decade, we are going to see requirements-as-code becoming the new thing, with new industry standards being created to describe PRDs in a clean and maintainable way for LLM inputting, and those PRDs will be stored with version control repositories to track changes.
Now you might ask, why would we need requirements when we have the source code, can’t we just use the code as requirements? Yes and no.
Yes, ultimately the code can act as your requirements, but also no, because if you rely on the code, then you’re still thinking like a software engineer of the year 2025.
Remember, this is already the future, we’re in the year 2030, and most software is now a black box, just like assembly code is an alien language to most software engineers. Having the source code isn’t particularly useful if you can’t read code so well, what you want is a set of requirement in a natural language, so that as a human, you can understand what is present or missing in the expected behaviors, and so you can make adjustments easily if needed.
Those requirements will be separated into categories, like functional requirements, UX/UI design requirements, data model requirements, and security requirements.
Until now, vibe coding meant endless back‑and‑forth with an AI model. Agentic systems remove that friction: they iterate in a closed loop until the code meets every requirement and clears all acceptance tests, without the need for human intervention. You could even have multimodal AI models perform end-to-end testing from the final consumer’s perspective.
Traditional tooling like package managers and CI/CD pipelines will collapse into one “Regenerate and Validate” button that triggers everything, from architecture generation down to final QA testing.
Below is a simplified diagram that illustrates what the process of writing software will become in the near future. As a human operator, you will write requirements and tests, and then everything else will be a black box.
The Main Implications of LLMs for Software Engineering
Based on the above, it’s now only a matter of a few years until a high percentage of all human-driven programming goes away. I spent some time projecting into a second-order thinking what are the main implications I’m forecasting. I had a hard time organizing them holistically so instead I’m presenting them individually in the sections below.
1) Most software engineering will become “requirements-as-code”
Software engineering will move away from writing code with programming languages to writing requirements and test scenarios in plain English.
This is because if you are able to describe your requirements with enough context and details, and if you can describe the expected behavior correctly, then the AI models will be able to both build what you want, and deterministically test all assumptions to guarantee that the code is accurate and correct. It does not matter what’s in the code as long as its outputs are what you expect for a given set of inputs.
We will see new standardized “requirement languages” or DSLs (Domain-Specific Languages) for capturing the intent behind software, and for ensuring that AI models deliver requirement correctness, just like compilers must adhere to official language specs. New job titles will be introduced such as “intent architect” or “requirement auditor.”
2) Not all software engineering will disappear
Using LLMs to code is a natural progression of the abstraction trend we’ve seen over the past 70 years. In the 1950s, all programming was done assembly, and then high-level languages started taking over. Fortran appeared in 1957 and Lisp in 1958. The C language came in 1972.
Although developers could write code only in a high-level language, they still had to know how the compiler translated that code so they could achieve certain optimizations, for example loop unrolling or inlining small functions. These were really just accidental complexity, and smarter code pattern recognition was added to compilers in dedicated “optimizer” layers. This allowed compilers to implement such optimizations better and all by themselves, removing this additional cognitive load from software engineers.
And anyway, how many engineers today are looking at the output of compilers? Almost none. Engineers write code in programming languages, and that gets translated into machine code, and we have built enough guardrails around this process that its outcome is deterministic and trusted.
Every new software technology is just another layer of abstraction, and has led us to the point that entire cohorts of engineers only know about the layer their job requires and they never peak through the lower layers or try to understand how things work from top to bottom.
Even if multiple layers were invented since Assembly, Assembly didn’t entirely disappear. For example, even today VideoLAN has a core team of assembly developers writing video codecs purely in assembly. Their dav1d project, an AV1 cross-platform decoder, is 30k lines of C and 210k lines of hand-written assembly (and you can learn more about dav1d in this interview).
LLMs are just that, yet another layer on top: human-led programming will not disappear, it will just become a more niche and specialized job.
LLMs won’t replace all programming evenly. Use cases for industries or technologies where there is a lot of open source code will be more replaceable. This means we’re not likely to see LLMs do well at programming anything for military or nuclear applications, simply because all of that is well-guarded proprietary code.
3) All code-maintainability technical debt will disappear
As long as you have the requirements written somewhere, you can just ask the AI models to reimplement everything with whatever combination of technologies, and you don’t need to worry about a library or SDK version becoming unsupported: you’ll just regenerate that piece of code asking the model to support whatever library version you need.
Likewise, decisions on poor software patterns will no longer require engineering time down the line to refactor anything: engineers will mostly rely on “requiements-as-code” and treat the generated code as a black box anyway.
And again, it does not matter how bad the code is inside as long as it functions according to requirements and that all edge case tests are passing with 99.99% accuracy. Poor code modularization or other anti-patterns will also no longer be a bottleneck to extending the software: extending will just be a matter of adding additional sections to your list of requirements and asking the AI models to either regenerate everything from scratch or modify only a subpart as needed.
4) Data will be the new bottleneck
You can always easily regenerate or change the code with the requirements-as-code approach, but you cannot easily change how your data is stored.
LLMs make code cheap, but they are not changing the fact that the physical limitations about data remain the same. The speed at which data can be read or written, and the speed at which data can be transferred over the network and around the planet still depends on the same laws of physics.
This means that even though you’ll be able to regenerate the code based on requirements, you won’t be able to easily migrate your data or make changes to your data models. Any mistakes with data models and storage made early on in a project will have compounding effects down the line. This also implies that decisions around data models and storage will have to receive more scrutiny and involvement from humans, and that this cannot be left entirely to the AI models. We will hear more about issues related to “data model technical debt,” or “data debt.”
Another point about data is interoperability: having great AI models and even MCP and other connectors will be limited by the fact that many companies have their data siloed into various platforms or SaaS providers, and that creates yet another limitation on the useful applications of LLMs.
5) QA engineering will be more critical but it will also change drastically
Using LLMs at scale to generate code gives to QA engineering a huge role to play to guarantee that the code behaves in certain ways under certain conditions, because this will be a critical step in creating trust in the code generated.
Consequently, QA engineering becomes even more important than it is today, along with all the processes around it. Given that LLMs make code cheap to generate, code bases will no longer be high-value intellectual property to companies, and instead, the comprehensive sets of requirements and test scenarios will become the new high-value intellectual property.
But QA will also be disrupted by AI models: LLMs will bring more advanced automation of test creation, with user-flow simulation and specialized multimodal LLMs that will automate the cataloging of corner cases, and produce failure scenarios far beyond what current human QA engineers can do.
Finally, a massive problem to solve in QA pipeline for AI-based systems is security: for now LLM code shows many security vulnerabilities, and automated security checkers will have improve in order to not let AI-built software systems expose vulnerabilities in production. This is not optional, for example the EU AI Act has been in force since February 2025 and will enter full compliance in by 2027.
6) Architectural design remains a moat (for now)
LLMs are becoming good at programming because there was a large body of open source code that could be used for their training.
It’s not like we have large quantities of formalized architecture descriptions, or data model descriptions, and how they behave at scale under various systemic pressures. This explains why LLMs are less performant (at least at the time of this writing) at creating scalable systems and data model design, and why these two fields could keep on requiring heavy human expertise in the years to come (and consequently, are good fields to double-down on if you’re a software engineer).
Just like with data, architectural mistakes can compound over time, especially if the sets of requirements and tests are not well structured. For instance, if you have the wrong service architecture, even though LLMs allow you to generate the code for the individual services, the overall system topology will keep on showing the same fundamental design issues. From that point on, traditional code-related technical debt will give way to “integration debt,” and “architectural debt.”
After some point, we might see models that can develop excellent system design skills, but we haven’t seen those yet, simply because once again, there isn’t enough quality training data to feed the AI models for that.
7) Software is eating the world, but LLMs are eating software
Software has allowed the automation of many business, manufacturing, and industrial processes for more than 50 years. This meant that companies that embraced software were able to scale their business faster and further than companies that lagged and were stuck in the analog world, simply because they could scale their cost of operations at a better rate.
And now that AI models are eating software, software companies will get disrupted by companies developing with AI simply because their cost of operations will be lower. Those that don’t adapt will be the new analogs left behind.
What’s next?
In my next articles, I will share more insights on what LLMs will change for software engineers and tech managers in general. Stay tuned!
Be First to Comment