A computer for local coding AI: autocomplete and agents need different tests

While writing a TypeScript form, autocomplete proposes a short continuation after the cursor. Even a correct suggestion helps less if it arrives after you have already typed the next line. In the same file, record when suggestions arrive, whether you accept them, and what you edit afterward. Generating a complete function in chat means reviewing and inserting the whole result; using autocomplete means judging whether a short suggestion fits the current line and variable flow.

First check that your editor supports the model, then see whether suggestions follow the project's variable names and code style. Pasting a complete function and then renaming variables has different review needs from receiving a bracket or conditional one line at a time. Open a typical file in your actual editor, accept suggestions, and record how much you change to see whether autocomplete helps your workflow.

For an invitation-code validator, define the expected behavior: reject an empty string and three spaces, but accept AB-12 unchanged. A length-only check could accept three spaces, so trim surrounding whitespace before checking whether the value is empty. The normalized value used for this check does not have to replace the stored value. Changing the case of a valid code or its storage format would go beyond the request.

Give the model the reproducing inputs, current behavior, expected behavior, and only the relevant function and caller. In the diff, check which files changed and how broad the edit is; in tests, check the actual outcome for all three cases. If there are no automated tests, create a small reproduction with those inputs. One passing case does not validate the whole form: check the validator separately from the screen's submit and error-message behavior. Confirm that the screen prevents submission and clears its error when appropriate so users experience the policy correctly.

When a test fails, distinguish a validator bug from a problem in how the screen passes the value. If both layers need changes, decide which layer owns the rule and limit edits to the necessary files. This reduces the risk that handling an exception in one screen changes another form's behavior.

An agent editing multiple files uses the request, code, earlier responses, and tool results as context. If the invitation-code rule spans a screen and tests, locate and provide those relevant files together. Sending the entire repository can add unrelated code and make the needed locations harder to identify. A longer context can hold more material, but it does not automatically find the right files.

Locate the function containing the rule, the screen that calls it, and the existing tests. If the agent edited a different form with a similar name, correct the search path first. If it read the right files but missed how the function and screen connect, break the plan into steps: edit the validator, inspect the caller, and check the error display. Existing tests may capture exception policies that are not obvious from a function name, so read them before editing and verify that the agent's explanation matches the files it actually inspected.

Reading files, applying edits, and running tests or package-install commands have different effects on the repository and environment. Do not enable the entire repository, terminal, and installation permissions at once. Start with read access to locate the necessary files. Review the diff before applying edits, and run tests only after understanding what the command affects. Using a local model does not mean search tools or external APIs also operate locally.

Test an invitation-code change in a copy or separate branch, and do not provide secrets or real customer data. If tests require network access or installation, inspect the runtime¹ environment separately from file-edit permissions. For sensitive repositories, exclude tools that may transmit data externally and test execution permissions only in a reversible copy.

Compare candidates on the same TypeScript form task. For autocomplete, check whether suggestions fit the typing flow; for a function edit, confirm that empty and whitespace-only input is rejected while AB-12 is preserved; for an agent, inspect edit scope and test results. If you plan to use multiple roles, test the model combination and concurrency you will actually use. Short-suggestion speed does not predict completion time for a multi-file task.

Consider two hypothetical edits. A takes 15 seconds to generate and another 90 seconds of human editing, for 105 seconds total. B takes 30 seconds to generate and 20 seconds of editing, for 50 seconds total. The slower generator finishes the overall task first. These illustrative numbers are not measurements of specific models; tests and review effort must also be comparable for a fair comparison. Use speed comparisons to narrow candidates, then complete the real form task through testing. If editing and review work well on your current device, you can postpone a purchase.