Preface
Because an agent, by its nature, is not deterministic, we need to improve our approach if we want to achieve a certain level of determinism.
The usual workflow should be inverted. Instead of sitting down to code at the same time developing the design, take time to think about the design implementation, draft specifications, define constraints and draw diagrams.
C4 Model is currently one of the most effective approaches for describing complex software systems. Don't forget the old good ones: ER diagrams, sequence diagrams, etc.
Once the diagram draft is ready (pen and paper are good enough), take a screenshot and ask the agent to generate an *.mmd file (mermaidjs format, highly recommended) or any other format you prefer. From that moment there should be a rule for the agent to use that diagram as reference for any request - migration, refactor, implementation - related to the product you're building.
Skills and Contexts/Tasks specs are expressive BDD documents that, once completed, should be summarized by the agent in a shared repository so that the project context is available whenever it is needed, reducing the possibility of a hallucinations.
All of this makes the design and implementation process more organic and deterministic in its behavior.
When we have worked out some aspect of software design, we should not let incorrect comparisons with [... let's say other disciplines ...] keep us from correctly documenting our work in software design. (Jack W. Reeves)
Current state
The now infamous phrase "AI agents are cheaper Junior Devs" reflects an evolution in the wrong direction of what was originally intended. When it was first said years ago by a group of savvy Software Engineers, the intention was to explain that, like a Junior developer, AI agents tend to follow orders. Even if they have a lot of data/information (given that is mostly probabilistic information) there will still be errors, duplication and many missing parts across different scenarios.
The original intent was to describe the outcome of the interaction, not to replace the idea or role of a Junior developer. However, what has happened in the last year is the anthropomorphization of agents. There are many posts, opinions and reflections on this topic, so I will not delve into it. What I would like to explore instead is a different path, a different perspective around the use of AI agents in software engineering.
Let's start with an old article by Jack W. Reeves that I've always found insightful: What is Software Design? (1992). I recommend reading the three essays he wrote on this topic.
Reeves explored the rise, at that time, of OO programming techniques in the C++ world and used those ideas to support his main argument:
Programming is not about building software, programming is about designing software (Jack W. Reeves)
He support his thesis saying
C++ has become popular [1992] because it makes it easier to design software and program at the same time (Jack W. Reeves)
He argues "we're not software engineers because we do not realize what a software design really is". While I mostly agree with this statement, I'd say the industry has grown and matured enough that today the majority of software engineers understand what software design is - even if many of us don't consciously realize it while we're doing it.
Reeves also wrote:
The final goal of any engineering activity is the same type of documentation. When a design effort is complete, the design documentation is turned over to the manufacturing team ... In fact they can proceed to build a lots of the product, all without any further intervention of the designers (Jack W. Reeves)
These designs are the blueprints that derive from prototypes, test models and structural analysis.
... the final source code is the real software design ... one consequence [of this] is the fact that software is cheap to build. If source code is a software design, then actually building software is done by compilers and linkers (Jack W. Reeves)
As software engineers we design and test models (PoC, TDD, BDD), implement scale models (prototypes) and perform structural analysis (benchmarks, performance analysis). All of this work is done to refine the design through refactoring and implementing the code.
And just like in "hardware engineering", the design process - writing source code, prototyping solutions, documenting requirements and decisions - is error prone.
The general consensus is that when real engineers get through with a design, no matter how complex, they are pretty sure it will work [...] In short, the designers do everything they could think of to make sure the design is good design before it is built. (Jack W. Reeves)
I'd say this is a substantial difference for software engineers. We use the "manufacturing team" (compilers, linkers, etc) to "optimize" the software design; because of its "almost free" nature the build phase often happens in parallel with the design phase (the source code). The final build is what we call deployment to production.
Designing software is an exercise in managing complexity [...] is very similar to system design. (Jack W. Reeves)
This was said in 1992, when OOP was the hype and tools such as UML and Structure Charts were the de facto way to specify requirements and design implementations.
We must keep in mind, however, that these tools and notations are not a software design. Eventually we have to create the real software design and it will be in some programming language. (Jack W. reeves)
Because of this, he concluded:
It's probably better to let the original designers write the original code, rather than have someone else translate a language independent design later. (Jack W. Reeves)
Enter AI Agents
Let's review briefly the history around the "AI Agents" hype, at least as I experienced it.
In 2021 Github Copilot was released with plugins for multiple IDEs and environments. I used Copilot mostly as an "advanced" intellisense. Thanks to its «limited» ability to infer what was happening in the file being edited (ideally no more that 200 loc because of context limitations), it was able to suggest lines of code or even blocks of code good enough to have to start a boilerplate or remind me of possible ways to define, for example, a function.
It was also possible - and still is - to request specific code or hints through comments.
In 2022 OpenAI released ChatGPT to the general public, and it permanently changed many aspects of the software industry, both within the industry itself and how it is perceived by the outside world. Software engineering lost part of its mystique. Non-engineers started to the work as less complex because now a prompt could produce multiple answers instantly - and often with a sycophantic tone that I personally dislike.
In my own workflow, ChatGPT became the quick fixer for "simple" questions. What used to take a five-minute search could now be reduced to three minutes, often with more context.
ChatGPT 5, I'm sure, placed a spotlight on the anthropomorphization we, as humans, were projecting onto what is fundamentally a high-capacity probabilistic model.
At that stage ChatGPT could already be used for larger questions thanks to its reasoning skills. However, getting the most out of it required users to learn and understand a new set of constraints and practices: assigning roles, providing context, structuring prompts.
This stage was interesting because, when done properly, it forced users to think differently about problems. Designing prompts and scenarios to improve the feedback loop could expand creative and cognitive limits.
By the end of 2023 Cursor appeared. I didn't use it extensively, mostly because my vim+copilot setup was already sufficient for what I was doing, but it was clear that something important had happened: an Agent could now operate at the project filesystem level.
I had to wait until 2025, when Warp 2.0 was released with a complete restructuring. The focus shifted away from an "advanced" Terminal App with IDE-like utilities and toward becoming an ADE - Agentic Development Environment
Being a terminal with Agentic functionality built into the system has an advantage: the power of tools like Cursor combined with the ability to interact with the whole system - OS filesystem and its functionality.
Considering that the agent concept (including tools and extensions such as MCP) is designed to work through CLI, it makes a lot of sense for an ADE to be CLI based. (A great explanation here)
Thesis
"Vibe coding" became the buzzword of 2025 and 2026, but because of the rapid evolution of the environment:
The questions of whether OO techniques [2026: AI Agents] are just hype have been replaced by questions of how to get the benefits with the least amount of pain. (Jack W. Reeves)We have now <MCPs> <CONTEXTS> <SKILLS> <RULES> <ROLES> <ADKs>, and many other mechanisms designed to constrain and focus the capabilities of AI Agents. All of this is built on top of other tools and concepts developed to improve what we as software engineers already do.
Agents are like Junior developers but cheaper and faster is not one of those useful concepts.The Junior Dev Fallacy
When this comparison was first mentioned, the intention was to provide a reference point about decisions-making, accountability, and experience between a Senior and a Junior developer - not between a Junior developer and a probabilistic tool.
An Agent has access to a massive amount of information and can process it extremely fast to infer possible outcomes. But it lacks knowledge in the human sense. It's a probabilistic model.
If you have to remind a Junior developer more than fifteen times about the project standard for styling UI components - for example, how styled-components should be declared or where Tailwind classes should live - you would consider letting that person go. In reality, most juniors learn that after three or five repetitions.
An Agent, however, can make the same mistake months after the original implementation, even when rules and constraints are explicitly documented. And when corrected, it will often respond with something like "You're absolutely right, this is not the standard way to implement components in this project".
In a short and specific rant: this situation reminds me of what happened with "agile" when CEOs and PMs with non-technical background adopted it as a buzzword for marketing purposes.
The evolution thesis
Programming and the build/test cycle are central to the process of engineering software.We need to manage them as such ... we can improve this process, but we can not escape it (Jack W. Reeves)
I'd say many reticent people expect to keep coding the way engineering has always been done. But event that assumption is historically inaccurate. Many probably do not remember when programming meant punching holes in punch cards, and I'm sure those people screamed when someone said "Hey, this is called fortran".
On the other side, some people are excessively optimistic and expect some sci-fi AI like Ironman's J.A.R.V.I.S.
I've been long convinced and I've been saying:
Software architecture must be a mindset for any software engineer
Software architect is a role that you could obtain, but most importantly software architecture is a way of thinking you should have, and it is crucial for the new programming language era.
Experience can lead us in the right direction, this is craft ... Then we must take what we started with and make it better through a controlled process of refinement, this is engineering. (Jack W. Reeves)
Just like, let's call them for the sake of the argument, "traditional" languages have a set of rules, constraints, syntax and are populated with libraries and frameworks, all that supported by design patterns, best practices and whatnot, the "natural" language turned into a new programming language has evolving rules, syntax, libraries (i.e. SKILLS, RULES, MCPs) and first appearances of what, I'd like to call proto-frameworks (what the industry now refers to as ADKs).
All of that is still evolving but the release times are so narrow that I'm sure we'll be watching so many advances in this field in no-time.
A Design Paradigm
The goal of any engineering design project is the production of some documentation. Obviously, the actual design documents [i.e. source code] are the most important, but they are not the only ones that must be produced. (Jack W. Reeves)
The workflow we used as guidebook is the generalization of auxiliary documentation that represents requirements acceptance criteria, architectural decisions, but those documents eventually became outdated and sometimes not fully updated they collect dust or occupy disk space and are used only to brag about them, to present during audits or as a justification to get funding.
Undoubtedly, keeping such documentation up to date is difficult. This is another argument for the need for more expressive programming languages. (Jack W. Reeves)
Natural language satisfies many of those requirements. But adopting it as part of the programming paradigm also means adapting our knowledge and practices.
Agents can generate code faster and, in many cases, produce more performant solutions. Instead of focusing only on what should be implemented, we can focus more on how a feature should behave. Instead of writing the same reduce function for the hundredth time, we can focus on preventing duplicate logic across modules.
Coding skills and engineering knowledge remain essential - arguably the most important skill - but communication and architectural thinking are becoming increasingly relevant.
Afterword
The vibe coding hype is a natural phase of any new technology. We saw similar cycles with Agile, with OOP, and with tools such as Dreamweaver or Flash.
Every time a technology simplifies complex tasks, the general public becomes interested in exploring it - often with the hope of achieving results without fully understanding the underlying complexity.
Modern LLMs and agents have narrowed the gap even further. If natural language is becoming the next programming language, it is only natural that everyone wants to play with the new tool.
The source code may be the master design document, but it is seldom the only necessary. (Jack W. Reeves)