Human Involvement in AI-Assisted Code
May 3, 2025🎧 Listen to the original 2025 recording: Play the original recording
The recording preserves the article as originally published. The written version below has been revised, so its wording and structure differ from the audio.
AI Is Part of the Engineering Workflow
AI can plan a feature, trace unfamiliar code, generate an implementation, write tests, investigate failures, and revise its own work. It gives founders and engineering teams useful leverage, and it belongs in modern software development.
Human involvement does not mean a person must type every line or reject generated code. It means a person or team remains accountable for defining the intended behavior, providing the missing context, evaluating the change, and operating the result after release.
Requirements Come Before Implementation
A coding agent can implement a clear request quickly. It can also implement a plausible interpretation of an unclear request just as quickly.
Before asking whether the code looks good, someone has to establish what “good” means: which user is affected, which business rule applies, what data is authoritative, what failure behavior is acceptable, and what is outside the change. Those decisions come from the product and its operating environment, not from syntax alone.
Context Is an Input, Not an Afterthought
Useful context can live in API schemas, tests, architecture notes, representative data, logs, issue history, and the experience of people who know why the system behaves as it does. An agent cannot account for a constraint it cannot see.
This is one reason maintainable code matters. Clear boundaries, stable contracts, and documented decisions help an AI agent and a new human teammate work more safely. A confusing codebase does not become coherent merely because changes can be generated faster.
Keep the System Understandable
Generated changes can introduce duplicated views, overlapping services, redundant state, or abstractions that solve the same problem in different ways. Human-written changes can do that too.
The response is not to avoid AI. It is to reconcile each meaningful change with the existing architecture: keep what belongs, remove what does not, and make ownership clear enough that another person can follow it later.
Review Is More Than Reading a Diff
A clean-looking diff is useful evidence, but it cannot prove that the affected workflow behaves correctly. Review connects the implementation to requirements, contracts, state transitions, permissions, and failure paths.
AI can assist with this work. It can identify callers, compare interfaces, draft test cases, explain a suspicious branch, and look for similar logic elsewhere. The reviewer still decides which evidence is sufficient for the risk of the change.
For a detailed review sequence, see Reviewing AI-Assisted Code Before It Ships.
A Bounded Example: Identity That Changes at Runtime
One debugging problem I encountered involved a SwiftUI message flow backed by Firebase. A record's document identifier was optional while the object was decoded and became available after the asynchronous fetch. That identifier also participated in the row's identity.
The screen could render successfully, yet navigation selection could reset when the fetched identifier changed the identity SwiftUI was tracking. The relevant question was not merely whether the row compiled or displayed. It was whether identity remained stable across decoding, fetching, rendering, and navigation.
This example is deliberately narrow. It does not prove that AI cannot debug state-management problems. AI can help trace the data flow and propose fixes. It shows why runtime sequencing and framework behavior must be part of the review, and why the person approving the change needs to verify the complete flow rather than accept a locally plausible patch.
The Runtime Is Part of the Evidence
Static analysis, tests, and code review answer important questions. The running system answers others: whether authentication survives a refresh, whether data converges after reconnecting, whether retries duplicate an action, whether a slow response changes state in the wrong order, and whether logs expose enough information to diagnose a failure.
Verification should match the consequence. A copy change may need a quick rendered check. A permissions change may need role-based integration tests and a controlled rollout. A migration may need backups, rehearsal, metrics, and a rollback plan.
Maintenance Is Part of Delivery
Shipping is not the end of the decision. Dependencies change, customers find edge cases, business rules evolve, and production data reveals assumptions that were invisible during development.
Someone must know how to interpret those signals, decide what to change, and preserve the parts of the system that should remain stable. AI can make that person faster by searching history, comparing approaches, writing diagnostics, and implementing the next change. It does not become the owner of the customer or business outcome.
A Practical AI-Assisted Delivery Checklist
- Intent: State the user outcome, constraints, and explicit non-goals.
- Context: Supply the relevant contracts, architecture, examples, and operating rules.
- Change review: Inspect the actual diff and identify assumptions that affect other parts of the system.
- Verification: Run tests and exercise the affected workflow in the environment appropriate to its risk.
- Operations: Confirm logging, monitoring, recovery, and rollback behavior where they matter.
- Maintenance: Record consequential decisions and assign an owner for future changes.
The checklist is intentionally concise. A low-risk internal tool and a regulated production workflow need different levels of evidence, but both benefit from making responsibility explicit.
Human Involvement Means Outcome Ownership
The useful question is not what percentage of the code was generated. It is who can explain the intended behavior, who reviewed the consequential decisions, what evidence supports the release, and who will respond when reality differs from the plan.
A founder may own that responsibility. An internal team may share it. An outside engineer may own a clearly bounded system or review. The right arrangement depends on the product and its risk; it does not depend on a degree, job title, or who typed each line.
AI is extraordinarily useful inside this model. It increases the reach of the person who owns the outcome. Human involvement is what connects that leverage to requirements, runtime evidence, maintenance, and responsibility for the product people actually use.
Have questions? Drop me a message, and let’s chat.