How do you request a structural edit on a file the assistant cannot read in one piece?
answer
- It answered from what it could see
- A self-consistent slice, not the file
- Complete view of something small
- Who enumerates the uses? Not the model
basics
~20 sGive the tool a complete view of something small, not a partial view of something large: the block being moved, the uses you found yourself, the tests that pin it. What it cannot see, it fills in.
solid answer
~50 sThe tool answers from the window it was given, so when the file does not fit, it is reasoning about a slice and will not generally tell you which slice. That is why the edit comes back looking fine: local coherence is exactly what it is good at, and a fragment can be perfectly coherent while contradicting code that was never in view. So I do not widen the request, I narrow it: one named block to move, the list of its uses that I found with a whole-project search, the tests that pin the behaviour, and the invariant stated in words. Then I verify with the things that do read the whole program - the build, a search for the moved names, the suite - because the model's silence about the rest is not coverage.
code
pseudocode · 23 lines# WHAT THE TOOL WAS SENT - the first 120 lines of a 2,000-line handler
handleOrder(order):
order.fee = 0
if order.express:
order.fee = expressFee(order)
total = order.subtotal + order.fee
...
# ---- the window ends here; 1,880 lines were never sent ----
# WHAT CAME BACK - consistent with every line it was shown
computeTotal(order):
fee = 0 # the field became a local:
if order.express: # nothing in view read it again
fee = expressFee(order)
return order.subtotal + fee
handleOrder(order):
total = computeTotal(order)
...
# LINE 1,463, NEVER IN VIEW - still reads the field
printReceipt(order):
line("delivery", order.fee) # never written now; the fee drops offgo deeper
Know that the tool answers from the text it was given. If the file is longer than it can take, it is working from part of it and has no way to tell you which part it missed.
Explain why a partial view still yields a clean edit: the model makes the slice it saw self-consistent, and consistency with a fragment is not correctness for the file.
Describe how you scope it - one named block, its uses enumerated by a deterministic search, the tests handed over deliberately - and which whole-program check you run afterwards.
Decide when the answer is not a model at all: if the unit cannot be made whole inside the view, the mechanical half goes to a name-resolving tool and the rest is staged small enough to review.
## What the tool is answering from A suggestion engine answers from the text it was handed, and that text is a window. When the file is longer than the window, something has to give: the file arrives truncated, or as the region around your cursor, or as fragments a retrieval step thought were relevant. Whatever the mechanism, the model is reasoning about a **slice**, and the slice is not labelled as one. Everything outside it is not "unknown" to the model in a way it can report; it is simply absent, and absence reads like nothing to say. ## Why a partial view produces a clean-looking edit The edit comes back well-formed, idiomatic, and consistent with every line you can see in the diff. That is not luck. Local coherence is a property a model is good at, and a fragment can be made perfectly coherent while contradicting code that was never in view. So the ordinary failure here is not a garbled edit - it is a **locally correct** one. It compiles, it reads like something a careful colleague wrote, and it is unchecked against the parts of the program it never met. | what sits outside the view | what it does to the edit | what finds it | |---|---|---| | A second use of the moved block further down the file | the edit updates one use and leaves the other | a whole-project search for the name, run by you | | Another place implementing the same contract | the new signature fits one and breaks the other | the build, then reading the list of implementers | | A caller in a file that was never opened | the call site is left on the old shape | a reference search before the request, not after | | A test that documents the current behaviour | the edit changes what the test pinned | running the suite, and reading which test moved | | An earlier branch that already mutated the value | the extracted routine sees a different input than assumed | reading the whole path, once, yourself | | A distant reader of a field the edit turned into a local | the field stops being written and the reader goes quiet | reading the uses you enumerated, not the diff | ## Scoping the request so the unit is whole The move is to convert **a partial view of something large into a complete view of something small**. In practice: 1. Pick one unit: one block to lift, one name to change, one routine to restructure. Not "tidy up this file". 2. Enumerate its uses yourself, with something deterministic - a whole-project search for the name - and hand that list over with the request. You are supplying the part you cannot assume it will go and find. 3. Include the tests that pin the behaviour you claim to preserve, in the request itself. 4. State the invariant in words: "an order with no lines must still stop before charging". A stated invariant is the one thing in the request that the model can check its own output against. 5. Ask for the one edit, and ask for it to touch nothing else. A request that invites incidental improvements spends the view you carefully assembled on unrelated lines. ## When the view cannot be made whole Sometimes the unit genuinely is large - a routine whose body is longer than any window you can give it. Then the answer is to split the **edit**, not the file: - Give the mechanical half to a deterministic tool that resolves names the way the language does, and reserve the model for the half that needs judgment. - Stage the change so each stage is individually whole: one call site at a time, each with its own test run, rather than one sweep you cannot review. - Accept that "do this by hand" is a real answer for a small number of edits, and is cheaper than diagnosing a quiet behaviour change a week later. Cutting a whole *feature* into units for an agent to work through is a different subject; this is one structural edit on one oversized file. ## Reviewing an edit that was made from a slice Read the uses you enumerated up front, and compare them to what the diff touched. Run the things that read the entire program rather than a window - the build, the type check, the suite, a search for the old and new names - because those are the participants in the loop that do have a complete view. And treat the model's own account of the change as commentary, not evidence: it can describe what it did to the text it saw, and it cannot describe the use it never saw. ## The durable version of this answer Bigger windows keep arriving, and they move this problem without removing it: the uses of a name live across files, and a larger view also means a larger diff for a person to review. The sentence that stays true is that **what the tool could see determines what it could get right** - so the engineering work is in deciding what it sees, and in keeping a deterministic check in the loop for everything it did not.
- The request fits, but the block you are moving is used somewhere you did not include. What happens?The edit is right about everything it saw and leaves that use on the old shape, or silently changes what it does. The fix is upstream: enumerate the uses with a deterministic search before the request rather than hoping a wider window happens to include them.
- How do you check afterwards that the edit did not depend on something out of view?Run the participants that read the whole program - the build and type check, a search for the old and new names, the suite - and compare the diff against the list of uses you collected up front. A self-report of what was changed just restates the diff.
saying these in an interview costs you the question
- Assumes the tool read the whole file because it answered confidently
- Treats a summary of a long file as equivalent to the file
- Relies on the tool to announce that it ran out of context
- Thinks a larger window removes the need to scope the request
- Judges the edit by how clean the diff reads