Disclaimer: this article was written by an organic sentient being, me, and not by an AI. All typos, mistakes, and repetitions are mine, and I am proud of them.
I tend not to trust my own understanding of a topic if I have just read a description of it, or watched a video. My level of understanding is several orders of magnitude better when I’ve been learning a topic by actively engaging with the topic for example by trying to build something, because a lot of the deep understanding of something only happens when you interact with it, and when you observe it collide with the real world.
For example, I’ve written compilers to understand how programming languages work, I’ve written a persisted key-value store to understand large-scale data storage systems, and more recently, I wrote a crypto payment system to understand the Ethereal blockchain and its ecosystem.
Everyone nowadays is selling us their AI skills, AI best practices, and God’s truth on how we are supposed to use AI. I’ve myself drank the kool-aid only to wake up to the reality that all these people are only using persuasion and marketing tricks but not proving anything, and if I wanted to understand the impact of AI on software engineering, then I would have to develop my own system and workflow, and see it run in wild.
So my idea was simple: build an AI workflow, apply it to a few projects, and observe myself interact with it to see what new habits I’m adopting, what I’m learning, what works and doesn’t. After a few weeks, I would extract the guiding principles behind my decisions, as a way to gain a deeper understanding of how those systems work under the hood, and equip myself with some mental models of how one should interact with such systems in the future.
Nine weeks and 421 commits later, I’ve built a workflow which I’ve named Backlog Loop and released on GitHub, and in this article I am sharing what I’ve learned. I don’t recommend that you should use this tool, but rather, read about the issues and limitations with AI that it helped me uncover.
Disclaimer: this article has been written 100% by me, a human being, using mechanical finger typing. All typos and lack of stylistic taste are entirely mine.
I haven’t taken to this blog for a year now. I changed jobs. I was busy with family matters. I got into a rabbit hole of tokenmaxxing building a coding harness for writing code I can trust with LLMs. And I took notes about things I wanted to write about, but I thought to myself that won’t be of any interest to anyone, so I didn’t write them. But in the end here we are, It thought maybe I would write something that would add some value to someone somewhere, and that would be worth reading instead of reading it from ChatGPT, Claude, or any of their derivatives.
So here we go. I’m worried. I’m worried for us.
I don’t want this to be yet another AI doomer article. I do believe AI can and will automate software engineering once we manage to solve the problem of ensuring code correctness with 5-nine reliability at scale. We will get there, it’s not about if but when.
I’m not worried about AI taking over as the paperclip maximizer. I’m worried about us humans losing our ways. Losing the simplicity of appreciating another human’s presence, giving a smile to someone without expecting anything in return, feeling someone’s skin and looking into his or her eyes as you shake hands. I’m worried that through addictive apps and AI interactions we are going to atrophy our ability to empatize with other living beings to the point of becoming a society of lonely self-absorbed narcissists with culturally ingrained sociopathic tendencies.
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.
Human inputs requirements and tests, and the AI models handle everything in between.
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.
As of April 2025, the frontier has moved to AI Agents and Agentic AI. And yet, the ChatGPT interface remains impractical to organize past conversations or make sense of one’s most used prompts.
I find myself storing my prompt templates in various text files, google docs, or copy-pasting from previous prompts. It’s all a big mess and a waste of time. So I needed a tool to management my prompts.
To solve this problem I’ve created Prompt Library, a web-based prompt library and composer. The tool lets you create, edit, search, and tag your prompts, insert variables and placeholders, etc. All data is stored locally for more privacy, and you can export your prompts as a JSON file. You can check out the full list of feature on the GitHub project page.
Future developments will include a way to store the history of changes made to a prompt, and compare different versions, and possibly to be able to store “prompt paths,” that is to say how to represent a graph of prompts used in sequence for more complex tasks.
