AI-assisted engineering: evidence over output

A bounded method for using AI in software work without outsourcing technical judgement.

AI can shorten exploration and implementation. It cannot own the technical decision, the risk or the release. The useful question is not how much code a model produced. It is what evidence remains when the code has to be understood, tested, secured and maintained.

This is the method I use for AI-assisted engineering work. It is grounded in the public Formatloom and Max Bid projects, but it does not claim that every line of those projects was generated by AI. The recorded evidence supports a narrower statement: AI helped with parts of implementation and technical exploration, while the product boundaries, review, tests and release responsibility remained human-owned.

Specification and constraints come first

Before asking AI to change code, I write down what the product must do, what it must never do and how the result will be checked. The specification is not ceremony for the model. It is the boundary that makes a generated suggestion reviewable.

Formatloom has a clear example: processing stays in the browser, there is no upload endpoint or application database, the input is limited to 1 MiB and lossy conversion must produce a visible warning. Max Bid has a different boundary: one calculation contract must remain understandable across a Rails reference application and a TypeScript static implementation, with localization and no currency conversion.

The constraints change the questions I ask. Instead of asking for a generic implementation, I can ask whether a proposal preserves a privacy boundary, matches an observable contract, handles stale browser work, or exposes a parser limitation to the user.

AI-assisted exploration

AI is useful as a fast partner for exploring a bounded problem. I use it to compare implementation options, enumerate edge cases, suggest test fixtures, explain unfamiliar APIs and identify questions that a design still leaves unanswered.

The output is a candidate, not a decision. I check it against the repository instructions, the specification, existing conventions and the smallest useful change. A fluent answer is not evidence that the design is correct. The evidence comes from the contract, the code, the tests and the running product.

I do not publish an exact prompt or interaction count. Those numbers were not recorded as a reliable project metric, and a prompt count would not prove engineering quality anyway. The meaningful record is the chain from constraint to decision to verification.

Implementation stays incremental

The safest AI-assisted change is small enough to inspect. I prefer a sequence of narrow slices:

state the behaviour and acceptance conditions;
locate the responsible boundary in the repository;
ask for one implementation or a focused comparison;
inspect the diff and reject unnecessary changes;
run the checks that cover the changed boundary;
inspect the product before moving to the next slice.

This keeps the model close to the source of truth. It also makes failure recoverable. If a suggestion is wrong, the diff is small, the reason is visible and the next attempt does not need to rediscover the whole system.

Human review is the ownership boundary

The person submitting the change owns the result, regardless of who typed the code. Human review means more than scanning for style issues. It asks whether the implementation solves the stated problem, whether the trade-offs are acceptable and whether the author can explain the important paths and failure modes.

For long-lived code, I review data flow, state transitions, error handling, complexity, security boundaries, accessibility and maintenance cost. I also check whether the implementation quietly added a capability the product did not need, such as persistence, an external request or a new secret.

The depth of review follows risk. A disposable experiment can have a lighter gate. A public business rule, browser privacy boundary or deployment workflow needs deeper review because someone will rely on it later.

Tests turn decisions into evidence

Tests are not proof that a system is perfect. They are executable records of the decisions that matter.

For Formatloom, the evidence includes parser and worker contracts, fidelity warnings, Rails route boundaries, browser workflows, keyboard access, responsive layouts and network checks. For Max Bid, it includes the calculation contract, exact monetary behaviour, localization, DOM behaviour, end-to-end scenarios, accessibility, artifact inspection and parity with the Rails reference.

The test level should match the risk:

unit and contract tests protect formulas, parsers and message shapes;
integration tests protect boundaries between the application parts;
browser tests protect observable behaviour, navigation and accessibility;
build, lint and static analysis checks protect the release artifact;
manual running-product checks cover what automated tests cannot see reliably.

AI can propose tests. It cannot decide that a passing test covers the right risk without understanding the system.

Security checks are part of the change

Security review starts with the product boundary. In Formatloom, the worker must not send document content, analytics is allowlisted and the content security policy restricts destinations. In Max Bid, browser values stay in memory, user-controlled values are rendered as text, languages and currencies are allowlisted, and the generated artifact is checked for secrets and unsafe content.

The Rails reference adds controls such as CSRF protection, HTTPS enforcement, strong parameters and parameter filtering. Brakeman and dependency auditing cover risks that a browser test cannot cover. These checks are not optional decorations added after AI has produced the code. They are acceptance conditions for the implementation.

Inspect the running product

A diff can look correct while the product is wrong. I inspect the running application after the automated checks: routes, copy, focus order, responsive layout, loading and error states, generated output and browser network requests.

For a browser-local tool, the Network panel matters. For a static calculator, direct navigation, localized formatting and the generated artifact matter. For either product, the question is whether the running system still matches the boundary written in the specification.

This step also catches quality problems that are difficult to express in a prompt: a warning that is technically present but unreadable, a stale result that remains on screen, a link that points to the wrong language or a release asset that contains information it should not contain.

Release and rollback

Release is another evidence gate. The change must pass the relevant tests, build the production artifact, inspect that artifact and publish the exact commit that passed CI. The deployment workflow should make its permissions and trigger conditions explicit.

Rollback belongs in the design before the first failure. A release record should identify the previous approved artifact, the trigger for rollback, the command or action that restores it and the smoke check that confirms recovery.

The Max Bid release record is useful precisely because it distinguishes passed local automated gates from pending native-browser, manual accessibility and production rollback checks. I do not turn a documented procedure into a claim that a rollback was executed. If the evidence is pending, it stays pending.

What AI use proves — and what it does not

AI-assisted work can show that I know how to bound a tool, compare options, inspect changes and connect implementation to evidence. It does not prove autonomous development, a specific number of interactions, a percentage of generated code or deep expertise in a domain that the project did not exercise.

The responsibility remains simple: understand the change, make the risk visible, run the right checks and own the result that reaches users.