A better prompt won't fix your AI agent
Introducing Saaga, an agentic codebase documentation tool
Saaga is an open-source tool we built to document your codebase for AI coding agents and keep the documentation up to date as you build.
AI has made solid documentation a necessity. Still, many teams and tools treat documentation as a byproduct, often due to lack of resources. As a result, documentation is a one-off effort that's stale within the week.
By solving documentation, Saaga makes AI coding more rapid and much less error-prone. It runs on Cursor, Claude Code, and Copilot.
Saaga solves a concrete problem: An agent with no map rebuilds code that already exists, ignores your architecture and confidently provides wrong answers. Reliable documentation stops the guesswork. You save tokens and get fewer wrong answers in your PRs. In addition, non-engineers can use the documentation to understand how a domain feature has been implemented.
The agent isn't dumb; it's amnesiac
The instinctive solution to agentic mistakes is to write a better prompt, but that will only take you so far. The agent does not have the solutions, because in a typical codebase, answers to questions like "how does activation work" live nowhere in particular; they’re spread across dozens of files, hidden in conventions nobody made explicit. The agent reconstructs that picture under a token budget and fills the gaps with guesswork. What’s more, each session starts from zero, and the agent finds the same answers, over and over again. The fix isn't a sharper instruction. It's a map of the codebase. This is why we built Saaga.
Where Saaga came from
Saaga began in client work. We started a sprint with Museokortti (The Museum Card, a year-long entrance ticket to 360 museums in Finland). Their product runs on Salesforce — and none of our team had touched Salesforce before. That was a deliberate arrangement with the client: both teams wanted to know whether an agent could walk us into an unfamiliar system and let us do real work in it.
Day one, it could. We built a sizeable feature, and it worked.
However, there were many problems with this approach. The generated code did not follow project conventions, and the agent failed to reuse helpers and facilities already provided by the codebase. Additionally, since we were not accustomed to Salesforce development, it was difficult to judge how good the outcome was.
So, on day two, we came up with an idea: instead of crawling through the code ourselves, we would document the existing app to a format that makes sense to the agent.
Our plan was to create three document types:
concepts (what a given thing, like the Museum Card itself, means),
features (how a certain functionality runs end to end),
patterns (how a convention works, like how endpoints authenticate).
We cut the app into vertical slices and documented one slice at a time. The first pass managed to get the big picture right, but many random details were wrong — Museokortti's domain expert caught errors in minutes. That was no surprise, as no prompt produces airtight docs, however hard you tell it to check itself within a single agent session. So instead of fixing by hand, we added a pass that reads the documentation against the code and reports the contradictions. It found exactly the errors the expert had. Two or three rounds per slice, and we got no more findings.
The reason it worked is the keeper. Every document and every verification runs in a fresh session, with no memory of the previous one. Nothing carries forward, so the agent can't trust what it "already established". It has to open the code and look, every time. A long session does the opposite: its context fills with its own earlier guesses and it believes them over the source.
Most hallucinations don’t manifest right away, but much later in the session. That’s why clean sessions keep the documentation honest. The rest was engineering: wrapping the steps in a script, teaching it to plan and to update the docs instead of regenerating them.
The first version was a collection of shell scripts and prompts held together with duct tape. It worked because the two of us using the tool knew exactly how it worked. That strategy stops working the moment anyone else runs it, so we rewrote it in TypeScript and currently ship it over npm.
Saaga is a simple command-line tool. It gives the user free rein to decide how to use it in their project. For instance, besides running it manually, it can be automated in a CI/CD pipeline. Documenting a codebase the first time takes a few hours; after that you keep it current with a thorough overnight CI pass that opens a PR. Alternatively, you can perform a rough two-minute sweep before each commit that’s eighty percent accurate and always current, with an accurate pass taking place while you sleep.
Using Saaga in our own work, the difference is clear: without it, I push rougher code and clean up after the agent more often. The impact of the documentation can be observed even by asking yes/no questions about non-trivial implementation details. Without the documentation, the agent is usually wrong more times than with the documentation. Claude got the question right with the documentation, wrong without.
Why we open-sourced Saaga
We wanted Saaga for ourselves and our clients, and that created a problem. Consulting code becomes the client's property the moment it lands in their repo, and there's no clean way to carry a proprietary tool from one client to the next without it dissolving into someone's monorepo.
Licensing would simply be an awkward solution, solving some aspects of the problem but creating many more problems.
Open source solves it cleanly: the tool lives in the open and runs anywhere.
Making Saaga open source is also a concrete reflection of Wonna’s values. As a Finnish company, we value giving back to the Finnish developer community: we run meetups to share what we’ve learned and invite others to share too. Open-sourcing Saaga is a natural continuation of that. We hope it offers a practical example of the tooling needed for AI-native software development, and how that tooling works under the hood.
Use it for your work
We expect the first version of Saaga to be feature complete on September 2nd. Star the repo on GitHub to be notified the moment we go live.
Author
Tommi Sinivuo
As Wonna’s AI Lead, Tommi is the driving force behind our Exploring the Future of Coding journey. With nearly 15 years in software—mostly on the backend and DevOps side—they combine hands-on expertise with a passion for sustainability. Tommi has been exploring and applying AI-assisted development tools since their earliest public releases, gaining deep, practical insight into how these technologies reshape software development work.