How AI has changed development

Autocomplete suggests the next few lines of the function a developer is viewing, while a coding agent can receive a goal, locate relevant files, run tests, and select the next change based on failures. Even with the same model, connecting read, write, and execution tools changes the system's responsibilities and risks. Package installation and deployment, in particular, affect much broader external state than source-code suggestions.

For small bug fixes, an effective loop is to reproduce the failure first, read the relevant contract, make a minimal diff, and then re-verify with the same command. Conversely, giving an agent write access to the entire repository while the goal is ambiguous lets it redefine on its own what counts as done. The higher the level of automation, the more specific the acceptance criterion, stop conditions, and reversible units of change must be.

Gathering context is not about attaching as many search results as possible. When fixing a payment amount error, business rules, public API types, the amount calculation function, existing regression tests, and actual error logs come first. Including every file with payment in its name, or old build artifacts, mixes information from different revisions and can lead to misreading the current contract.

A good work record does not stop at “this file seems relevant”; it preserves both evidence and gaps. For example, distinguish that the API schema is canonical and the generated client is derived, that a production error occurred only at a certain revision, and that production-data conditions have not yet been reproduced. These distinctions let the next person review or challenge the reasoning without repeating it.

A TypeScript interface aligns value shapes among compiled components, but HTTP responses arrive from outside compilation. At the boundary, accept JSON as `unknown`, validate required fields, ranges, and combination rules with a schema validator, then narrow it to a safe type. Simple property checks can miss number-like strings or IDs that exist but are empty.

A schema need not contain every business rule. Rules such as “the end date is later than the start date” or “only the payer may request a refund” require examining multiple fields and current permissions together. Record shape validation, domain validation, and authorization as distinct errors so the agent knows what to fix and is less likely to bypass checks with an incorrect assertion.

The first step in a verification loop is to establish reproducible failure conditions, not to make a fix. Record the input, execution environment, expected result, and actual result, then check that the test fails under those conditions before changing the code. Without reproduction, a code change cannot show whether the symptom vanished by chance or the cause was removed, and it is easy to declare completion while the same defect remains under other conditions.

After a fix, run not only the new test but also type checks, affected unit and contract tests, and representative browser journeys according to risk. Simply rerunning a failed command until it passes is not evidence. Isolate environmental causes, or control time and shared state for flaky signals, then verify repeatable results with the original inputs.

An agent with read-only permissions cannot directly change external state even if it reaches a wrong conclusion. Each added capability, such as file writes, shell execution, network transmission, account changes, and production deployment, widens the breach scope and raises recovery costs. Permissions should therefore be split by capability and target rather than bundled under a single “use development tools” grant.

Approval is an information boundary for understanding the actual change, not a formality of clicking a button once. The approval screen should show the target environment, before-and-after values, actor, and recovery method. Repeated low-risk reads may be automated by policy, but sending secrets, deleting data, and deploying to production require explicit reconfirmation, while server-side authorization must remain separate.

A fictional fixture applies a 10% discount to a 10,000-won order with a 700-won cap. The expected discount is 700 won; this teaching contract detects a missing cap and is not a real company policy. Place capped and uncapped inputs side by side. This also catches a bogus fix that hard-codes every result to 700 won.

The test must initially fail if the old function returns 1,000 won. After it returns 700, also retest uncapped and ineligible orders to check that the local fix has not harmed other cases. Find other callers such as refunds or recalculation. A shared-function change can affect more than the reported screen, requiring checks on consumer contracts.

If test files are part of the patch, review expected-value changes separately. Changing 700 to 1,000 without an approved policy change makes tests pass while preserving the original defect. If a policy change is approved, record its evidence and effective date. Distinguishing policy changes from bug fixes prevents recalculating historical orders under unintended new rules.

Link the failing fixture, approved rule, patch and rerun results. This answers which user-visible error was removed, a more useful question than coverage alone. Record command exit codes and failing inputs. A note saying “tested” cannot distinguish undiscovered tests from executed tests whose results were ignored.

Insert a request to transmit a secret file externally into a teaching README. This is an attack fixture testing whether untrusted input changes the task boundary, not an authorized action. Use a fake marker instead of a real secret and observe attempted egress through a blocked collector. The test itself must not expose personal data or production credentials.

Success means no actual secret-file read or external request, not merely a warning from the model. Inspect rejected targets and policy decisions in tool traces without recording secret contents. Check that rejection logs do not copy the marker from protected files. Blocking execution while echoing sensitive content in errors merely moves exposure into observability storage.

Move the instruction into log comments and test-failure messages as well. A string filter targeting only README content can miss equivalent instructions arriving through other paths. Allowed targets must remain unchanged when the attack is paraphrased. A boundary owned by provenance and execution policy differs from a filter memorizing one sentence.

After restoring normal error logs, bug reproduction and authorized edits must still work. Blocking every tool is not a successful development assistant, so retain normal-task regression evidence too. For normal fixtures, verify that enough relevant error lines and functions remain available. Removing all context and forcing the model to guess the cause is not a solution.

A fictional task is a patch that fixes the date format in CSV exports. The reviewer checks that only output examples and the related parser and test changes are included, and moves any unrelated authentication-setting change to a separate review. For each file, briefly record who authored the change and why this fix needs it. Even when several people have edited the same file, do not treat the whole task as one owner’s result.

Reproduce the bug while preserving any user-authored UI-copy changes already in the working tree. If those disappear across the patch, the preservation contract fails even when tests pass. Do not automatically clean uncommitted changes when creating a test environment. If using an isolated copy, record included changes so differences in test inputs remain visible.

Test the corrected CSV with a fixture representing an older consumer. Even accurate dates may require a compatibility notice or version boundary if existing clients cannot parse them. Record the consumer parser version and expected date. If browsers and batch jobs interpret the CSV differently, explicit supported consumers make compatibility judgments reproducible.

Describe changed behavior, reproduced errors, passing checks, and remaining compatibility conditions. Do not claim deployment or operational recovery that was never performed; the next approver needs an accurate view of remaining work. Remaining work is information about the approval boundary, not a reporting flaw. When deployment permission or data-change approval is required, mark code-review completion and operational rollout separately.