How I Use AI to Make Software Easier to Own

The expensive part of a software change extends beyond writing it. Someone has to understand the result, verify its behavior, operate it, and eventually change it again.

That is the constraint behind how I use AI.

I want help moving work forward. I also want the resulting system to remain understandable enough that another engineer can own it. Those goals belong together. Producing changes faster has limited value if each change increases the cost of everything that follows.

My workflow includes implementation, investigation, review, and cleanup. A particularly useful part comes after a solution exists, when I ask whether we needed all of it.

Make the implementation defend its complexity

In a recent review, I asked whether a large pull request contained logic we could remove, including logic built around assumptions or hard-coded values.

That question changes the review.

Instead of evaluating each function only for correctness, it asks whether the behavior deserves to exist. A helper can be well written and unnecessary. A test can pass while protecting a mechanism the business never required.

The difficult part is distinguishing that machinery from complexity that carries real responsibility.

Cancellation handling, for example, can protect resource limits. Removing it may simplify a function while allowing work to outlive the request that started it. A useful review has to follow that consequence through the system.

The standard I want is simple: explain what the code protects, what changes if we remove it, and what evidence supports the decision.

Fewer lines are valuable when they leave us with fewer concepts to maintain while preserving the behavior we need.

Ask for disagreement, then inspect the reasoning

One instruction I use is: do these refactors if you agree.

That gives the assistant a proposed direction and an obligation to evaluate it. I want it to identify an incorrect premise before implementing a polished version of that premise.

However, asking for disagreement is only an invitation. The response still needs evidence.

A useful objection points to an actual dependency, caller, business rule, or failure path. It explains why the proposed change affects something I care about. A generic warning about scalability is much less useful than identifying the exact place a concurrency limit would stop working.

The same standard applies when the assistant agrees. Agreement should come with enough reasoning to inspect.

I remain responsible for deciding whether the explanation matches the business and the system.

Put recurring context somewhere durable

My repository instructions describe the project's purpose, its authoritative documents, the conventions to preserve, and the checks expected before handing work back.

For Software Survivor, that includes an editorial constraint: teach engineering judgment. Explain why a decision was made before explaining its implementation.

Those instructions help define what a successful change looks like. Without them, an assistant might produce a technically valid article that weakens the site's positioning, or duplicate information that already has an authoritative home.

The same principle applies to code. An assistant needs to know which source owns a business rule, where integration behavior belongs, and which generated files require inspection after a build.

Maintaining that context takes work. Instructions can become stale or contradictory. I want a small amount of authoritative guidance that reduces repeated explanation and also helps the next engineer understand the project.

Define completion through evidence

My instructions ask for an explicit account of what changed, what was checked, and what remains unverified.

Those distinctions matter. A successful build establishes different facts from a behavior test. A mocked integration test establishes different facts from a live provider check. Neither should silently stand in for the other.

I also want the final diff inspected. Completing the requested edit can produce unrelated formatting changes or generated artifacts. Those changes still need a reason to belong.

This makes the handoff reviewable. I can assess the result, understand the limits of the evidence, and decide what should happen next. The production checklist for AI-assisted software covers the broader release questions that remain after an individual change is complete.

Keep the next engineer in the decision

There is a cost to this workflow. Reviewing assumptions, maintaining context, and checking results take time. Repeated review can also generate unnecessary work if every pass searches for something new to change.

A review needs a stopping point: the required behavior is clear, the checks support it, and the remaining complexity has a reason to exist.

That is the outcome I want from AI assistance.

I can delegate investigation and implementation while continuing to own the constraints and tradeoffs. I can ask for alternatives, challenge a proposed fix, and request another pass focused on what can disappear.

The question I keep returning to is whether the next engineer will be able to understand and safely change what we leave behind.

AI is useful to me when it helps make that answer yes.