Skip to main content

EST. 2004

Back

How I Actually Use AI When I Code

Jun 18, 2024

i used inline autocomplete for a while. it helped sometimes. mostly it interrupted.

when you're working through an architectural decision, a constant stream of suggestions that may or may not be right creates more churn than value. you spend mental energy evaluating suggestions instead of thinking about the problem.

what changed things for me was shifting from token-level hints to task-level execution.

instead of asking AI to complete the next line, i describe a bounded task with explicit constraints and review the diff. "refactor this module to use this interface, no behavior changes, existing tests must pass." the output is a reviewable unit of work. that's a different kind of collaboration.

concrete, constrained tasks are where it consistently delivers.

scaffolding a new module from an existing pattern. repetitive refactors with clear rules. debugging against logs. generating multiple implementations of the same interface to compare tradeoffs.

vague goals produce confident noise faster. "improve this" without constraints yields changes that look plausible and may be subtly wrong in ways that are expensive to catch.

i still own correctness, scope, and maintainability. AI doesn't know why the system is shaped the way it is, what failed before, or what constraints exist outside the context window. plausible-but-wrong changes slip through when the reviewer doesn't understand the system well enough to catch them.

AI amplifies someone who understands what they're building. without that foundation, output volume increases without a corresponding increase in output quality.

the actual loop: define the intent and constraints clearly, describe a bounded task, review the output against architecture and known failure modes, validate before merging. same engineering standards. just faster first passes.