Here's my strategy:
The codebase I work on was designed to be split by features. Architecture is well thought and each feature has the same high level abstractions, all code is in one folder. This bring several interesting guarantees: code is scoped to this folder, each feature is "not too big" and fits in the llm context easily, and a design document explains architecture choices, that is well respected by the llm.
When the llm works on a feature, it is instructed to do several things to help me catch errors before shipping. Write a templated description of the change: interactions with external systems, sequence diagram, happy path, corner cases, deploy checklist, settings change, etc. I review high level choices, and not the code.
Finally, the llm add review threads to the code everywhere it made suppositions and related to untested assumptions. Each of this comment says: what could not be teste, what the llm thinks, what happens if I don't change anything and release the code.
Finally, on parts where I want to be sure, I do llm-instructed testing. It can build complex test benchs in no time, fetch data from production "provide me the command to fetch data, and a script to anonymise it", do a before/after comparison, ... It costs few tokens but it buys the peace of mind.
This way I have a workflow where the code is fully written by the llm and I don't go crazy reading its code.
The codebase I work on was designed to be split by features. Architecture is well thought and each feature has the same high level abstractions, all code is in one folder. This bring several interesting guarantees: code is scoped to this folder, each feature is "not too big" and fits in the llm context easily, and a design document explains architecture choices, that is well respected by the llm.
When the llm works on a feature, it is instructed to do several things to help me catch errors before shipping. Write a templated description of the change: interactions with external systems, sequence diagram, happy path, corner cases, deploy checklist, settings change, etc. I review high level choices, and not the code.
Finally, the llm add review threads to the code everywhere it made suppositions and related to untested assumptions. Each of this comment says: what could not be teste, what the llm thinks, what happens if I don't change anything and release the code.
Finally, on parts where I want to be sure, I do llm-instructed testing. It can build complex test benchs in no time, fetch data from production "provide me the command to fetch data, and a script to anonymise it", do a before/after comparison, ... It costs few tokens but it buys the peace of mind.
This way I have a workflow where the code is fully written by the llm and I don't go crazy reading its code.