Coding With AI Agents in the Background: Our Real Workflow

The StartingUp Summer continues. Taking a step back on a dense year also means opening the workshop doors. After closing the drawer of questions AI made obsolete, we're telling you about the deepest thing it changed for us: coding with AI agents running in the background has become our daily routine, described here without filter.

You've surely come across the promise: developers replaced by a chatbot, entire pieces of software written on their own overnight. What we live at the agency is both less spectacular and far more interesting. Yes, a large share of our code is now written with AI agents: instances of artificial intelligence that receive a precise mission, have access to real tools (read the code, run commands, launch the tests) and work alone for long minutes, often in the background, while we do something else. No, nobody has been replaced.

This article is a field report, not a sales pitch: it describes how this actually works, wins and struggles included. No lab demos here: only situations we lived through this year on client projects.

Coding with AI agents comes down to three steps: specify a scoped mission, hand it to an agent that works in the background with real tools, then verify everything that comes back (tests, review, real-world trials) before anything ever ships to production. The rest of this article breaks down each part of that workflow.

The image of a developer dictating code to an assistant is wrong. The right image is that of a conductor: they no longer play every note themselves, but they choose the score, hand out the parts, listen to everything being played, and stop dead anything that sounds off. Our typical day consists of breaking work down into parallel missions, handing them to agents, then reviewing and deciding on what comes back.

A real example. On an e-commerce platform, we shipped a complete video-search feature in a single session: search terms customized by language, manual addition by URL, result deduplication. Several agents worked in parallel, each on their own scope. By the end of the session: more than 380 automated tests passing and zero type errors. What kept the human busy during that time wasn't typing code, but deciding: which architecture, what limits, what ships to production and what waits.

Different register, same logic: for a specialty shop, a roughly 3,000-word in-depth article went through a full pipeline, competitive research, drafting, then three SEO-optimization agents launched in parallel and about fifteen fixes applied after review. Yet the most decisive part wasn't automatable at all: the editorial angle missing from the search results (writing from the point of view of the subject-matter expert, not the vendor) is a choice, not a computation. And for the sake of honesty, a struggle: that day, the background agents couldn't save their own files, and their output had to be recovered by hand. "Launch and forget" is a goal, not yet a given.

Data migrations, test suites to write, mechanical rewrites, dependency updates: everything that's long, well-scoped and verifiable goes to a background task. The agent moves forward, we keep working on everything else, and we take back the wheel at review time. It's the same spirit that led us to connect WordPress to Claude via MCP: giving agents tooled, scoped and revocable access to our systems, rather than copy-pasting bits of code into a chat window.

On a PrestaShop e-commerce site, an ad-tracking module stubbornly refused to run: saved in the database, active, correctly hooked in... but never actually called during web requests. Two hours of methodical investigation, hypothesis after hypothesis, to discover that an install inserted manually into the database isn't a complete install in the platform's eyes. The agent tests and checks far faster than we do; the human keeps the thread, brings the context (the redirect scenario at fault was impossible to reproduce locally), and ultimately settles on a belt-and-suspenders solution.

These sessions also serve as a reminder that the environment lies as much as the code does. A classic trap: a library installed inside a Docker container but never declared in the project's dependencies. Everything works, until the day the container gets rebuilt: blank page. Faced with this kind of bug, the agent is just as blind as we are; what saves the day is the method (reproduce, isolate, prove), not the model's power.

Nothing an agent produces enters a project without review. Our most profitable practice: a double review, first for compliance (does the work match exactly what was specified?), then for quality (is the code sound, tested, defensive?), often handled by other agents before a human makes the final call. This mechanism recently caught, on a WordPress build, a wrong setting repeated across seven configuration files: entire sections of the admin interface would have been invisible, silently, until the first real use. The tests were green. Without review, the bug would have shipped to production.

No agent, at our place, can deploy, delete data or publish anything without explicit human approval. These rules are written into our tools' configuration, not into some vague code of conduct, and they bite regularly: the agent stops, explains what it wants to do, and waits. The friction is real, and it's healthy. The day an overly broad sync swept away code it shouldn't have touched, everything was restored within minutes, precisely because nothing ever bypasses version control or human approval.

• Boilerplate and repetitive mechanics. Project scaffolding, configuration, infrastructure code: consistent quality, disconcerting speed.
• Migrations and mass transformations. Apply the same change across dozens of files or pieces of content, without fatigue and without missing a single one.
• Tests. Writing serious test coverage is no longer the chore you keep putting off: entire suites appear in a few hours and catch real bugs.
• Bug investigation. Forming hypotheses, checking them one by one, combing through error logs without losing steam: the agent excels at the investigation, as long as a human keeps it on course.

• Long-running business context. An agent starts each session almost blank. Everything that makes up a project's history (why that choice two years ago, what this client absolutely doesn't want) has to be documented or repeated. Documentation has become critical infrastructure, more than a courtesy.
• Taste. On micro-decisions of design, wording, user experience, the agent offers what's correct, rarely what's right. Art direction and attention to detail remain human.
• Review debt. The sneakiest one: generated code that hasn't been reviewed is debt. Production speed has outpaced review speed, and accepting without reviewing amounts to piling up code that nobody on the team truly understands.

This last point deserves to be said plainly to decision-makers: the new technical debt doesn't show up in the timelines, it shows up six months later, when code that no one has ever read needs to evolve. A vendor who ships fast thanks to AI without a review process isn't saving you time, they're borrowing it from you.

We're sometimes asked whether teams need training in "prompt engineering." Our answer, after a year of heavy use: not really. Talking to models is learned in a few days. The two skills gaining value are older and more demanding: specifying (precisely describing what you expect, the constraints, the criteria that will let you say it's done) and verifying (proving that it works, through tests, reviews and real-world trials, rather than taking it on faith).

That might be the best news in this shift: it rewards neither jargon nor trendy tools, but rigor. A rigorous developer backed by agents moves much faster than before; so does a careless one, and that's exactly the problem. If someone promises you miracles thanks to AI, one question sorts it out: ask how the code gets reviewed.