Is reading code becoming an anachronism?

Over the last ten weeks I've built a full multi-platform app and I haven't read a line of its code.

When last did you look at the output of a compiler? Or do you just accept that it works and trust that the machine code is correct?

I have a suspicion that most software development is headed this way and looking at the code will become old-fashioned, with the exception of certain kinds of specialist work, much like we use compilers for almost everything except very niche applications such as space constrained microcontrollers and highly optimised time critical loops. Even this is increasingly rare.

The approach that I have used is to treat the AI as a direct report, rather than a glorified code autocomplete. I set up an orchestrator that delegates work to teams of subagents, staying responsive so it can interact with me. My 25 years in the tech industry as a developer, product and project manager translate directly to this scenario.

The app I've produced is a personal productivity tool. I couldn't find what I wanted, so I decided (against Claude's correct advice that it would be expensive) to build it. It runs across my three primary platforms: Android, Windows and web. My first draft of the spec was in mid-March, but the bulk of the work has been in the last 10 weeks. The true value is not the product that I truly love using, but what I learned from the process.

Claude writes the code, tests and documentation, and I manage product purpose, process and philosophy, as well as user interface approval and final authority on irreversible decisions. The process is very reminiscent of managing remote teams via Slack, just with less ceremony and none of the Zoom meetings. This 'small' side project has reminded me of how much work this can be!

The code base is approximately 190,000 lines of code, of which only 61,000 are the app itself. The remaining 129,000 lines consist of 3,207 unit and widget test cases, integration tests and end-to-end (e2e) tests. My app's test ratio grew progressively over the development but has stabilised over the last couple of weeks. This is part of the price of using AI at this stage of its development.

Excluding integration and e2e tests to compare apples with apples gives a test to code ratio of 1.9:1 (vs 2.1:1 all in), which is more than four times the median 0.4:1 ratio worked out from a recent study of 526 popular GitHub projects (Miranda et al., 2025), and better than Flutter's 1.3:1 but nowhere close to SQLite's 590:1 ratio (sqlite.org/testing.html).

The objection that I suspect many people have is that the agents are testing their own code, and that they might overlook errors they create or, more insidiously, that rather than fix an error they might ignore negative test results, or even change the test to pass the error. The three main ways I deal with this are 1) adversarial code reviews: set an LLM to catch an LLM 2) use mutation to deliberately introduce errors in the code to test the tests and confirm that they catch the mutations 3) use the app as my daily driver.

The downside to all of this is that it takes time and money. Since June the test code grew from 0.27 to 1.9 times the app code. The full test suite takes almost an hour to run on GitHub. I've reduced that to 19 minutes of clock time by sharding it into three parallel parts, but it still consumes the same amount of compute, a total of about $0.35 per run.

With review passes, fixes, branch updates and the final master run, each new feature takes multiple pushes, averaging $1.71 per Pull Request. When you are building at pace, that accumulates rapidly, with $400 in GitHub fees, only 2/3 of the way through the month! While test code has grown much more rapidly than app code, the ratio has stabilised, and test cost and run time should scale linearly with app code from here on.

So far, between Claude and GitHub I've spent about $2,000 on this project. My sense of the product I have on my phone is that it would have taken a team of 2-3 developers and a part-time tester and UI designer about six months to get to where I'm at, perhaps more. Discounting my own time, as it would apply to both scenarios, that salary bill would be dozens of times higher than the tool cost.

There are limits to how much this approach can scale. On the tool side (currently) context windows limit how much code an LLM can read at a time. Approaches to work around this exist, and are getting better with time, but it remains a challenge for large code bases. Test growth, and more importantly test run time, are also limits that will slow dev cycles and increase their costs. Finally, having a single human as the final arbiter imposes an inevitable bottleneck.

A caveat: I would not recommend this approach for mission critical software. Anything where errors would have irreversible consequences for client, company or country should be built with a human in the loop, reviewing the code and testing thoroughly. Conversely, I think that not letting an LLM review your codebase nowadays seems shortsighted. You bear responsibility for anything you release, LLM authorship or not.

In conclusion, you can now do as a single founder what would have taken a team of several people only a few years ago, for a fraction of the cost. Doing it properly is not easy, and even as an experienced developer/product person/project manager I still took months to get to where I am, with some expensive pitfalls uncovered along the way (I'll look at the receipts in another post).

If you would like to learn from what I've done, rather than repeat my mistakes, have a look at github.com/adriaan-wessels/solo-ai-kit. Unlike this article, which is all my own words, I've let Claude write the repo under my oversight. While it's built for Claude on Windows, the principles should extend to any frontier model running on a modern operating system. Share it with your own LLM and ask it which practices and procedures will work for your own setup.