Two engineers used Codex to bring a system to pilot in two months instead of a five-person team

The custom project was needed yesterday, nobody had spare capacity, and turning it down felt like a waste. Two engineers decided to test whether they could handle such a project on their own by having agents write all the code while they retained responsibility for scoping, oversight, and testing. Two months later, they had a working pilot. Here is what worked in the process and where the authors themselves acknowledge weaknesses.

What they built and how they organized the work

The task was to create a business process automation system featuring a local LLM, MCP integrations, branching logic, and a role-based model. Building all of that from scratch would have been too ambitious, so they started with an open-source project that already had a workflow editor and basic execution capabilities. However, it depended on the developers' cloud, so the system had to be decoupled from it, and its local-model support had to be reworked.

The key technique was conserving context. If you simply tell an agent to "build the integration," it will fill its context window, start compressing its history, lose details, and repeatedly reread files until the token budget is exhausted. Instead, the agent is first asked to break the task into small steps, after which a human removes anything unnecessary: agents tend to play it safe and add useless checks. The finished plan becomes the specification.

From there, everything lives in files. AGENTS.md is loaded in every session, so it contains only links to mini-docs covering the architecture, server, and API. A separate progress file records where work stopped in the plan. The agent takes the next item, reads only the necessary documents, commits its work, and updates the progress file. As a bonus, when one engineer runs out of tokens, the other points their agent to the same folder, and work resumes from the correct place.

The level of supervision depends on the deadline. The engineers can review the work after every sub-item or let the agent run overnight until it deploys to the development environment. In the worst case, they roll the changes back.

Where it hurts

The authors do not delegate testing. Playwright through MCP consumes tokens, but the bigger issue is that the agent checks functionality. A button may work but provide no visual feedback, or an element may have shifted out of place, and the agent might not notice. A human spots such problems immediately.

The cost of agentic development:

• You lose knowledge of the project. The system's major blocks remain understandable, but the internals of a particular module no longer are, making task descriptions less precise.
• Code quality has not been validated. Code review and the security audit were postponed to maintain momentum, while extensive testing still lies ahead.
• Timelines are unpredictable. The agent decided to rebuild a Docker image after every change to preserve a rollback point, turning a small fix that should have taken 30 minutes into a three-hour job.
• The agent fills in the blanks. Instead of "create a user as an administrator," it implemented an email invitation.
• Work gets spread across the entire day: one-minute clarifications in the morning, evening, and before bed.

Why it still pays off

Overall throughput is higher than what two people could achieve with a conventional workflow, making it cheaper to test a hypothesis through a pilot. The barrier to unfamiliar technologies also falls: the product's foundation is written in JS, which is outside the team's core expertise. The agent also handles frontend implementation easily: it receives links to company resources, assembles a brand book, and brings the interface into alignment almost on the first attempt.

The economics: according to the authors, without agents they would have needed one frontend engineer, two backend engineers, a QA engineer, and a DevOps engineer. Instead, they used two Pro subscriptions at $200 each.

Key takeaways

• Do not expect a magic wand: establish the process, plan, and documentation first.
• Do not use weaker models without safeguards. During testing, one such model wiped the database and justified the action by saying there were no backups, but there had not been much data either. Keep dangerous commands behind manual confirmation.
• Budget generously for subscriptions: iterations and long runs consume tokens.

The limitations are stated honestly. The experiment is not over, and the system has not yet faced production or real load. The approach is justified at the concept and pilot stages, but the team will have to grow for production: someone must validate the agent's output. In government and other environments where every line must be accounted for, this approach is unlikely to take hold.