The tool can write code. You still own the outcome.
AI can scaffold a feature, trace a bug, explain an unfamiliar repository, and produce a suspiciously confident migration plan before your coffee has cooled down.
That is useful. It is also exactly why the mental model matters.
Treating AI like a teammate encourages us to assign it intent, judgment, and accountability that it does not have. Treating it like autocomplete undersells what it can do. A better model sits somewhere else entirely:
AI is a power tool for manipulating information.
A power tool can make a skilled person dramatically faster. It can also help them make a much larger mistake in much less time. The difference is not the tool. It is the workflow around it.
What AI is genuinely good at
The strongest use cases are not magic. They are compressed, accelerated versions of work we already understand:
- Exploration — mapping an unfamiliar codebase, finding call sites, and identifying likely dependencies.
- Translation — moving logic between languages, frameworks, schemas, or levels of abstraction.
- Mechanical work — repetitive refactors, test cases, documentation, formatting, and data transformations.
- Option generation — producing several reasonable approaches before a human chooses the trade-off.
- Review support — spotting missing edge cases, inconsistent naming, or assumptions worth challenging.
The common thread is simple: these tasks have outputs we can inspect.
AI becomes dangerous when we use fluent output as a substitute for evidence. A plausible explanation is not a traced data flow. A clean diff is not a correct diff. A passing unit test is not proof that the feature works in the browser.
Prompting is not the hard part
There is an endless market for secret prompt formulas. Most of it is cargo cult with better punctuation.
The useful part of a prompt is not a magic phrase. It is a clear contract:
Context:
- Where are we working?
- What existing behavior matters?
Goal:
- What concrete outcome should exist when the work is finished?
Constraints:
- What must not change?
- Which files, systems, or people are out of scope?
Acceptance:
- How will we prove the result works?This structure works because it forces us to define the job before delegating it. It also gives the model something better than vibes to optimize for.
If you cannot describe the acceptance criteria, you are not ready to automate the implementation.
Use a trust ladder
Do not jump from “the model has seen the repository” to “the model may rewrite the repository.” Increase autonomy as evidence accumulates.
1. Start with read-only exploration
Ask it to locate the relevant code, describe the current behavior, and identify uncertainty. A useful answer should point to concrete files and explain how information moves through the system.
If the diagnosis is wrong, stop there. You have lost minutes, not a release.
2. Ask for the smallest coherent change
Large rewrites hide mistakes. Small diffs expose them.
The best change is not always the one with the fewest lines, but it should have the narrowest blast radius that still solves the actual problem. Make the agent explain why each touched file belongs in scope.
3. Verify at the same level as the risk
A formatter change may need a configuration check. A component change needs a browser. A payment change needs considerably more than “tests passed.”
Match verification to the failure mode:
- Run type checks and tests.
- Exercise the real UI flow.
- Inspect network requests and persisted data.
- Test empty, slow, invalid, and interrupted states.
- Re-run performance and accessibility checks when the rendering path changes.
Verification is not a victory lap after implementation. It is part of implementation.
4. Keep the evidence
Record the command, result, screenshot, benchmark, or reproduction that proves the change. “The agent said it worked” is not evidence. Neither is “looks fine on my machine” wearing a robot costume.
Review AI code like code from a very fast stranger
Generated code deserves neither automatic distrust nor automatic approval. Review it with the same questions you would ask in a serious pull request:
- Does this solve the root cause or only hide the symptom?
- Which assumptions are new?
- What happens when input is missing, stale, duplicated, or malicious?
- Did the change silently broaden permissions or data access?
- Is there a simpler native feature already available?
- Are failures observable, recoverable, and understandable?
- Would a future developer know why this exists?
Pay special attention to code that is boring to read. Authentication glue, cache invalidation, date handling, retry logic, and database migrations are where confident little assumptions go to become expensive incidents.
Do not outsource judgment
Some decisions should remain explicitly human, even when AI contributes analysis.
Product intent
A model can suggest what users might want. It cannot decide whom the product should serve or which compromise matches your values.
Architecture
AI can compare patterns, but architecture is a set of long-lived trade-offs inside a specific organization. The “best” abstraction depends on team size, operational maturity, deadlines, and the cost of being wrong.
Security and privacy
Never assume a model knows what data it is allowed to see, store, or transmit. Scope access deliberately. Treat prompts, logs, generated files, and tool permissions as part of the security boundary.
Accountability
The model cannot be on call. It cannot explain the decision to a customer, regulator, or exhausted teammate during an incident. Whoever approves the change owns it.
Agent permissions are part of your API design
Once an AI can use tools, permissions matter more than personality.
A sensible default is:
- Read broadly enough to understand the task.
- Write only inside the declared workspace.
- Require explicit approval for destructive or external actions.
- Resolve exact targets before deleting, publishing, or sending anything.
- Prefer reversible changes and small commits.
An agent with vague instructions and broad permissions is not autonomous. It is unsupervised.
The practical loop
A reliable AI-assisted workflow is deliberately unromantic:
- Define the outcome.
- Let the tool inspect the real system.
- Challenge its diagnosis.
- Implement the smallest coherent change.
- Verify the actual user path.
- Review the diff and evidence.
- Commit only what belongs together.
That loop is slower than pressing “accept all” for thirty seconds. It is much faster than debugging thirty accepted assumptions next week.
The point is leverage, not replacement
Good AI usage does not remove engineering. It removes some of the friction around engineering.
The payoff is not that we stop thinking. It is that we spend less time moving syntax around and more time deciding what should exist, where the risks are, and how we know the result is real.
Use the fast machine. Keep the slow judgment.
