The Engineer as Architect

A year ago, building a software feature meant writing it manually, with each line going through equally manual feedback. AI has changed that sequence drastically. Engineers now have to work out how to direct machines that do much of the typing, and perhaps more importantly, how to do it without losing control of the result.

Francesco Coacci, a full stack software engineer at Monk, the New York company building agents for accounts receivable, has spent the past year reworking how he builds. He now directs several features at once, steering agents that handle the typing while he reviews and verifies their output, a change that has shifted the engineering work from writing each line to designing the system and the constraints that govern it. His methods offer builders a grounded account of how an agent-first workflow holds up in production and where it breaks.

From Sequential Builds to Parallel Agents

Before LLMs spread through engineering teams, Coacci built software linearly. He'd take a feature request, strip it down to its basic functional requirements, and implement them one feature at a time. The loop was familiar to most engineers: start work on a single feature, ship it, test it in a real environment, then refine it before moving to the next.

His first attempts to fold AI into that process treated it as something running on the side. "Before, I used to think in terms of getting something done with AI on the side, and then the final version made with that system wouldn't really work, or it'd be slow, and I'd just keep changing stuff," says Coacci. This way of working served only as an assistant, and the rework piled up. What followed was essentially a reinvention of his old model.

Coacci frames the agentic shift as a change in both how the work is done and what it produces, not a marginal speed bump. The core of that change is parallelism. "What I do right now is have five windows open at the same time, and I follow my agents building five different features at once, with my instructions," Coacci explains. Several agents now run at the same time, advancing features simultaneously rather than in sequence, each guided by the direction he sets.

His attention has moved from writing code to steering the agents and reviewing what they produce, and the rest of the team at Monk has reoriented around shipping faster the same way.

Constraints Over Code

The biggest risk in an agent-first workflow is losing control of what the agent decides. Left without limits, agents drift and make unsupervised choices, a danger Coacci has seen firsthand. "If you don't set specific constraints and rules, the agent may go rogue and come up with full-fledged decisions by itself, which is really dangerous," he explains. As a result, he treats precise instruction and tight constraints as the core of the job.

The more features Coacci works through at once, the more the quality of his up-front instructions determines the outcome. Clear intent at the start, in his account, is what separates a fast, clean ship from an endless iteration loop. When he knows exactly what he's changing, he caps the agent at two or three iterations before shipping. Over-iterating, he argues, usually signals unclear intent instead of diligence; the fix is to decide what's being built before the agent begins working, not to keep correcting it afterward.

That clarity also protects reliability, which must be kept intact with the increase of outputs that AI offers. The discipline is what lets him move quickly without the product breaking. The main idea Coacci presents to builders is that constraint and instruction design has become a primary engineering skill in its own right, not an afterthought to the real work of writing code.

In-Depth Knowledge of How the System Works as Essential

As agents handle more of the typing, the engineer's value shifts toward direction. "The work is closer to software architecture now. I have to know exactly how the system behaves before I can review what the agents write against it," Coacci explains. He reviews what the agents produce rather than babysitting each iteration, and that review only works because he understands the system well enough to verify what they generate.

Counterintuitively, core computer science knowledge has become more useful to him, not less. He credits the theory-heavy education he received in Italy, where he earned his bachelor's degree before completing a master's at NYU in computing, entrepreneurship and innovation. His time studying in Italy allowed him to better understand how a computer works, while the American degree emphasized application, and he now values having had both.

Algorithms, system architecture, and data modeling feed directly into the product and technical decisions he makes, which in his experience often come down to establishing and setting specific concepts that help him pick the right direction. The takeaway Francesco Coacci offers builders is straightforward: don't skip the fundamentals just because a model can generate the code.