Example note

Two pages, which is what you keep after a health-check. Page one is the conclusion. Page two is the author's comment. Below them, one task from the full report, with its mode. Names and the system are invented.

An internal order portal, preparing for three people and agents to change it. The same note is what a Rescue diagnostic produces. This example is a system that already works, so the newer blocks are visible: Next steps, and the author's comment. Not a promise that your system looks like this.

Page 1

What was asked

Can this portal be developed safely by three people and by AI agents, and what has to be fixed before accounting exports are added?

Conclusion

  1. The system is a good fit for one person. Speeding development up, with agents or with people, takes a few steps. Nothing needs to be rewritten.
  2. The main blocker: context is scattered, agreements are not written down everywhere, and the checks on those agreements (linters, formatters) have gaps. Several people cannot work in parallel yet.
  3. The main hidden architectural problem: hand-rolled data pipelines. They are fine for metrics on the fly. They will drag once the system is asked for retrospective reporting.
  4. Production is in good shape, with a few holes to close. The development environment is behind: it leans on the live databases, which is dangerous and slow.

Next steps

  • On your side.Name who is responsible for the portal, and who reviews a change. The report can be read with an agent. The agent must not be asked to edit the system from it.
  • With an engineer.Context, formatters, linters, and a separate development environment. These edits touch the whole codebase and live data. Only an engineer will notice an agent's mistake here.
  • Where I come in.Do the first wave with you, and set the agents up so three people do not block each other. That is safer than doing it alone or with the current team as it stands. Where it is not, the comment on page two says so.

Maturity

Now: stage 2. Aim: stage 3. People use the portal. Changes go out without tests and without a separate environment.

Practices and findings

GroupIn placeApplicableProblemsRecommendations
Technical and product context4623
Guardrails5945
Code quality61034
Parallel work1422
Security and leaks4733
Operations and environments3602

Page 2. Author's comment

I confirm this page. An agent may draft it. The draft does not ship until I do.

How I read this

The portal is in decent shape. The base works, and it does not need to be rewritten. The problem is not the quality of the code. The system is still built for one person who holds the shape of it in their head. Three people and a set of agents will get in each other's way on the day they are allowed near the live data. The conclusions above are about preparing to grow, not about a rescue.

The next weeks, and who does them

Start with what needs no code: decide who owns the engineering agreements, and name the person who reviews a change before it is merged. Then a development environment that does not use the live databases. That is the expensive link, in risk and in speed, and the rest leans on it. After that, the agreements for agents, the formatters, and the linters. The order and the mode of each task are in the full report.

You can hand the report to your agent so it can explain the findings and help you prepare questions. Do not let it change the system from the report without an engineer. It will confidently fix the wrong thing, and it will not know it has broken the environment or the permissions until that is expensive.

Where my involvement helps, and where it does not

Setting up the separate environment, and a review order that any of the three people and any agent can follow afterwards, is faster with me than alone or with the team as it stands. What matters there is having seen how this breaks, not knowing the tools. Formatters, linters, and ordinary agreements do not need me. Your engineer can do those from the list in the report.

How to continue

If working together is interesting, the next step is a conversation about which shape fits: a project with a written scope to prepare for the extra people, or accompaniment as the hard parts show up. I name the terms after that conversation, once it is clear who on your side reviews a change. If your own people are enough, the report stays with you and works without me.

One task from the full report

The report is for you, and for your agent, to read and to ask questions about. It is not a job the agent starts. A task is taken only when an engineer is named and will check the result. There is no mode in which the agent works alone.

  • Your decision, no code. Name who is responsible for the portal, and who reviews a change before it is merged.
  • Agent under an engineer's review. Formatters and linters, after the separate environment exists.
  • Only with an engineer. A development environment that does not use the live databases

A development environment that does not use the live databases

Only with an engineer

The change touches live data. An agent will not know what it broke until it is too late.

  • Before. A branch or a backup, and the tests on this part are green.
  • After. A change can be tried without writing to the live data.

Start the health-check

Back to Speedup · Rescue