What good engineering looks like in 2026: evidence for a safe change
Use a concrete change contract to connect boundary validation, meaningful tests, operational signals, and recovery.
Judge a change by what another engineer can verify
A useful engineering standard answers practical questions. What inputs does this change accept? Which business invariant does it preserve? How will an operator know it failed? Can the previous version still read the data it writes? Those questions remain useful regardless of the language or whether an AI assistant helped write the code.
Take a CSV export feature as an example. The happy path produces a file. The engineering work also includes preventing cross-account access, bounding memory use, reporting job failure, and deciding what happens when a user retries. A type checker alone cannot establish those properties.
End-to-end types can reduce mismatches between cooperating codebases. They do not validate arbitrary network input, authorize a user, or prove a database migration is reversible. Agent-generated tests are optional tooling, not a universal requirement for a serious product.
Write a change contract before choosing the test count
The following JSON is a review artifact for a fictional export job, not a schema accepted by a particular framework. It names the invariant and failure cases so the author and reviewer agree on the evidence required.
A useful test changes an observable outcome when the implementation is wrong. An authorization integration test should request another account's export and verify that no file or data is returned. A test that merely mocks the authorization method to return true does not exercise that boundary.
{
"feature": "account_csv_export",
"invariant": "only authorized account members can request and download exports",
"inputs": {
"date_range": "validated and bounded",
"account": "derived from authenticated authorization context"
},
"failure_cases": [
"request from another account",
"worker restart during generation",
"duplicate request",
"storage write failure"
],
"signals": [
"completed_jobs",
"failed_jobs",
"oldest_pending_job_age",
"job_duration"
],
"recovery": {
"stop_new_jobs": true,
"preserve_existing_job_records": true,
"reconcile_unknown_outcomes_before_retry": true
}
}
Observe the workflow the user depends on
A successful HTTP response may mean only that a job was queued. Measure completion separately, and carry a correlation identifier from the request into the worker and storage result. Keep account identifiers and filenames out of high-cardinality metric labels; put necessary diagnostic context in access-controlled logs.
Google's SRE guidance distinguishes measured service indicators from the objectives set for them. For an export, an indicator could be the fraction of accepted jobs that finish within the agreed deadline. Choose the target with product stakeholders and actual workload data; do not copy an availability percentage from another service.
Define terminal failure, cancellation, and overdue work explicitly. Otherwise, a job that disappears from a worker may never enter the failure count. Test the monitor using a synthetic failed job so the team knows the signal reaches someone who can act.
Logging every request body is not observability. Prefer event names, outcomes, durations, and redacted context. Establish retention and access rules before operational logs become an accidental copy of customer data.
Make rollout and rollback compatible with stored state
Introduce a new database field before requiring every process to populate it. During a rolling deployment, old web processes and new workers may run at the same time. Write compatibility tests around that mixed state instead of assuming the deployment switches every instance atomically.
Record what disabling the feature actually does. It may prevent new exports while already queued work continues. A recovery procedure needs to explain whether workers drain, pause, or reconcile incomplete jobs, and how a user sees the resulting status.
Use AI assistance where it improves the work: proposing edge cases, explaining unfamiliar code, or drafting a migration checklist. Review its output against the actual contract and execute the relevant checks. Generated assertions can repeat the same mistaken assumption as generated application code.
The standard is a change another engineer can understand, verify, operate, and recover. Tool choices should serve those properties, with effort scaled to the consequences of getting the change wrong.