AI is already sitting next to you in your editor. The question is whether you are using it well.
There are two ways to use AI in software development
Laying down maxims in software engineering is a risky move. The professionals in this field tend to be contrarian by nature, and a firm rule just tempts them to disprove it.
With AI, that risk gets worse. Maxims about AI can become outdated fast, given the pace at which the technology evolves, sometimes before anyone even gets the chance to challenge them.
Despite that, I'll take the risk and say there are two ways to use artificial intelligence in development:
- AI is used to optimize and improve development lifecycle processes. This includes things like automatic error detection, code improvement suggestions, and other tasks that make the developer's work faster and easier.
- AI is integrated directly into the final product as a core part of its value proposition for the customer. Examples include personalized recommendation systems that improve user experience, large language models (LLMs) adapted to specific tasks, or solutions built on retrieval-augmented generation (RAG).
Corollary: the second group almost always includes everything from the first.
This article is meant to be useful to both groups of professionals. That said, we'll focus mainly on the first group, given its size and its broad relevance across software development.
"Everyone" is talking about going faster
If you scroll through social media, LinkedIn for instance, you'll find posts about how "productive" AI makes people. I could paste dozens of examples from different platforms, but to keep things clean, I'll paraphrase them.
"I can't believe it only took me 20 minutes to revolutionize how I track expenses for my farm LLC!"
"As someone who's been leading tech initiatives for years, I could have hired developers, bought enterprise software, or kept doing it manually in spreadsheets."
"Instead, I spent 20 minutes with AI and built exactly what I needed."
"This is how I (a non-technical person) vibe-coded a full functional app in four hours using Claude Code with several API integrations."
"It took me 2 hours of vibecoding using an AI tool to build..."
"It's over..."
"This new AI agent called [insert whatever name you want here] can now create full-stack products, websites, and games, turning simple ideas into full-stack apps within minutes—no experience required"
What do all these examples have in common? They're all about how quickly you can build a new app, an MVP, or a feature.
"20 minutes" seems to be the average time it takes to do something impressive with AI, followed by the magic numbers "2 hours" or "4 hours".
Everyone is faster and saving time. What used to cost X now costs a tenth of that. Everyone seems to be in a rush to generate code, as if that were the only metric that matters, even though the evidence behind it is thin.
Setting social media aside for a moment and looking at the industry, we can find reports with stronger empirical backing, like the McKinsey 2023 study. A lot has happened in the past year and a half in terms of models, code generation speed, and new features, but even then the results were already framed around "speed".
(...) Generative AI-based tools offer impressive time savings across many common developer tasks.
The study found that documentation could be 45-50% faster, coding 35-45% faster, and refactoring 20-30% faster.
So we can draw a few conclusions:
- Software developers are consistently generating code with AI (whether through simple autocomplete or multi-agent setups).
- AI lets us generate code faster.
- Generating code faster doesn't always mean that code adds value to the final product.
Don't confuse speed with velocity
In this section we'll draw an analogy between the physics concepts of speed and velocity. We're not going for scientific rigor here, just the kind of simplification that's useful for our scenario.
What is speed? Speed is "the distance something travels in a given amount of time." The problem with speed is that you can be fast in multiple directions, even moving in circles (nobody would argue that a satellite isn't moving fast).
That's fine for physics, but in the previous section we talked about speed as a productivity metric. We intuitively know that metric can't be right, and we confirm it when we realize we're generating code fast but without any clear direction.
Generating code fast brings a set of problems:
- It increases technical debt: edge cases outside the context of the original prompt get left unhandled.
- It reduces code clarity: the generated code often solves the functional problem we asked for, but it isn't clear (at least not to a human reader).
- It reduces maintainability: the previous two points hurt maintainability in obvious ways. Code that carries technical debt and is hard to understand can never be maintainable.
- It reduces testability: the problems above make it very difficult to verify that all the business scenarios can be tested properly.
The widespread use of AI for code generation has opened a debate about whether code is still relevant or whether it has simply become another abstraction layer, similar to .NET or Java intermediate language. But even granting that, there are deeper problems with this fast-feature approach:
- Do the features built actually deliver value to the customer or the product?
- Are they aligned with the business?
- Do they give the product or the customer a competitive edge?
- Do they create dependencies on unstable, poorly defined, or poorly maintained solutions (code)?
I know what you're thinking: "Darío, we had these problems before AI. There's nothing new on this list!" And you're right.
But as we established earlier, we're generating code faster and faster with AI, and we can now ship new functionality at a pace we couldn't before. That fact multiplies the probability that the risks above actually materialize.
This is where the concept of velocity comes in. What is velocity?
Velocity is the speed and direction with which something moves. In other words, being fast isn't enough. You need a direction to have actual velocity.
To close this section: it's not a good idea to generate features (code) just because it's cheap, fast, and cool. We need to generate code with AI at a controlled velocity.
How do you generate code with AI at a controlled velocity?
To explain this part of the article, let's use an analogy. Do you know what a First Person Shooter (FPS) is? Maybe not by that name, but if I mention games like Call of Duty, The Last of Us, Doom, or Duke Nukem 3D (my personal favorite), you know what I'm talking about.
Now imagine we're playing The Last of Us (if you haven't played it, do yourself a favor and play it) and we're in the following situation:
In this kind of situation, I have 2 options:
- Rush into the room shooting (and risk whatever might happen)
- Observe everything first. Since there's a door covering me on the left, I can enter slowly, keeping my back to the right wall next to the door, then observe again and decide the next move.
Sure, we've all gone with option 1 for the adrenaline rush at some point. But we know option 2 is the safer play if we actually want a chance at success.
What we described as option 2 can be generalized like this:
- Observe
- Orient
- Decide
- Act
This framework was first described in the mid-20th century by John Boyd as a decision-making model for highly dynamic situations, originally designed for aerial combat between fighter jets (dogfighting). It's called the OODA loop, after the initials of each stage.
Here's how this mental model maps perfectly onto the game scenario we described.
And you can see how the loop repeats with every move as we progress through the game.
Now, how does this answer the question of how to generate code with AI at a controlled velocity?
From the first section of this article, we can conclude that we are, in fact, generating code very fast with AI. From the second section, we need direction so that speed translates into actual velocity.
So the way to generate code with AI at a controlled velocity is to use the OODA Loop as part of your workflow.
Does this work in practice? How?
tl;dr: yes, it works.
Ever since I started using Claude Code as a code generation tool, I felt a certain discomfort. It wasn't with the tool itself (which I considered superior from the start, both in terms of interface and results), but with the process I was following to develop new features.
At first, I tried using very detailed prompts, providing enough context to eliminate any doubt or ambiguity. But something still felt off. Then I tried giving precise instructions through the CLAUDE.md file. Combining that with detailed prompts produced initially promising results. Over time, though, as I refined the code, I lost control and direction, and ended up generating features very different from what I'd originally imagined.
That's when I realized I needed to move through micro-iterations: short but precise steps in the right direction. I experimented with more specific, focused prompts and started getting better results. I began calling this process of making small iterative improvements, each kicked off by a prompt, "AI multi-turn feature generation." The name came from an expression Andrew Chan used in his article "Vibecoding a high performance system" to describe part of his vibe-coding process.
Then I incorporated the OODA loop mental model to make sure each small improvement moved in the right direction. Finally, I made one more change to my workflow using a few Claude Code hooks: after each code generation cycle, a commit was automatically created with the prompt used as the description. That gave me, at last, the comfort and control I needed in my development process.
Conclusion
In today's software development context, AI has become an essential tool that lets developers generate code at an unprecedented pace. But it's critical not to confuse speed with effective velocity. By applying the OODA cycle (Observe, Orient, Decide, Act), developers can make sure their speed translates into meaningful, directed progress. This approach helps avoid common problems like technical debt and unclear code, and it ensures the features you build actually deliver real value to the final product.
Personally, I've found that this approach has significantly improved my development process when using AI-based code generation tools. The multi-turn feature generation methodology, combined with the OODA model, has given my projects a clear structure to move forward. This framework is grounded in solid, proven principles, like "divide and conquer" and continuous improvement cycles, which gives me confidence in its effectiveness. That said, I'm open to feedback and suggestions from other professionals who want to help refine it further.
Finally, I'd encourage every developer not to settle for processes that feel uncomfortable or frustrating. Just as I turned my initial discomfort with AI tools into a more efficient and satisfying process, you should look for proactive ways to optimize your workflow. The key is adapting the tools and methodologies available to fit your specific needs and improve your daily productivity.
