A software developer has outlined an intentionally slower way to use large language models for programming: ask the assistant to propose code in a chat window, then type every change into the project by hand. Ankur Sethi argues that the practice helps preserve a developer’s understanding of a codebase while still saving time on routine work.
Sethi describes the risk of accepting large, automated changes as ‘cognitive debt.’ In his account, asking a coding assistant to implement an entire feature can leave the human owner disoriented, even if the feature appears to work. Reviewing a large AI-generated pull request is not an appealing substitute, he writes, because the reviewer must navigate code that may be overly defensive, poorly explained or subtly wrong.
His alternative is encoded in instructions used across his personal projects. The assistant is told not to create, modify, move or delete files without explicit permission. It must display proposed edits and state-changing commands in the conversation so that Sethi can enter or run them himself. The restrictions leave the model in an advisory role rather than giving it direct control of the repository. Sethi can stop at any unfamiliar API or algorithm, consult documentation or ask the assistant for an explanation before allowing the proposal into his code.
The method sacrifices much of the headline productivity associated with autonomous coding tools. Sethi estimates that it makes him roughly twice as fast as working without an assistant, rather than delivering the much larger gains sometimes claimed for AI coding. He considers the trade worthwhile because manually entering the code forces time for checking APIs, questioning algorithms and noticing hallucinations or weak design decisions. It also creates opportunities to refactor and adapt the proposal while it is being incorporated.
A second benefit, in Sethi’s view, is spatial familiarity. By making each edit, he develops a map of where functionality lives and how new work connects to existing components. That familiarity can help with later maintenance and can produce more precise instructions for the assistant. He compares the process with longstanding advice given to learners: type examples from books or forums instead of pasting them without reflection.
The proposal is a personal workflow, not evidence that manual retyping will improve every team or project. Sethi says it has worked for him for several months and that he values comprehension over maximum throughput. His broader concern is that extensive delegation to machines could leave the software industry responsible for systems whose construction is no longer well understood by the people maintaining them.
