Prompt injection
Why content the agent reads can hijack it, and what a real boundary looks like.
Read the guide →By task
Code and agents
The difference between a useful coding assistant and an expensive mess is almost always whether the task had a defined boundary and a defined finish line.
“Make it better” is an unbounded budget
Ask a capable model to improve some code and it will. It will also refactor adjacent files, swap a library, modernise a pattern you deliberately kept, and helpfully remove the workaround that was load-bearing. None of that is disobedience. You authorised it by leaving the boundary undefined.
State the symptom, not the fix
Describe what happens, what you expected, and when it started. Prescribing the fix removes the diagnosis you actually wanted.
Fence the blast radius
Name the files or directories that may change, and say explicitly what must not be touched: dependencies, public interfaces, the migration, the rate limiter.
Define done as something testable
“Existing auth tests pass plus one new regression test” is a finish line. “It works” is not.
Require diagnosis before change
Ask for the root cause first, and to stop for confirmation if the cause turns out to be somewhere else.
Ask for the actual test output
Not a claim that tests pass. The output. This one instruction catches a large share of confident nonsense.
Diagnose why [symptom] happens after [what changed].
Read the relevant tests and logs before proposing anything.
Change only files under [path]. Do not add or upgrade dependencies. Do not modify the public API.
Preserve [the thing that must survive].
Done when: existing tests pass, plus one new test that fails on the current code and passes after the fix.
Report the root cause, the files you changed, and the real test output. If the cause is outside the allowed path, stop and tell me instead of working around it.If you are not a developer
Building working software without being able to read it is now genuinely possible, and it has a specific failure curve. Everything goes well until something breaks in a way the assistant cannot fix from the error message alone. At that point there is no fallback, because debugging requires the understanding that was skipped.
Two habits make this much safer. Keep the project in version control from the first day, so you can always return to the last state that worked. And treat anything involving accounts, payments or personal data as the point where you get a human review, because the security problems in generated code are not visible from the outside.
Ask for an explanation you can check. “Explain what this does in plain language, and tell me what would break if it went wrong” gives you a way to sanity-check work you cannot read. It is not a substitute for review, but it surfaces a surprising number of bad assumptions.
Agents raise the stakes because they act
An agent that reads files, runs commands and calls services is no longer producing a suggestion you approve. It is taking actions. Two things follow.
First, everything it reads is potentially hostile. A web page, an issue comment or a dependency's README can contain instructions written for the model. Prompt wording is not a defence against this; permissions and approval steps are.
Second, connecting a tool hands over your existing access rather than granting new powers. That is reassuring until you consider how much your own account can reach. Prefer read-only, keep the tool list short, and require confirmation before anything irreversible.
Connectors and MCP
What connecting an assistant to your systems actually does.
Read the guide →Reasoning models
Effort settings, and why more thinking does not fix an ambiguous brief.
Read the guide →