The problem
JDQ’s developers maintain Project Watch™, our own end-to-end app, and nine large client applications. So far we use AI coding agents on about 1.3 million lines of code in four codebases: Project Watch™, old and new, and two of those client applications. The other seven will follow as each client approves the use of AI coding agents on its application. Our older ASP.NET Web Forms applications had no automated tests, so every change meant careful manual checking. Modernizing Project Watch™ meant working through about 280,000 lines of legacy code, where many features had been built three times over the years (Microsoft Access, then Web Forms, then Blazor), and business rules sometimes went missing between generations. Repetitive work such as data-entry pages, grids, reports and database scripts took a lot of time. Important but not urgent work kept slipping: automated tests, written coding standards, and consistency reviews across whole applications.
What we built
Three JDQ developers now use AI coding agents on three applications, at every stage except deployment. For each request, the agent reads the Project Watch™ issue, explores the code and the development database, and writes a plan with findings, options and open questions. The developer makes the decisions and approves the plan before any code is written. The agent then makes the change, with the code automatically formatted and built after every edit. It writes automated tests, and drafts database changes as numbered scripts paired with rollback scripts. Specialized helper agents convert legacy pages, write tests, and review code and migrations; the reviewers can read the code but not change it. The agents connect through MCP to technical documentation. Our coding standards and architecture rules, once mostly unwritten habits, are now written down in each code repository, and the agents follow them consistently.
People stay in charge. For production code and database scripts, the agents work at the Supervised level of our trust ladder: a developer approves every commit individually, and pushing code, updating databases, publishing and changing configuration always need approval. Tests, documentation and read-only reviews run closer to Spot-checked. The agents never touch production systems. Developers review and run every database script by hand, first in development, then test, then production, and client user acceptance testing (UAT) is unchanged. Our code and prompts are not used to train AI models.
A typical request. A client asked for an older report to be added to the new report manager, with the same job picker as a recent report. The agent found that the database view and the report’s registration already existed, so the change needed only two settings and one code branch. It also noticed that a query pasted into the issue belonged to a different report, and asked instead of guessing. The developer approved the plan, tested against its verification steps, reviewed the changes and approved each commit, then deployed it for the client’s UAT.
What clients see. Faster turnaround on requests and fixes; a typical enhancement or fix now takes about five hours. Hidden scope surfaces before work starts: on one issue estimated at 8 hours, the agent’s exploration showed the real work was 38 to 46 hours, so the client could decide before the budget was spent. Data fixes come with before-and-after checks and rollback scripts, and UAT comes with a written testing guide. Our run-time error triage agent was itself built this way, in 25 hours against a 40-hour estimate.
Results
Lessons
What surprised us most was how much the agent finds before writing any code: contradictions in a request, features an older version had that the newer one dropped, and scope well beyond the estimate. Reviews across a whole application became practical: one pass checked every button and link in 104 files. And results depend on written rules. Once our architecture rules were written down, the agents followed them consistently.
Mistakes happen, and review is how they are caught. While migrating pages, an agent connected 12 buttons to pages that had not been migrated yet, and two buttons opened the timesheet editor without the details it needed. The code built cleanly and the tests passed. Our review of every button and link in the app (516 buttons and 392 navigation targets) found both problems on October 9, 2026, and they were fixed the same day. The lesson: a clean build and passing tests do not prove navigation works, so route and link checks are now part of every review.
We keep the agents away from production, deployments, and decisions that need business or visual design judgement; those stay with the developer and the client. Where results must be identical every time, we use plain code, not AI. For developers, the job shifts toward clear requirements and plans, critical code review, and keeping the written standards current, because that is what the agents work from.
“The agent does the first pass and the homework. We still decide and still take responsibility for every line that ships.” — Gary Fuhr, JDQ Principal
Related: Run-time error and issue triage