The Evolution of Software Engineering Productivity
From computing power as the bottleneck to human judgment as the constraint. This is how the software engineering productivity has evolved over the years.
This week’s newsletter is sponsored by Blitzy.
The Future of the Agentic SDLC
Blitzy is the first autonomous software development platform with infinite code context, enabling Fortune 500 companies to ship 5x faster from Figma design to production code.
While individual developer tools like co-pilots struggle with context and only autocomplete code, Blitzy is engineered specifically for enterprise scale codebases.
Its deep understanding of your codebase and design standards paired with specialized agents enables Blitzy to clear years of tech debt, execute large-scale refactors or deliver new features in weeks, not quarters.
The Blitzy edge:
Self-improving knowledge graph: Ingest millions of lines of code and map every line-level dependency creating a dynamic knowledge graph of your codebase.
Figma integration: Reads every node in your Figma file, honors your design system and component libraries. Generates responsive, pixel precise, production-ready frontend code that integrates seamlessly with your existing backend.
Agent orchestration: 3,000+ specialized agents autonomously plan, build and validate production ready code using spec and test-driven development at the speed of compute.
End result: Over 80% of the work delivered autonomously, 500% faster.
The future of enterprise software development is here.
Thanks to Blitzy for sponsoring this newsletter. Let’s get back to this week’s thought!
Intro
Today, generating code or adding more features to a product is no longer a constraint. But it wasn’t always this way.
In the early days of software engineering, the speed of implementation directly determined the speed of delivery. The faster you could translate logic into working code, the sooner the software could be released. Productivity was tightly coupled to typing, knowing the syntax. The definition of a “great engineer” reflected that reality.
But what’s important to understand is that what made you exceptional 20 years ago is not what differentiates you today. The constraints have changed. And when constraints change, so does the skill set that creates leverage.
In today’s article, we are going through how software engineering productivity has evolved over the years, and what are some of the most important things to keep in mind to thrive in your role as an engineer/engineering leader at this time.
To help us with this, Francisco Manuel Soto Ramírez, Software Development Engineer at Amazon, is our guest author for today’s article.
Let’s introduce our guest author and get started.
Introducing Francisco Manuel Soto Ramírez
Francisco Manuel Soto Ramírez is a Software Development Engineer at Amazon and author of the newsletter called Strategize Your Career. He regularly shares interesting articles based on his experience there.
I’ve known Fran for quite some time now, and I’ve read quite a few of his articles, therefore I am happy to have him as a guest author today.
Let’s start!
Productivity in software engineering is constantly changing
Productivity in software engineering is not a static metric because the definition of value changes constantly.
Being a highly effective engineer in 1990 required a completely different set of skills than it does in 2026. We are currently undergoing the most violent shift in the history of the industry.
Software development has moved from a model of rowing the boat, which prioritizes pure effort and logic construction, to a model of steering the boat, which prioritizes judgment and orchestration.
The barrier to entry for writing code has dropped to near zero. The new barrier is trusting the code that has been generated.
To trust the output, we need to understand:
What good looks like
We also need to know exactly what to ask for in the first place.
Henry Ford famously noted that “if he had asked people what they wanted, they would have said faster horses”.
A regular user often struggles to build a high-quality application because they are dealing with a lot of unknowns about what makes software usable and scalable.
In order to understand it better, let’s go through the history.
The era of scarcity (pre-1980)
The primary bottleneck in this era was access and pure computing power. Computers were physical destinations rather than personal tools, and they were incredibly expensive resources.
Feedback loops were often 24 hours long. You would submit a deck of punch cards, wait a full day for the batch process to run, and potentially receive a syntax error that required you to start the process all over again.
The cost of a mistake was measured in days rather than seconds.
The productive engineer in this environment was defined by mental compilation. This was the ability to simulate the machine in your head to ensure perfection before execution. Since the computer was a scarce resource, humans had to adapt to its limitations.
Peer reviewing was implemented during this time as a cost-saving measure for the machine. If the cost of executing code is too high, we allocate more human costs to reduce the waste of computer resources.
We used human brains to pre-validate inputs because the machine was too valuable to waste on bad logic. This dynamic established a precedent where the human was the cheap resource and the computer was the expensive one.
The era of the “blank page” (1980–2010)
The bottleneck shifted from hardware to logic construction. The personal computer and Moore’s Law made compute abundant, so the machine was no longer the primary constraint.
The new struggle was the blinking cursor problem.
Engineers faced the difficulty of translating abstract thought into strict syntax from scratch. They were solving bigger problems, and that required more cognitive resources.
There was a significant anxiety associated with algorithms because you could not simply import a library or framework as you can nowadays. You often had to work on things like sorting logic or memory management yourself.
Productivity was defined by syntactical fluency. The best engineers had memorized APIs and standard libraries to reduce the friction of looking things up in physical books or slow documentation.
The standard practice was for developers to maintain personal text files of useful code blocks to reference later. This reduced the cognitive load of facing the blank page every time a new feature was needed.
The end of this era was the combination of open source, Google, StackOverflow, and high-level frameworks.
These tools turned logic into standardized blocks. You no longer need to write your own HTTP server to put a website on the internet. You can spin up a basic web application with a single command.
The value of memorizing syntax dropped as access to collective knowledge became instant.
Funnily enough, I think most universities still live in this era and the previous one.
I had to do exams on paper, without a reference to the standard library, and of course, without checking Google or Stack Overflow (I left university way before LLMs).
There’s value in knowing how to implement your own data structures and the algorithms, I won’t deny that.
But there’s no value in tying one hand to a student’s back when learning: They will arrive in the real world and realize they have some fundamentals, but the methods that got them here won’t get them there.
The era of constant contact (2010–present)
The bottleneck moved to attention and fragmentation. Tools like Slack and Teams solved the problem of communication, but simultaneously destroyed the ability to do deep work.
The challenge was no longer writing the function itself. The challenge was regaining the mental model of the system after each interruption. The cost of context switching became the primary drag on output.
Engineers adapted by adopting defensive behaviors. The productive engineer blocked out their calendar with fake meetings to secure focus time. They used noise-canceling headphones as a do-not-disturb sign to ward off casual interruptions.
The division between a manager’s schedule and a maker’s schedule became a critical discussion point. Makers learned to batch their communication to preserve long stretches of silence required for complex logic.
I know I wrote things in the past sentence, but this era has not ended. It is perhaps more present than ever. However, we are beginning to pay more attention to the costs of this fragmentation, so hopefully we’ll overcome it soon.
We can now use AI to summarize information or search for it better instead of asking a colleague and interrupting their flow. The tools that caused the distraction are now being used to manage it, but the fight for attention remains a defining characteristic of modern work.
The era of the pilot (2023–present)
We have entered a phase where the bottleneck is verification and direction. Logic has become a commodity because AI generates functions instantly. Compiling errors, linters, and other static analysis tools allow AI to iterate with these tools until it gets a working output.
The bottleneck is no longer how to write code but determining exactly what code to write.
All engineers can now produce code that works. The difference between a junior and a senior engineer is that the senior has “taste”. They know how to write code that is maintainable, extensible, and easy to reason about. They ensure the code does not work against the team in the future.
A dangerous trap in this era is being on both sides of the spectrum.
Avoiding the use of AI and adopting new workflows
Some engineers may think software engineering is a craft, and they are cheating if they use AI, so they may use AI but still be involved in the low-level steps of the process
Having too much trust in AI’s output
Some other engineers may think AI is like another software engineer they can trust, so they trust their judgment as you’d probably trust a PR that was written by one engineer, reviewed by another 2 engineers, and everyone was aligned.
You’d trust that engineer to find out the requirements themselves instead of doing the upfront work of providing detailed instructions on what you expect as output.
It is effortless to generate code, but exhausting to read and understand it.
This causes a rise in code slop similar to the low-quality content flooding social media. If you do not understand the underlying logic, you cannot verify if the AI has introduced a subtle bug or a security vulnerability.
This era allows solo iteration on a scale that was previously impossible. Engineers can iterate on complex architectures alone.
Before, they’d have had a lot of communication costs to coordinate an entire team. You can go very fast if you manage well the AI’s context window, feeding it the right documentation at a time. Debugging has also shifted. Now, AI is the first line of defense to explain stack traces.
Since the bottleneck is knowing how to properly use AI, there are 2 aspects to overcome it:
Learn how AI works. Everyone uses ChatGPT, but few people know what a system prompt is and how the “memories” and the “personalization” work.
Learn from others. The quality of your prompts is directly proportional to the quality of your knowledge. Both Junior engineers and Senior engineers will have access to the same model, with the same intelligence, but the senior engineer will have better results.
The future: (2026+)
We are the slow link in the chain. As code generation becomes virtually free, codebases will balloon in size. The difficulty shifts to the negotiation between the APIs of multiple AI agents.
The idea of a human-in-the-loop sounds good until it’s impossible to maintain at a large scale. You cannot manually review fifty pull requests an hour. If you try to review every line of syntax, you will drown in the volume of code.
We must apply the lessons from the first era in this article. When computers were scarce, we added human costs to protect the machine. Now that our brains are a limited resource, we must add computer costs to protect ourselves.
A CTO does not review every pull request in a large company because they work on higher-leverage problems. Engineers must also move further up the stack. If we have 100 tasks and can only complete 10, we must choose the 10 with the highest impact.
The productive engineer of 2026 moves up in the value ladder. They shift from writing code to writing requirements and prompts as code. They focus on reviewing behavior rather than syntax.
The question becomes whether the feature works for the user, not whether the variable is named correctly.
Syntax is still important, don’t get me wrong, but it should be managed by automated tools and system prompts rather than human eyes. We already use linters because reviewing for spaces or tabs indents doesn’t scale.
Stop operating inside the system, rather start designing the system. We must build the factory rather than the car.
Some actionable strategies
The first strategy is about context management
Stop asking AI to build a login page without context. I’d recommend defining the data structures and the flow first. Use AI to generate the skeleton based on your already reviewed data schemas.
If the data and flows are solid, the logic becomes easier to generate. AI is terrible at guessing intent but great at following contracts.
The second strategy is about agents working autonomously
You design a sandbox environment and create a feedback loop that AI can iterate on. Humans need to stop reviewing broken code. We need to implement workflows where AI agents work in their own container.
They will run until compilation, linting, and unit tests pass. This is about shifting the cost to the machine rather than the human. You only review the code that works, considerably reducing the amount of code you review.
The third strategy is the aggressive automation of bureaucracy associated with knowledge workers
All knowledge workers have a bureaucracy fee. If a task is not core in your role, you should not be doing it. Use LLMs to generate meeting notes, action items, and documentation updates.
We are all doing higher leverage activities. This liberates your scarce brain resources for high-leverage architectural thinking. It’s important that you outsource the administrative work, so you can focus on the more important things.
Conclusion
We are entering a time where a single engineer can do the work of an entire team from 10 years ago. The leverage available to the individual contributor has never been higher.
However, this requires a fundamental shift in mindset. You cannot continue to work the way you did five years ago and expect the same results.
The senior engineer of the future is not the one who knows the most syntax or who can type the fastest. It’s also not the one who compiles the code in their head.
It’s the one who understands the problems that the organization is facing and uses AI tools effectively in order to create a meaningful impact.
We still have to overcome the constant distraction, the high cost of context switching, and the dangerous accumulation of AI code slop. That’s the focus of my writing, so we have a long way to go to build these guardrails.
Stop rowing the boat. Start steering the ship.
Last words
Special thanks to Francisco for sharing his insights with us. Make sure to check him out on LinkedIn and also check out his newsletter Strategize Your Career.
He regularly shares interesting insights from his experience there.
We are not over yet!
dailytips.dev newsletter
My friend Marko Denic has just started a daily newsletter for developers who want to improve their skills in all aspects of coding.
And for Engineering Leadership readers, when you subscribe, you also get a free guide on how to make better technical decisions as an engineer.
Liked this article? Make sure to 💙 click the like button.
Feedback or addition? Make sure to 💬 comment.
Know someone that would find this helpful? Make sure to 🔁 share this post.
Whenever you are ready, here is how I can help you further
Join the Cohort course Senior Engineer to Lead: Grow and thrive in the role here.
Interested in sponsoring this newsletter? Check the sponsorship options here.
Take a look at the cool swag in the Engineering Leadership Store here.
Want to work with me? You can see all the options here.
Get in touch
You can find me on LinkedIn, X, YouTube, Bluesky, Instagram or Threads.
If you wish to make a request on particular topic you would like to read, you can send me an email to info@gregorojstersek.com.
This newsletter is funded by paid subscriptions from readers like yourself.
If you aren’t already, consider becoming a paid subscriber to receive the full experience!
You are more than welcome to find whatever interests you here and try it out in your particular case. Let me know how it went! Topics are normally about all things engineering related, leadership, management, developing scalable products, building teams etc.
 | A guest post by
|