From HTML and ASP to AI agents: two months with Salvor

Where I started

I used to write a site line by line myself. I knew why everything was the way it was, because I had made the call. Today agents write most of the code. Speed went way up, but something got lost: the reasons behind decisions.

An agent doesn't know today what it learned yesterday. I explain why we did something a certain way, open a new session the next day, and it makes the same mistake again. I also can't read every line agents write in a day. Most of the time I only see the bug after the site is live.

I came across Salvor on September 24 as a friend's open-source project and installed it on two real projects the same day: a fact-checking site and a kids' games site.

What changed for me

1. The project remembers itself now. Salvor keeps knowledge as plain Markdown files in a .salvor folder inside the project. When I open a new session, the agent already knows rules like "bump the version number before this site goes live". I don't have to explain them again.

2. Knowledge stays when the agent changes. I work with different agents on the same project. The knowledge lives in a file, not in a chat history, so whichever one I open starts from the same place.

3. The reasons are back. The "learned failures" list is made of plain sentences: what happened, why, and how to prevent it next time. The reasons I used to keep in my head are now written down inside the project.

4. I have the final say. Nothing an agent learns becomes permanent until I approve it. I decide what goes into the project's memory.

Where it was hard

Memory goes stale. Salvor's summary note describes the project's current state. But if I update the site and not the note, the next session starts with wrong information. That happened to me once on a live site. Now a small check runs at the start of every session and compares the claims in the summary with the real state.

Being written down isn't enough. Even when a failure is in the memory, an agent sometimes repeats it. Memory is a guide, not a guarantee. The final check is still mine.

Contributing to the project

I noted where I got stuck, turned it into clear, reproducible reports with the agents, and shared them on the project's GitHub. So far I've opened 7 pull requests and 5 issues. They include a security guide for repositories served by a web server, a guide to removing Salvor without losing knowledge, a proposal to give every option on the approval screen one plain-language line, a contradiction in the lifecycle of failure records, and field reports from two real projects.

The people who write a tool know how to use it. The people who use it show where it struggles. Both are needed.

Tips if you're starting out

• Start small. One project and the one or two most repeated mistakes are enough for day one.
• Don't approve what you don't understand. Ask the agent: "explain this in one sentence, no jargon".
• Read the memory once a week. It takes ten minutes. If something is stale or wrong, fix it.
• Don't hand over the final check to memory. Look at everything that goes live with your own eyes.

Bottom line

In the HTML and ASP years, I was the project's memory. Working with agents, that memory scattered. Salvor moved it back into the project, into files I can read. Agents change, the knowledge stays.

If you want to set it up, the code and install instructions are here: github.com/SalvorLabs/Salvor. Questions: t.me/SalvorLabs.