Iterate With AI. Keep Your Engineering Judgment.
AI makes it easier to try an implementation. The useful skill is deciding what to test, recognizing what the result actually shows, and knowing when to discard it.
This website is a small example. I used AI to iterate on the layout, navigation, and copy. An implementation could appear quickly, but the next decision still required looking at the page: was the spacing right, did the navigation stay consistent, and did the text accurately describe my work?
A first version and a finished result are different milestones. The work included repeated revisions. Treating the first render as the whole project would hide the judgment and checking that made it useful.
Shorten the loop around a specific question
I prefer a bounded loop: describe the problem and constraints, try one change, inspect the result, and keep or reject it. On a website, the question might be whether a heading still fits on a narrow screen. In a GPU kernel, it might be whether a change reduces execution time without changing the output.
The second question needs different evidence from the first. A convincing explanation or plausible implementation cannot settle it. I need a reference, a controlled comparison, and a check that the measurement exercises the path I changed.
The double-buffered kernel investigation makes this concrete. Prefetching was present in the source, but early variants did not produce the intended overlap. Inspecting the generated instructions explained why. The idea had to survive what the compiler and hardware actually did.
Trying something can be cheap. Being wrong can be expensive.
Discarding a local CSS experiment is usually easy. Recovering from a production migration, a permission change, or a numerical error that contaminates later measurements can be much harder. Faster generation does not make those consequences disappear.
I want the experiment to be reversible where possible and its acceptance criteria to be clear before I run it. A saved baseline, an isolated environment, or a targeted regression check can make a fast iteration useful instead of merely busy.
AI assistance can also make it easy to produce more changes than I can evaluate carefully. When that happens, I need a smaller experiment. More candidate code is only valuable if I can distinguish improvement from noise.
Expertise gives the feedback loop its direction
On a visual prototype, recognizing a better result may be enough to choose the next step. In performance and security work, failures can remain invisible while the demo looks fine. Understanding the system helps me choose measurements that could prove my preferred explanation wrong.
That is why I do not see engineering knowledge becoming optional. It determines which constraints I state, which tests I trust, and which output I reject. The state-history bug in the inference project is a reminder that even a passing test can answer the wrong question.
I want to keep the speed AI gives me while retaining ownership of the result. Build a smaller experiment. Inspect it closely. Record what changed. Repeat. You can outsource your thinking, but you cannot outsource your understanding.