A five-file code tour writes down the feature toggle that gates the decision an assistant has to find

The failure here is a localization failure. According to the dev.to write-up, an assistant trained on millions of open-source projects will suggest a change to the first file that looks like a match, even when the real logic lives two steps away in a file you never named ^[4]. Rewording the prompt does not add the call edge between those two files; something in the context window has to carry it.

The tour carries it as a walk through one feature, in order ^[5]:

1. The trigger. A button or form submission in a browser interface, the job definition for a scheduled task, the entry point that listens for incoming calls when the request arrives from outside. Write the file name and the function or line range, and if the first function only calls a second, follow it and note that file too ^[9]. 2. The main decision, where the code checks a condition, picks a path, or turns input into an action. Record the file, the function name, and any setting or fixed value it depends on: a feature toggle, a user role, an environment setting ^[10]. 3. The data path. Where the system reads, where it writes, any temporary holding area or call to another service, traced until the information reaches permanent storage or leaves the application ^[11]. 4. The visible result. The file and line that produces the success message, the list of errors, the response body and status, or the log entry for a background job ^[12].

Step two is the one I would not skip. A model can guess a handler from a folder name. The environment variable that gates the branch has to be written down.

The evidence under all of this is thinner than the recipe. The post cites 2024 research by Sergeyuk, Golubev, Bryksin and Ahmed finding that developers use AI far more often for writing and summarizing code than for figuring out where a change belongs ^[2], and lists three recurring complaints: inaccurate suggestions, weak understanding of the project, and misplaced confidence ^[3]. The study counts how often developers reach for AI to locate a change, says nothing about how often the assistant gets the location wrong, and the post does not report a before-and-after measurement of suggestion quality with a tour in context.

For the file count to hold, the decision has to sit in roughly one place. The worked example for a profile update lists five files: a form component, a function that checks the input, a handler that processes the request, a module that writes to storage, and a piece of code that formats the response ^[8]. The scope checklist also has five stops, so the finished artifact runs to about one entry per stop ^[1]. If permission checks live in middleware, validation in a schema, and the branch in a rules engine, the main-decision line turns into a summary of four files.

The upkeep is the real cost. Because the boundary is what the user experiences, an email sent when Save is clicked is a separate behavior with its own trace ^[6]; mixing behaviors, the post argues, produces the confusion the tour is meant to prevent, since the assistant sees several goals and picks the wrong one to optimize ^[7]. Every tour holds line ranges, and a rename invalidates them. The post asks writers to keep facts (file names you opened, function signatures you read, variable names you saw) apart from assumptions guessed from a comment ^[14], and I would keep that split for human readers even if no model ever read the file. The claim made for the finished tour is narrow: enough context to suggest a new field, a stricter rule, or a small change without rewriting the wrong function ^[16].