Architects Rather Than Spectators: Our Approach to AI-Assisted Development
Since the arrival of Large Language Models (LLMs) and code-generation tools, software development has been undergoing a deep transformation.
Sébastien Boeyen
Co-founder
One trend in particular has taken center stage: "vibe coding." Popularized by highly agentic platforms, this approach promises to build software through intention alone. You give a high-level directive, and the AI reads, rewrites, and ships entire sections of the application on its own.
Vibe coding has its place. For throwaway prototypes, weekend experiments, or proving out an idea before committing to it, letting an agent run freely is fast and often good enough — the cost of a mistake is close to zero, because the code was never meant to last.
The calculus changes completely when the code is going into production and the work is billed to a client. There, the things that make vibe coding fun — speed, low friction, letting the agent decide — become liabilities. A hallucinated dependency or a silently broken component isn't a minor inconvenience; it's a regression someone pays to find and fix later, often us. So rather than choosing a camp, we work along a spectrum that runs from surgical coding to the strategic use of planning before execution. The right point on that spectrum depends entirely on the task.
1. Surgical Coding
At the opposite end from blind vibe coding sits surgical coding. This is our default for well-defined tasks: performance optimizations, targeted bug fixes, anything where we already understand the problem.
Here our developers act as architects. Instead of handing the AI unrestricted access to the entire codebase, we point it at specific files — or even individual functions — and constrain it to the change at hand.
The benefits are concrete. Take a typical scenario: an agent running in free-execution mode is asked to adjust a date-formatting helper. It "helpfully" refactors a shared utility that three other modules depend on, and a reporting export breaks in a part of the application no one had touched in weeks. The fix can take an afternoon just to trace. Working surgically — scoping the change to the function that actually needs it — that class of problem simply doesn't occur. The model makes the modification you asked for and nothing else.
Constraining the context also keeps token consumption proportional to the task: the AI isn't re-reading thousands of irrelevant lines, so responses are faster and costs stay predictable.
2. Matching the AI to the Complexity of the Problem
Not all work is tweaking an isolated function. Building a new feature or undertaking a larger refactor means deliberately widening the context. Our strength is in refusing dogma: we adjust how much autonomy the AI gets based on how well-defined the task is.
The more ambiguous the goal, the more we shift from a "micro" mode — the developer dictates the change line by line — to a "macro" mode, where the AI helps shape the design and we steer. It's the same tool dialed to a different setting, not a different philosophy.
3. Planning Before Code: Challenging the Architecture, Not Enduring It
So what happens when a request is genuinely broad or under-specified?
Most modern AI coding tools offer a planning mode: instead of immediately writing code, the agent first produces a plan. We use it almost systematically for this kind of work. Rather than letting an agent rewrite dozens of files in the hope of stumbling onto a solution — which burns through budget and introduces real technical risk — we force the thinking to happen up front.
In planning mode the agent doesn't generate executable code. It behaves like a tech lead: it analyzes the broader context, drafts a roadmap (which files to touch, the proposed architecture, the dependencies involved), and then we challenge its choices.
This human review step lets us debate the proposed architecture before a single line is modified. If the plan overlooks a security requirement or reaches for needlessly complex logic, we correct course while it's still cheap to do so — on paper rather than in a tangle of half-written code.
4. Spending in the Right Place
There's an economic dimension to this, and it’s becoming increasingly central as the market shifts toward per-token pricing for all major AI coding systems. In this model, surgical coding is an objective cost-saver: by constraining the context the AI reads, we directly reduce token consumption.
However, honest accounting matters here. While surgical coding saves tokens, planning and human review consume developer time, which is generally a higher-value investment. We’re not claiming our method is always cheaper to run minute-to-minute. We’re claiming it spends effort where it pays off. The expensive part of software is rarely the first draft — it's the corrections, the regressions, and the maintenance that follow. An agent left unsupervised can produce code that works in the demo and quietly accrues debt you discover three months later. By investing developer judgment up front, we trade a small, visible cost now for a large, hidden one we never incur. That's the real saving, and it's the one that protects a client's budget over the life of a project.
Conclusion: Human Judgment Stays in the Loop
Vibe coding makes for impressive social-media demos, and for the right throwaway use it's a legitimate tool. But what keeps production systems healthy is judgment about when to let the AI lead and when to hold it on a short leash.
By combining surgical coding for everyday work with structured planning for areas of uncertainty, we get the speed of AI without surrendering control of the result. We stay responsible for the code we ship, keep costs honest and predictable, and build foundations meant to last.