What has actually been run, and where it stopped
Two delivered outcomes and three patterns in use. Each one says where it stopped.
Outcome means the real environment demonstrated the intended outcome, so each entry below states what was checked, what was observed, and where the work stopped. Stopping early is normal and often correct. The damage comes from describing weak evidence in the language of strong evidence, so "validated in the test environment, not yet observed in production" is written out in full rather than rounded up.
Everything on this page is software work. That is where the author works, so that is the evidence that exists. The cycle is not limited to software, and the rest of the site does not describe it that way — but no cycle outside software has been run and recorded here yet, and that gap is named rather than covered over. If you run one somewhere else, the repository is where it would go.
Contentful API migration
A CMS content API rewritten from a GraphQL integration to REST, and from .NET 9 MVC to .NET 10 Minimal APIs, with every route, JSON shape, and response envelope preserved so no consumer had to change.
A manual rewrite was estimated at 8–10 weeks of team effort. With AI carrying most of the implementation under close human direction, the implementation took about a day. Parity was checked across 36 endpoint cases: 34 matched exactly and 2 were signed-off deviations, alongside 239 tests. Both versions ran in the test environment with the API gateway pointing at the new one, so QA validated the real site and signed off. The production cutover has not run.
That day is implementation only. Testing and parity validation took roughly another day, and stakeholder agreement longer still, and the work was not continuous. Comparing one day against a ten-week estimate that included analysis and coordination would overstate it.
Performance was measured locally, two processes on one machine, and never on deployed infrastructure. The gains came from the architecture rather than from AI.
What matters here is how much AI lowered the barrier to attempting the work at all, rather than who wrote the code.
A React Server Components memory leak, traced upstream
A production application was crashing with out-of-memory errors. A blunt Node flag stopped the growth and stabilized production, and it also stripped error-stack detail everywhere. The mitigation was validated on a fleet running the same image: 113 restarts without the flag, zero with it, over about six and a half hours.
The investigation continued past the workaround, traced the retention mechanism into
React's react-server renderer, and produced a one-file fix contributed
upstream so other applications need not carry the same workaround.
Status: a CI-green pull request, not merged.
Built and used against real organizational data
Cross-team knowledge access, production exception remediation, and multi-repository defect remediation.
Knowledge access has answered real production and support incidents, including a data-synchronization failure that had survived an overnight investigation after the owning team had gone.
The remediation patterns have run on real work through existing review and deployment approvals. None is an always-on capability or adopted organization-wide, and each still depends on a human providing the map and holding the approvals.
Five lessons from running this on real work
These came out of the work above, including the parts that went badly. The evidence behind each one is software; the lesson is not.
- Focus beats parallelism
- Agents made it easy to run three initiatives at once, and context and human direction spread too thin across all of them. Dropping the parallelism and working one stream at a time is what finally resolved the hardest issue at its root. Human attention is the scarce resource, rather than AI throughput.
- Read the system before fixing it
- AI jumped straight to attempted fixes and repeatedly failed, because each attempt was a guess. Gathering what the system was really doing end to end, and adding logging where the picture had holes, found the root cause far faster than the fix-first thrashing that came before it. Thrashing is the signal to stop fixing and go back for the information.
- A workaround is not the destination
- Disabling stack-trace capture stopped the production memory growth, and that was the right immediate mitigation. Continuing past it found the retention mechanism underneath and produced an upstream fix instead of a workaround carried forever. Ask what a workaround is hiding or disabling, rather than only whether the incident stopped.
- You do not have to hold the context to be accountable for it
- A defect arrived in a flow the responsible human had never worked on. The orchestration layer read across the repositories, reproduced the behavior in the running application, and showed where it happened. The knowledge was in the system the whole time. Treat "I am not current on this area" as a question about access. Accountability stayed with the named human throughout.
- Write the context down, or pay for it again
- Two investigations, the same human, the same tools, the same period. The one that kept findings written down beside the work converged. The one where nothing persisted between passes degenerated into repeated attempts at a fix. A file maintained during the work is memory; a write-up produced afterwards is a report. That write is Growth, the fifth stage of the system cycle, and what it keeps becomes the next cycle's Context.
These share a root. AI multiplies whatever Context and Direction it is given. Teams that read the system first and then say what they want get outcomes that hold up, and teams that skip the reading get a lot of output and few outcomes.
Read the practices in full → · How AI fails, and which stage catches it →