What an audit is, and what it is not
An audit is not a linter and it is not a security scan, though it will notice things both would. Those tools answer "is this line acceptable". An audit answers a harder question: would this system survive contact with real users, and can the person who owns it explain why.
- It reads the project as a system, not as a set of files.
- It reports the gap between what the code assumes and what production will do.
- It names what the owner cannot yet explain, because that is the risk that outlives any single bug.
- It ends with work you do, not a document you file.
What the audit reads
Point LoWisa at a local folder or a GitHub URL. It takes a safe sandbox copy and works there, so your original is never the thing being poked.
- Structure. Entry points, module boundaries, what is generated and what is hand-written.
- Data. Schema, queries, the path a record takes from input to storage and back.
- Resources. What each request acquires, and whether it gives it back. Connections, file handles, memory, locks.
- Trust. What is validated, what is assumed, where authorisation is decided.
- Operations. Configuration, logging, error handling, background work, deployment assumptions and backups.
The 25 areas that decide whether software survives
Findings are scored against 25 engineering ownership areas across 7 categories. These are not academic topics. They are the places real projects fail after launch.
| Category | Areas |
|---|---|
| Foundations | Version control, project structure, environment and secrets, code quality and types |
| Backend and data | Database schema, connection pooling, API routing, auth and authorization, API docs |
| Frontend and UX | State management, routing, styling systems |
| Infrastructure | Server config, Docker and containers, CI/CD pipelines, deployment and hosting |
| Operations | Logging and errors, monitoring, background jobs, performance, caching strategy |
| Security and storage | Security hardening, file storage and uploads, backup and recovery |
| Testing and debug | Unit, integration and end-to-end testing, debugging and troubleshooting |
Scoring against a fixed set matters more than it sounds. It stops the audit from reporting whatever happened to be interesting and makes two projects comparable, including the same project a month apart.
What you get back
Three things, in this order.
- Findings. What the code actually does in the places that carry risk, with the lines that prove it.
- Knowledge gaps. The difference between the findings and what you can currently explain. This is the part other tools do not produce.
- A plan. The gaps sequenced by what will teach you the most, so you are never re-learning what you already own.
What a real finding looks like
A generated endpoint that opens a database connection per request reads perfectly well and fails at scale. The audit reports it as three connected facts rather than one warning:
- The behaviour: a new connection is created on every call and never returned.
- The consequence: under production traffic the connection limit is exhausted and the service stops answering, with an error that blames the database.
- The gap: connection pooling, which you will implement yourself in the sandbox until it is second nature.
The same shape applies to a missing index, an unbounded upload, an auth check that runs after the work it was meant to guard, or a background job with no retry.
Running your first audit
- Install and open the project. LoWisa runs on Windows 10+, macOS 12+, Ubuntu 20.04+. Open the folder, or paste a GitHub URL if the code is not on this machine.
- Choose Audit my AI code. The project is copied to a sandbox and scanned before anything is narrated.
- Read the findings with the tutor. It opens each file, highlights the lines behind the finding and explains what the system does with them.
- Do the work. Break it on purpose, watch what production would do, then implement the fix yourself with the terminal checking your claims.
- Prove it. Explain the system back. The audit is finished when you can, not when the report is generated.
What the audit never does
It does not modify your project. It does not need production credentials to teach you the system. Experiments happen on the sandbox copy, and the original stays exactly as you left it.
Frequently asked questions
How is this different from a security scanner?
A scanner matches known-bad patterns. The audit reads the system, including the parts where nothing is technically wrong but the assumptions do not hold, and it reports what you cannot yet explain as well as what the code does.
Can I audit a repository that is not on my machine?
Yes. Paste a GitHub URL and LoWisa reads the repository in a sandbox.
Will it fix the problems for me?
It will show you the fix and check your work, but you write it. That is the point: the next project will have the same class of problem and nobody will be there to generate the patch.
How long does an audit take?
The read is quick. Working through the plan is the real time, and it is sequenced so the first hour covers the findings most likely to take your service down.
What does it cost?
Downloading is free and starts with 20 credits, awarded once on first install. LoWisa Starter is $8 a month with 200 credits included, LoWisa Plus is $11 a month with 500 credits included. A credit is one cent of AI, billed at exact provider cost.