Different systems, different starting points. One goal: changes ship without breaking things.

Situation

I took over a system that already worked. A studio team had built it: engineers, designers, testers and managers. Every change took months. Some problems stayed open for years, even though the budget for development was there. The file management module, for one, kept producing bugs for a whole summer.

What I did

I was going to be the only engineer, so I built the whole process around AI agents. Requirements analysis, development, QA and deployment are separate steps with automated checks between them. I make the key technology decisions. The agents do the rest.

Result

• The new dashboard went live within a week. The new timesheets page matched every feature of the old one about two weeks after the first prototype.
• The whole interface was redesigned in two months.
• In a single month: new HR and sales modules, an automations engine, process templates and a major framework upgrade. with zero regressions.
• The commit rate (i.e. the pace of shipping new features) went up about eight times.
• I no longer write code myself. I review decisions and the agents deliver.

Situation

The founder runs an online school. She had read the stories about vibe coding and wanted one system for schedules, attendance, teachers and payments, but had no idea where to start. The school lived in a pile of spreadsheets. Entering data into the CRM, seating children in groups by hand, planning schedules, creating parent chats, managing video rooms, checking attendance and calculating payroll took several people.

What I did

I set up the foundation: the technology stack, the architecture, automated tests and linters, and a written rulebook that the AI agents read before every task. The agents also update the documentation after each task, so the rules keep up with the system. I added monitoring, backups and a deployment pipeline.

Then I stepped back. The founder has no programming background. She works with the AI agents herself, and she is the only one who does.

Result, from the code history

• She made 84% of all changes herself, working with AI agents, and committed code in almost every week since the start.
• The backend grew 3.3 times and the data models 2.3 times.
• The automated tests grew 4.5 times.
• The system is connected to many external services: a CRM, payment providers, messaging, video calls, calendars, documents and ad platforms. All connections are monitored and looked after.
• My time went from a few hours every week at the start to occasional monitoring and rare changes to infrastructure and rules, which takes me around an hour a month.
• The data center hosting the system went offline twice, once briefly and once for a long stretch. The system was restored from backups at another site.
• The whole school works in it: groups, students, teachers and administrators. The people who used to enter data now sell and help customers.

Situation

The owner of a clothing brand is not an engineer. Alone, with Claude, he built a large internal system: analytics, shipments, inventory, trend research, pricing and finance. His team uses its interface. Every technical and architectural decision in it was made by agents.

The tests, linters and security were at a decent level, but they did not work together. The seams between parts of the system were not checked, and the context was scattered across Claude’s memory files. The agents needed constant correcting, and the owner had become the tester.

What I did

I audited the repository against a catalogue of engineering practices. Then I put the context in order. The memory files became agent-agnostic rules files, made consistent with each other. The development principles are written down, and each one is backed by a test or a linter. The agents update the documentation themselves, by rule. I checked all of it on a couple of real tasks.

He got a two-page note for himself and a detailed report for his agent.

Result

• The system is in decent shape: no gaping holes, and the debt is local and does not block work.
• The rules, tests and context now work together. The agents read one consistent set of rules, and each development principle is checked automatically.
• Every finding in the report is sorted by who should act on it: the owner, an agent under review, or an engineer only. The owner knows what he can hand to an agent and where an engineer is needed.
• The next step is several people and agents working in parallel. The report names what stands in the way and the order to remove it.