The Need for AI Agents Beyond Coding in Software Engineering
Coding agents made code cheap. They did not make software more reliable, and they did not make it any easier to tell whether anyone uses what shipped. Cheap code was never the goal: a product people rely on and keep coming back to is, and most of the work that produces one is still done by hand. Agents could be doing far more of it.
Software Engineering before AI Agents
Long before the recent AI wave, I believed that good software didn't come from great engineers, but from good processes and best practices. One great engineer, or a handful of them, can lay strong foundations. Once that handful becomes a team, talent alone stops being enough to keep software reliable and maintainable.
What makes good engineering is everything around the code: system designs, decisions written down with the reasoning behind them, processes that protect quality, measurement of what each change does, and the discipline to catch failures fast and stop them from recurring.
Coding Agents Solved One of Three Problems
Code Has Become Cheap
Building software runs in a loop: planning what gets built, implementing it in code, and learning from production to iterate on what shipped. Agents solved the middle one. Code is cheap now, but cheap code is not the goal. Software people actually want to use comes from the whole loop, and a loop closed by hand usually is not closed at all.
The Two Problems Still Unsolved
Automated Project Orchestration
More code means more of everything around it: more decisions to record, more designs to keep current, more work in flight to coordinate. None of that got cheaper, even though agents are capable of most of it. The processes that produce good software are well known, and they should be made AI native:
- Plan with agents at the initiative level, then break the work into epics and tasks, each with dependencies and acceptance criteria, persisted outside the session that produced them.
- Document why each key decision was made, and which alternatives were rejected.
- Attach evidence to every acceptance criterion, showing how it was met.
- Update tasks and documentation automatically as direction changes and features ship.
These practices matter more for agents than they ever did for people. Well-scoped tasks produce better implementations. Required evidence prevents reward hacking. A written record of past decisions gives agents memory. They read the reasoning behind the code, not just the code itself, so they know when a direction must hold and when it is OK to try something new. Measurable goals keep them working toward an outcome instead of a closed ticket.
Closing the Loop: Learning from Production
Orchestration covers everything up to the moment code ships. Software is often treated as done when it reaches production, but what happens next matters just as much: errors that only surface under real traffic, performance that degrades as usage grows, flows people abandon halfway, features that ship and go unused.
All of that is already visible in rollouts, observability, and analytics. The signal is not what is missing, but reacting to it manually is slow and expensive.
Where Today's Tools Stop
Coding agents like Claude Code focus on the code. They are excellent at working through a problem with you, but orchestration and production feedback are left entirely to the user. Managed platforms like Lovable optimize for the UI and for speed to a first version, which is a different problem from keeping a system maintainable as it grows.
Both are useful for what they were built for. But any team whose business runs on complex logic, performance, and reliability is left to build everything around the code on its own. That work has not gotten smaller. Now that code is cheap, it is the bottleneck.
SetForth Automates the Work Around the Code
Agents write the code. SetForth runs the engineering around it. That is worth it for two reasons: software that stays maintainable as agents and teams scale, and progress measured by impact in production rather than by tickets closed.
SetForth connects new or existing repos to these processes. You keep your code, your dependencies, and your infrastructure. You decide which practices to follow, what an agent automates, and which decisions stay yours.
It maintains system designs that stay current, records every decision with the alternatives considered, and attaches evidence of what was built and how it was tested. It knows the goal behind each epic, updating tasks as direction changes and opening new ones when an implementation falls short. When you allow it, it rolls out changes, watches error rates, rolls back when something breaks, and measures the impact in your product analytics.
The measure of a change is whether it worked, not whether it shipped.