The colleague
The most useful mental shift I've found is treating the agent as a colleague — specifically, a fast, knowledgeable, infinitely patient junior senior who has only seen what you've shown them and forgets between sessions.
Once you internalize that, a lot of what looks like prompt engineering starts looking like the things you'd already do for a teammate: onboard them with the right docs, brief them before each task, pair through ambiguity, review their work before merging.
Why is this list slow when typing?
I'd need more to go on. Slow lists during typing usually trace back to re-renders, large unfiltered datasets, or per-render allocations — but without seeing the code, I'd just be guessing.
Same task, same model — what changes is how much the colleague was set up to succeed. The asymmetry between what you can see and what they can see is where most of the skill lives.
Skills, project rules, conventions, examples — the same materials a new hire gets. What to use, what not to, where things live, what good looks like in this codebase.
Most of this lives in a CLAUDE.md or .cursorrules at the project root. It's the highest-yield thing you can write in a codebase, because the agent reads it on every task. A useful rules file says things like:
- Use Tailwind classes; don't inline styles.
- Tests go next to source files, not in a
__tests__/folder. - No
any. Use the narrow types fromlib/types.ts. - When unsure about UI, link to a similar component in
components/.
The same paragraph that gets a new hire from "lost" to "useful" in a week does the same for the agent.
Onboarding is general. Briefing is per-task — what this specific piece of work is, which files matter, what good looks like, what to avoid.
The mistake is starting cold every time: "fix the auth bug." A colleague would ask "which auth bug? where? what changed recently?" and you'd answer. Include the answers up front.
The longer the task, the more the briefing pays back. Five extra minutes of setup saves 30 minutes of clarifying turns later.
The output is a proposal. Same as a colleague's PR — not the final answer, your job to evaluate. Read the diff. Run the code. Check the cases you'd check on a junior's PR.
Don't accept what you can't verify. If you can't tell whether the result is right, that's a signal that the task needed to be smaller, or that the agent needed more context.
The "rubber-stamp" failure mode — clicking accept on long diffs — is where mistakes compound. Treat agent output the way you'd treat a teammate's: assume something subtle is probably wrong, and look for it before merging.