The way I do this is by still writing tests.

Do tests let you understand a codebase you have not written?

They can. Particularly if you use them to validate your assumptions about the code.

this desire to understand code will be soon be seen as rather anachronistic. What's important is that you understand your tests. Let the AI generate the code.

The spec and the test are your human contribution.

I understand your point of view but I think it's too "optimistic", i.e. it will not happen soon, at least not outside AI maximalists.

you're describing TDD and it never turned into the panacea that was promised. I'm excited to try claude code, i even have a decent little personal project lined up for it but someone somewhere will always need to understand the code because tests are never 100% exhaustive and major flaws come up.

Ah yes, can't wait to tell my auditor / regulator "I don't understand the code because Claude wrote it, but it's fine, because understand the code is for boomers." That will get a big laugh in a deposition.

That'll be anachronistic too obviously. Your tests will be audited.

If the tests are written with sufficient detail that you don't need to look at the code, the implementation of the code is such a small part of the overall work that you are gaining very little in terms of overall productivity.

I agree

I would say yes.

To have useful tests, you must write the APIs for the functions, and give examples of how to wire up the various constructs, and correct input/output pairs.

Implementations of those functions that pass the test now have significant constraints that mean you understand a lot about it.

That’s called Test Driven Development.

First you write the tests, then you write code until tests pass.

How do you know your own handwritten 20k lines of code have no bugs, or that 20k lines of code written by coworkers have no bugs?

I'm not the person you're replying to, but I have a lot more confidence in my own 20k lines of code than an AIs. I've built up skills to write performant, readable, functional, maintainable code. I build it up slowly and I can anticipate bugs as I write. I'm not perfect, but when bugs do arise, since I've built up the code, I have some idea of where to look and where not to look in order to fix them.

As for coworkers, I would really try to get them to work in chunks smaller than 20k loc. But at some point you have an expectation that coworkers will be accountable for their area of responsibility. If there's a bug in their code, they're expected to fix it. If there's a bug in the AIs code, I'm expected to fix it....