Over the last few months, I’ve dedicated significant time to experimenting with AI-assisted development agents. I’ve tested various tools, models, planning approaches, and many ways to automate software engineering tasks.
Curiously, the conclusion I’ve reached has less to do with the models themselves and more with the software surrounding them. It’s still early to know if this direction will become the standard; for now, it’s the one that seems most promising to me.
From the Illusion of Artificial Brains to the Reality of Code
A year ago, between tests on my GPU and experiments with OpenAI and Anthropic models, I encountered a reality different from the hype: the technology was still incomplete. I felt that frontier models were missing something essential. I found myself thinking of science fiction novels, where LLMs seemed to be just the prediction engine of an artificial brain that hadn’t finished building itself yet. It’s a metaphor that helps me frame the problem: although we now know that real reasoning emerges from their architecture, we still lack the rest of the “organism” for them to be truly autonomous.
At that moment, I decided to stop trying to decipher the fundamentals of LLMs. I recognized that, without a deep foundation in deep learning or machine learning, the effort to replicate existing technologies was not the most efficient path. My goal wasn’t to reinvent the wheel in an alien field, but to find ways to apply it effectively.
The Probability Trap
Back then, I was using VSCode with different plugins like Continue or Aider. Then came the IDEs with built-in stacks promising another revolution, like Windsurf or Cursor. They helped, but it was more of the same: a lot of hype and very little substance. Something was still missing, and although people were starting to talk about AI agents, the concept was very nascent; they were frameworks upon frameworks replicating the structure of an industry in flux. The path was clear, but LLMs needed a control layer to tame that raw reasoning capability.
A year later, in mid-2026, I started testing Codex and Opencode (tools that act as a “harness” for programming). They are a significant step toward making models more deterministic, even though they still depend on the underlying model. Through state machines and processes, they manage to channel the probabilistic nature of LLMs toward specific areas and concrete tasks. It’s clear there’s still a long way to go, but this approach offers some hope.
For these processes to be sustainable, we need a memory architecture. We could think of vector databases as an associative memory module (which the AI queries on demand), while the LLM’s context is its immediate working memory. On the other hand, projects like Andrej Karpathy’s ‘Second Brain’, along with Obsidian, allow us to build a long-term memory curated by the human: a navigable knowledge structure that allows us to consciously inspect and connect ideas.
With current frontier models and a well-structured agent strategy, the results in code generation are very promising, although human supervision remains key. The most powerful models are already capable of proposing architectures, detecting structural flaws, and synthesizing complex documentation.
Now, the feeling is very different.
But there is an important difference between being good at solving a bounded task and being good at executing an open process. That’s where the problems begin.
A model might decide to rewrite an entire implementation because it considers it a better solution. It can lose context. It can change strategy mid-development. It can introduce changes outside the original scope. Not because it’s a bad model, but because that is precisely the nature of a probabilistic system. When given too much freedom, it tends to drift.
The Real Challenge
From my point of view, I am increasingly convinced that the most interesting problem pending resolution isn’t getting a smarter model. The interesting problem is building a system that remains predictable even when the core component isn’t.
This implies a shift in focus. Instead of investing time in writing increasingly complex prompts, perhaps we should invest it in designing better workflows. Workflows where the state is explicit, transitions are deterministic, contracts are written, events are observable, and any execution can be recovered after a failure.
In this model, AI stops being the center of the system and becomes just one more actor within a well-defined process. It’s not that agents don’t work; it’s that they need to be orchestrated by a workflow. The agent is the actor; the workflow is the script.
To make this clearer, let’s look at a concrete example. In my last experimental project, I designed a workflow with three agents: one writes tests, another implements the code, and a third reviews the result. The state is saved in JSON files, and each step executes only if the previous one passes. This allowed me to reduce errors and, above all, gave me the peace of mind that I could interrupt and resume the process without losing the thread. It’s not magic; it’s engineering.
An Idea I Find Especially Interesting
I came across a phrase that perfectly summarizes this approach:
Write the loop, not the prompt.
It’s a simple idea, but it completely changes the perspective. Value stops being about a specific conversation with the model. It moves to the process that can be executed over and over again with consistent results. That phrase changed my way of thinking about system design with AI.
A Curious Consequence
It’s incredible, but for now, the better the models become, the less intelligence the workflow should contain. Important decisions shouldn’t live in the model. They should live in the state machine, in the contracts, in the tests, and in the rules of the process. In other words: the workflow should be deterministic and predictable; the intelligence, only what is necessary for the task.
That said, the power of the model is still the engine; without a model capable of processing language with precision, the most perfect workflow in the world would produce nothing of value.
The model should dedicate itself solely to what it is truly good at: identifying patterns, programming, and reviewing. Tasks that are aligned with its primary strength: natural language processing (NLP). Everything else belongs to the system.
Of course, this relationship could change if future models are qualitatively different. For now, it works, but we shouldn’t dogmatize it.
What I’m Thinking About Now
Lately, I’ve been particularly interested in topics like deterministic workflows for AI-assisted development, separation of concerns between agents, persistent state and failure recovery, verifiable contracts between development phases, observability of long processes, and event-based automation instead of conversations.
I believe we are still at the beginning of this way of working, and over the next few years, we will see more innovation in the engineering surrounding the models than in the models themselves. And, personally, that part seems even more interesting to me.
My prediction is that by 2027, we will see the first development frameworks where the workflow is the product, not the model. And then, the question will stop being “What model do you use?” and turn into “How is your process designed?”