How AI will impact us all?
Let's imagine possible scenarios that can enfold as AI boosts productivity in different activities related to developing software.
In this post, we will attempt to make some predictions on how AI will affect software engineering. We will go fully into guessing mode and make some bets about potential AI futures 🎲.
Some context first.
I got hooked on “vibe coding” recently 😬.
This got me excited on two fronts.
Shipping features. Simply shipping features so fast is addictive. I can sit for days and just ship features to a small product I am building (which I did already 🥲).
Triggers thinking. Productivity improvements that AI brings to software development make me think about how this productivity improvement can impact the whole software engineering landscape. It is hard to stop your mind from thinking about this and extrapolating in the process.
So this post will be a brain dump 🧠 of my thought process around this.
It will contain some predictions that I am very hesitant to share for two reasons.
Realm of possibilities. The range of all possible outcomes of AI's impact on software development is quite broad, from complete obsolescence to Jevons’ paradox (mentioned here a lot). Meaning any prediction has a high chance of turning out to be false. This makes writing about this a bit uncomfortable, as I do not want to be proven wrong in the future 🫣 (it will be fun to read this article in 5 years though).
Expertise. I am far from being an expert on AI. So this could very well end up appearing as ramblings of someone who does not know what the hell he is talking about 🤷♂️. I have some expertise in software development, though. That should soften the fall (I hope).
This is what the post will cover.
👀 Current situation. We will take a look at the current software development process and see how it works right now. This will give us a base that we can use to do our extrapolating.
🤖 Potential future. Here we will start extrapolating. This will already contain some wild and not-so-wild guesses.
🫢 Impacted roles. A lot of articles “flirting” with the potential AI future are not very explicit in trying to predict the actual impact (probably due to the same reasons I mentioned above 👆). In this one, we will try to explicitly predict which roles will be impacted and how.
💪 Preparing. How can you prepare for the software development shift that AI brings? The first two sections will already be hypotheses with a high chance of being proven wrong. We will go all-in and attach one more section that will speculate on how to prepare for this potential future scenario that might not even happen. Why not? If we are already speculating, let’s speculate all the way! 🎲
Let’s start with the current state of software development.
Where are we right now?
How are we developing software today?
Or perhaps it is more useful to take a year or so in the past as the baseline, as we already have AI impacting software development heavily (especially with startups).
If we look at how software development worked before AI coding tools, it looked kind of like this:
PM/Designer/UX researcher first works on formulating the idea.
When there is a clear enough idea for a feature, the PM will define requirements, and the designer will draft a design for the team to work on.
Finally, a team of engineers picks up the implementation and focuses on shipping it to users.
Where is the bottleneck?
How we build software right now contains an inherent bottleneck.
This is what is often referred to as the “maker-to-decider gap”.
The "maker-to-decider gap" term describes a well-recognized imbalance:
“One "decider" (PM, designer, or exec) can define work far faster than multiple "makers" (engineers, QA, infra) can build and ship it.”
The idea is:
It's relatively cheap and fast to come up with ideas, designs, strategies, or product specs.
It's slow and expensive to translate those into real, working, production-quality software.
So, implementing software has been generally slow so far.
How are we addressing the bottleneck?
So far, as implementing software has been generally slow compared to other activities involved, we were solving this by throwing more manpower at the bottleneck.
This bottleneck, combined with the huge demand for more software, is what has put software engineers in a very favourable position, compared to other professions.
There was no other way to solve the bottleneck than to throw money at it 💰. And if bags of money are being thrown somewhere, this is where you want to be.
Of course, this is not without limits. There is a limit to how much additional manpower will keep helping before it starts to slow things down. This is expressed through the famous Brooks’ law (read the seminal “The Mythical Man-Month” for more on this).
“Adding manpower to a late software project makes it later.”
Brooks argued that one of the main contributors to the fact that the addition of manpower starts to slow down software projects at a certain threshold is the communication overhead. We will come back to this later in the article.
So, in summary, the current state is described below.
✅ Roughly speaking, software development consists of activities that define what needs to be built and activities that build it (implementation).
✅ So far, the main bottleneck has been on the implementation side.
✅ We have been solving this by throwing more people (engineers) at the bottleneck.
✅ This created an imbalance between the “deciders” and “makers”.
Value / Cost ratio
We will digress a bit now to talk about the value/cost ratio.
Roughly speaking, whenever we are doing product development, two activities are happening all the time:
Betting. We are determining what the right bets to focus on are. We want to choose the most valuable features for our customers to maximise the value we create.
Delivering. We are delivering on those bets, shipping code to production, and getting that value in the hands of customers.
Both of these activities are important for an organization to be successful.
If we are not betting on the right things and wrongly estimate the potential value for the customer, then it does not matter how fast we ship it. If the product is not valuable, flawless delivery does not do anything.
On the other hand, if our delivery is very slow, we will not be successful either. If we are not able to get anything in the customer’s hands in a reasonable amount of time, or with a reasonable amount of quality, no matter how much potential the bet has, that potential will never be realised.
To summarise, product development roughly speaking comes down to:
determining the right bets and
executing on those bets.
To be successful, both of those need to align well.
Some inherent biases that are making it harder for organizations to be successful are:
builders are often overly-optimistic when estimating the time it takes to build something and
deciders are often overly-optimistic when estimating the value of a specific bet (this one is often overlooked).
Bottleneck shift
Today, we already have many AI-powered, agentic coding tools (Cursor, Windsurf, etc). These tools are already making a huge impact on software development in the startup segment, where rapid bootstrapping of greenfield MVPs to reach product-market fit is paramount. Engineers in this segment are reporting 10x gains in productivity.
I was vibe-coding an app recently, and it was ridiculously easy to keep adding features.
Segment where AI coding tools are not best at (yet) is working with existing, large codebases.
At this point, we can make our first guess.
Guess 1: AI coding tools will work flawlessly with existing, large codebases.
If we assume the above, it would follow that shipping features will become less costly.
As the product development process involves not only implementing software, but also the “betting” activities that “deciders” are working on, we need to look at it as a whole to extrapolate how things might change in the future.
It’s important to note that it is not only the implementation phase that is getting productivity boosts from AI.
The definition phase is getting faster as well.
Right now, there is a rough ratio of how much time it takes to define what to build vs how much time it takes to build it.
Let’s call it the F/B ratio for simplicity.
F/B ratio has been somewhat stable in the last decades. Software development has been consistently “slow” compared to deciding what to build, so the ratio did not change much.
Now, with the AI-powered productivity gains, things can branch out differently depending on how much productivity gains both of these activities will receive from AI assistance.
Guess 1.1: AI will introduce exactly the same rate of productivity improvements both for “defining” and for “building” activities.
If productivity gains both on the “defining” and on the “building” fronts are the same, it means the F/B ratio stays the same. Which means the bottleneck stays where it was so far, in the implementation phase.
Now, it’s important to note that there are two areas where we can focus our predictions.
How will the software development process and organizations doing it be impacted by AI?
How will the software economy in general be impacted by AI?
For now, we will focus on how processes and organizations doing software development might change.
In the 1.1 scenario, the process and the organizations around software development remain the least impacted of all scenarios. If the F/B ratio remains unchanged, you will still need to structure your processes and organizations similarly they are structured now to optimise software development.
Having the same productivity gains both for “defining” and “building” activities seems like a highly unlikely scenario. This is because these activities are inherently different. They consist of different sub-activities, and the amount of manual work prone to automation involved in them is different.
Which leads us to the next guess.
Guess 1.2: AI will introduce bigger productivity improvements for “building” and equalise how much time it takes to define something to how much time it takes to build it.
If “building” becomes equally expensive as “defining”, it means that we don’t need to throw that much money at “building”. We would roughly need an equal amount of “deciders” and “builders” to have an optimal process.
This also means that the money saved on building can be reinvested into having more decider/builder pairs so we can deliver more software.
Now, here we can take another step and even explore the scenario below.
Guess 1.3: Productivity gains in “building” will be so drastic that it will become much simpler to build than to define what exactly to build.
So roughly speaking, with the above two guesses, we are exploring a scenario where productivity gains both in “defining” and “building” activities are high, and building becomes equal to or less expensive than defining.
Where will the bottleneck be then?
One clear bottleneck is users of the product itself.
You can not just ship features infinitely fast and expect that to pay off. You can not release something at 2 pm and then release a completely revamped version of it at 3 pm and then decide to drop it and ship something completely different at 4 pm. Software adoption takes time, and measuring the adoption and success of features takes time because there are humans involved.
There is another bottleneck, though. So far, the slowdown has always been caused by the manual work. By “manual” here, I am referring to coding or UX designing activities. The activities that involve a person producing some digital artefact via some form of a language (programming language or design language). If we assume that these activities have drastic productivity improvements, then the remaining bottleneck might now lie in human communication.
Merge of “deciders” and “builders”
As building stuff and producing artefacts become simpler, communication between people is the remaining source of slowness.
Which could lead to the merge of “deciders” and “builders”.
If things are simple to ship, no decider will bother to communicate their vision to another builder and then wait for the builder to build it - they will just ship it themselves.
The other way around as well, if building is simple, then a lot of builders will exercise their “deciding” abilities that they never had a chance to do before. And the risk of failing will be smaller as they will not invest as much effort as before in testing their hypotheses. And as they test their bets more and more, their “deciding” intuition will improve over time.
This leads to the scenario where everyone is a CEO (something
wrote about here).Let’s elaborate a bit more, why a “merge”, if it becomes feasible, would be beneficial. Right now, there is a lot of back and forth between the person defining the requirements and the engineers who are implementing those requirements. Most of this is because a lot of context needs to be transferred from the PM’s brain to the engineer’s brain. There is a quote from
(the creator of the event storming technique) that goes like this:It’s developer (mis)understanding that’s released in production, not the experts’ knowledge.
If only one brain 🧠 handles everything, full context will be with the builder from the get-go. Then the experts’ knowledge will go to production. A nice example of this is GIT, where Linus acts both as a “PM” and as an engineer, leading to one of the most successful pieces of software ever built.
Ok, those are the guesses we will cover for now ✅ .
Note that there is also a potential future where defining work becomes much faster than executing it. We will not explore this alternative here. Both because I perceive it as less likely (due to a lot of manual work that is happening in the execution phase right now) and because in that scenario execution remains a bottleneck and the assumption is that money will keep pouring there, so it is a “good” scenario for software engineers and I will skip it.
Who will be impacted?
From the above guesswork, we can extrapolate who will be impacted by these changes.
Software engineers who lack customer-centricity, product mindset (whether their customer is an end user or another engineer in their org, or their product is a SaaS tool or an internal platform), system design skills, and are solely focused on execution/coding. If you are basing your career simply on your ability to know a programming language and write code, that skillset alone might not cut it in this era.
Product managers simply because when the “merge” starts happening, there will be more engineers than PMs competing for the new merged role. This is due to the above-mentioned imbalance created by the maker-to-decider gap. Not saying that all PMs will be gone, but those that will not be able to ship things themselves might be heavily impacted, as they will be going against more competition from engineers.
Impact on the economy of software
If we are talking about the software economy as a whole, several scenarios are being thrown around. Often, they are mentioned in some mutually exclusive either/or manner. I believe all of those will happen to a degree. Here are some I observed being mentioned.
Everyone who is building software right now will keep building it. They will do it faster, so they will produce more of it. In addition to that, there is a segment of people who never considered building software before, but will consider it now, as building becomes more available. More software will come from them as well. So, more software all around! 🚀
One scenario that comes up is that, because it becomes cheaper to build software, we will simply be building the same amount of it cheaper, and cut costs by cutting extra manpower. Some reject that this will happen, however, there are companies where exactly this might happen due to the nature of the role that software plays for that company.
In another scenario, a term called Jevons’ paradox pops up that states that the reduction in the price of a resource may, counterintuitively, yield higher demand for the resource. Mainly because the resource (in our case software engineer) becomes more widely available to consumers who could not afford it before. Think about all those friends you have who asked you to build them an app for an idea they had, because they could not build or fund it. Some segment of those people will get into the software economy now, either directly as a vibe-coder or as an investor (as building is accessible to them now).
As building software becomes cheaper, some bets that were too ambitious before and did not have a good enough value/cost ratio might get prioritised now. Meaning, again, more demand for builders to work on those ambitious projects.
Software should become more awesome, as we can build faster, we can iterate on feedback faster, and evolve it like we never could before. Also, who knows what those more ambitious projects will yield.
How to prepare?
For both software engineers and PMs, the preparation for the future could look the same.
Go and vibe-code an app you've always wanted to build 👩💻 🚀
It can be a small note-taking app for yourself, or a game you always wanted to create, but never had time for 💪.
As an engineer, building your product will put you in the driver’s seat and force you to think about how to market your product, how to get feedback, how to monetize it, etc. Perhaps you will even be inspired to read a book about marketing or finding a product market fit. Be the CEO of your own company.
As a PM, it will finally give you that superpower that in the past required a dependency on someone else. In all honesty, from my experience, agentic coding tools (although amazing) might not be fully there yet to support someone with exactly zero knowledge on how to build software. But I would recommend at least trying to see where this leads you. I am basing this on the fact that in the last app I was building, I think 95% of my prompts were PM prompts.
Final words
Ok, that was a lot for a first ToT article I fully authored.
I am very curious to hear your thought process around this topic.
If you believe that some of the guesses do not make sense and you have your own, do drop them in the comments 💬.
I would like to learn more about how you think about this.
All that guessing is tiring 😓.
I will go back to the relaxing vibes of shipping features now ☕ 🧑💻
See you soon! 👋