Why does a multi-line completion get less trustworthy toward its last line than its first?
answer
- One keystroke, several decisions
- The first line has an anchor
- Later lines continue the suggestion itself
- Consistency is produced, not earned
- One early assumption, honoured downward
basics
~20 sThe first line continues code you wrote and can inspect; every line after it mostly continues text the tool just produced and nobody has checked. One early wrong assumption is then carried, consistently, by everything below it.
solid answer
~50 sA completion's first line is anchored to material you can inspect - the code above and below your cursor. Each further line rests more on the lines the tool itself just wrote, and those have been checked by nobody. So one wrong assumption early in a block does not produce one wrong line; it produces a block whose remaining lines are all consistent with it, and that internal consistency is the trap. A block that hangs together reads like a block that is right. The cost asymmetry makes it worse: accepting ten lines takes the same keystroke as accepting one, while verifying ten takes ten times the reading. Length is a risk gradient, not a verdict - plenty of long suggestions are fine, and the point is that the checking has to scale with the block rather than with the keystroke.
code
pseudocode · 13 lines# in the service you joined last week; one keystroke accepts all five lines
function listOrdersPage(customerId, pageToken):
|<- cursor
# suggested:
limit = DEFAULT_PAGE_SIZE # (1) real - this file declares it
offset = decodePageToken(pageToken) # (2) real name; here it returns a record, not a number
rows = orders.findPage(customerId, offset, limit) # (3) passes a record where a cursor is expected
next = encodePageToken(offset + limit) # (4) arithmetic on (2)'s assumed number
return { items: rows, nextPageToken: next } # (5) shape follows from (2) and (4)
# nothing here is invented. lines 3, 4 and 5 are consistent with line 2,
# and wrong together, because line 2 is what all three of them were built on.go deeper
Know that accepting several lines at once is several decisions taken with one keystroke, and that the later lines are the ones nobody has checked. Read the whole block, or take only the part you read.
Explain the dependency: the first line continues your code, later lines continue the tool's own output, so one early wrong assumption yields a block that is wrong consistently. Say plainly why consistency is not evidence.
Show that you scale the check to the block rather than to the keystroke, and that you can point at the line in a block where the risk actually enters - the one introducing a name or an assumption the rest inherits.
Own the trade this implies: suggestion length is the main lever on how much code gets accepted per human decision, so wanting more throughput from completion is wanting larger blocks per decision. Be able to say what you would give up for that, and where you would not.
## Two different kinds of line in one suggestion A multi-line suggestion looks like one object and is not. Its **first line** is a continuation of material you can see and did not write blind: the code above your cursor, the code below it, whatever else the tool assembled. You can check that line against things that exist independently of the suggestion. Every **later line** is largely a continuation of the earlier lines of the same suggestion. Those earlier lines came from the same place and have been verified by nobody - not by you, because you are reading the block for the first time, and not by anything else, because nothing has run yet. The further down the block you go, the larger the share of what a line is resting on that arrived in the last half second. ## Why a block that hangs together is not a block that is right This is the part candidates miss, and it is worth saying in an interview in exactly these terms: **internal consistency is produced, not earned**. A block continues itself, so of course its lines agree. If line two decides that a value is a number when it is really a record, lines three, four and five will all be written as though it were a number. Nothing in the block will look odd. The block will read better than one that is half right, because a half-right block has visible seams and a consistently-wrong one has none. So the reassuring feeling of "this hangs together" is evidence about the block's own coherence and no evidence at all about its fit with your codebase. ## Line one against line five | | what it rests on | what constrains it | what it costs to verify | |---|---|---|---| | **line 1** | code you can see around the cursor | your own intent, the names in scope, the shape of the function | a glance | | **line 5** | lines 1-4 of the same suggestion, plus whatever they assumed | almost nothing outside the block | re-reading four lines first, then checking their assumptions | Read it as a gradient rather than a cliff. There is no line number at which a suggestion becomes untrustworthy; what changes, monotonically, is how much of the line's support comes from inside the block. ## The cost asymmetry at the keystroke One keystroke accepts the whole block. The reading required to justify that keystroke scales with the block. That mismatch is the entire ergonomics problem of multi-line completion: the tool has made accepting cheaper without making checking cheaper, and the gap between the two is where unreviewed code enters a codebase. - Accepting one line and accepting twelve are the same physical act. - Rejecting costs the same either way, and you write the line you were going to write. - The saving a long suggestion offers is real, and it is a saving in typing, not in reading. ## What to do with a long suggestion 1. **Find the line that introduces something new** - a name, a shape, an assumption about what something returns. That line is where the risk enters, and the lines below inherit whatever it assumed. 2. **Check that line against something outside the block.** If you cannot, you are checking the block against itself. 3. **If your tool lets you take part of a suggestion, take the part you checked.** The rest can be offered again. 4. **If you cannot check it in the moment, reject it.** Typing the first line yourself usually produces a fresh, shorter suggestion for the rest. 5. **Read the finished unit once as a whole** afterwards. Line-by-line reading at accept time is a different, weaker check than reading the function you ended up with. ## Where a long suggestion is genuinely safe When the block is a shape the surrounding file already establishes, every name in it is one you can see, and nothing inside it introduces a decision the code around it does not already constrain, twelve lines can be checked in about the time one takes. That case is common, and it is why multi-line completion is useful rather than merely dangerous. The risk is not length by itself - it is length plus something introduced inside the block that nothing outside the block pins down. ## Answering this in an interview Say the mechanism, not the mood. "Later lines continue the suggestion's own earlier lines, so an early wrong assumption produces a block that is wrong consistently, and consistency reads like correctness." Then add the ergonomic half - one keystroke, N lines of reading owed - and finish with the habit you actually use. An interviewer is listening for whether you scale the check to the block or to the keystroke.
- Is a ten-line suggestion ever safer than ten one-line suggestions?Sometimes. When the block follows a shape the surrounding file already establishes and every name in it is one you can see, the ten lines are checkable together in roughly the time one takes. The danger is length plus something introduced inside the block that nothing outside it constrains.
- You accepted a block and the first failure appeared three lines in. What does that suggest about the rest?Look above the failure, not below it. A failure partway through a block usually traces to an assumption made in an earlier line, and the lines after it were written to be consistent with that same assumption. Re-read from the line that introduced it.
saying these in an interview costs you the question
- Treats a ten-line suggestion as ten independent one-line suggestions
- Trusts a block because its lines are consistent with each other
- Assumes a longer suggestion means the tool was more certain
- Expects the tests to catch whatever the later lines got wrong
- Reads the first line of a block and accepts the rest on its strength