I'm preparing my morning matcha as I sit down in front of my laptop. The AI has been working all night, running in a continuous Ralph loop coding non-stop through a long list of tasks.
The features have been decided automatically, inferring from an AI what users really need.
Bugs are triaged automatically based on user submissions, at least for those who refused to let us record their screen.
Whenever a user asks for a new feature for the application, there's no reason to say no.
There are 42 pull requests. A successful night of coding, the stakeholders are going to be thrilled about our development efforts.
Each pull request comes with a descriptive title and a technical description long enough that nobody reads them anymore. We've decided to add a section to summarize the descriptions. Using AI.
As I start reading through the code, there are just too many lines to review by hand.
I open a new terminal tab, trying to cram it alongside the other 10 open sessions for this project, and I type:
ai-agent --dangerously-skip-permissions
I have 42 pending Pull requests to review.
Go one by one, review that the code follows best practices, good architecture patterns and has no missing tests.
Add comments and suggestions where needed.Best practices? Good architecture? I don't even know what code like that is supposed to look like —I guess the AI agent knows better.
Great. Now, while I wait for it to review, I can check the other 231 pull requests for the other 5 different projects that were being coded while I slept.
Management is starting to measure performance based on the number of tokens we consume. I'll surely get a raise.
I take a sip of my thoroughly and mindfully prepared matcha —I got distracted— it is now cold.
#Are we in the future yet?
Does this sound familiar?
Is this what we are striving for as Software Architects?
Not me, not out of spite of this new era —I embrace change— but because this approach is never going to work.
Wait, did I just see César really use an em dash (—) for the third time? Does this mean this newsletter is written by AI? No worries, I really like what they look like, and I'm trying to incorporate them in my writing whenever they make sense. I know a lot of AI models use em dashes, but hey, it's still me. I have an AI policy, and I promise you that this newsletter is an AI-safe space. Read more about my AI policy.
Once the AI agents have increased the output beyond what we as humans can review in a given project, humans are no longer in control of that project.
This I've decided to coin: laigacy code.
#What is laigacy code?
Laigacy code, simply put, is when a project has adopted full agentic programming in a way that is not sustainable. Where the amount of code written (without guardrails, a solid foundation, or AI skills) is so vast, that there's no human way to review it.
This effectively means, that we will need to use AI to review what AI has written, losing complete control over the project and effectively killing it faster than we can fix it.
AI accelerates development. If we have a solid foundation it will accelerate innovation and competitiveness, if we don't, it will only accelerate the death of the product.
#What is the fix for laigacy code?
The fix for laigacy code is not simple. We are still figuring it out. However, we can look back at the past to learn from old lessons.
In pre-AI projects when you found a legacy project you would first try to understand the system, document it, create a test harness around existing parts so that when you refactored later, you could validate that the project was working as intended.
Although we can draw some parallelism, there's a big difference. In laigacy projects you'd find excessive documentation, an unparalleled amount of tests and somehow still feel like you don't understand the project. What's even worse, once you start figuring it out, a bunch of overnight AI generated PRs appear that throw away all new assumptions!
What's underneath all of this is... Lack of confidence.
With AI, how do we know if changes are intentional... or not?
So, the fix for laigacy code can be no other than being intentional.
#How can we be more intentional?
We can be more intentional by reducing the usage of AI when communicating. For example when describing PRs, taking some time to explain the reasoning (with typos included if needd!) is a great way to be more intentional.
“”If I don't put effort in communicating, why the consumer should put effort in consuming the content?
Add high-quality skills, which I think are a great way to keep living documentation in the project.
Defining a human-validated architecture, with use cases, repository pattern, separating domain logic, applying layers, etc.
Actually guiding the AI, through plan mode, revisiting the plan if needed and reviewing the generated code. Become an active actor, rather than a passive one.
Syncing with the team on this new approach of using AI, creating conventions on how to use it in a way that is sustainable yet effective.
#Closing thoughts
It's easy to fall in the trap of not caring anymore. Of letting things slide. Of being less intentional. This is not the way. AI is a REVOLUTION, we, as with everything in life, need to be mindful about our craft, the rest will fall in place.
P.S: I'm honored to share with you that I'm giving a talk at an event that a couple of years ago, I wouldn't have dreamed of speaking at. JSNation. Not only that, but also React Summit. And we are doing a collaboration, perhaps you are interested in attending the event in person or online. Either way I have a 15% discount code for both. JSNationOpen in a new tab. React SummitOpen in a new tab. That's it, thank you!
P.S 2: I've written most of this issue on a bus on my way to Málaga city, Spain.