{"slug": "ai-pro-tips", "title": "AI Pro Tips", "summary": "A developer's guide to using AI agents effectively emphasizes treating them as agents rather than chatbots, focusing on spec-driven planning, executable acceptance criteria, and setting budgets and finish lines. The author advises front-loading relevant context, closing loops with reality through measurement, and maintaining personal comprehension of generated code. Prompts and project guidance should be versioned in repositories like AGENTS.md.", "body_md": "# AI Pro Tips\n\nI’ve posted enough scattered AI tips on Slack that it’s time to put them in one place. These are operating principles, not commandments. Nothing applies everywhere; don’t blindly follow any of this.\n\n## Use an agent, not a chatbot\n\nFor any non-trivial task I use a CLI agent. The important distinction isn’t the UI — it’s that the model can inspect the source material, use tools, execute work, observe the result and continue. I’ve used the same pattern for code, 100K+ document extraction, electronics design and paperwork: provide the primary sources and ask for a concrete artefact, not an answer about how one might produce it. Prefer APIs and CLIs; use computer control only where no programmatic interface exists.\n\n## Spend most of the effort before code generation\n\nSpec-driven planning and explicit clarification are non-negotiable. Define the problem, constraints, architecture, invariants and edge cases first. Break large plans down. Ambiguity at the start turns into confident, expensive nonsense later.\n\nFor agentic coding loops, make the acceptance criteria executable. I’ve had good results with a tiny, human-readable E2E language:\n\n```\nbegin test 'source reconnects'\nblock source network\nwait for log 'source_heartbeat_timeout' with timeout 10s\nunblock source network\nwait for log 'source_connected' with timeout 10s\nensure correct content for table 'xyz'\nend test\n```\n\nThe agent can build however it likes; the loop only passes when the contract passes. Unit tests should similarly come from documented behaviour, not from copying the current implementation and enshrining its bugs.\n\n## Front-load relevant context\n\nProvide as much relevant data as possible before an unattended workflow starts. Once an agent commits to a wrong hypothesis on insufficient data, it’s very bad at backtracking and “forgetting” its earlier decision. This does not mean dumping an unstructured landfill into the context window. Label the data, preserve its chronology and state what is authoritative.\n\nCode is the source of truth for system behaviour. Let the model read it. Use docs to state contracts, intent and surprising constraints; use old discussions as pointers, not truth.\n\n## Give the run a budget and a finish line\n\nFrontier agents no longer need elaborate Ralph loops just to keep working. A two-line prompt can now run for 12 hours. The problem has inverted: you need to tell the thing when to stop.\n\nSet cost, complexity and time constraints alongside a measurable outcome. For example: “Get the core import flow working end to end by 10:30am. Keep the change under 500 lines, spend no more than $20, and stop for approval if that requires changing the schema.” Realistic constraints produce simpler, more creative solutions and prevent an agent from polishing the universe.\n\n## Close the loop with reality\n\nNever ask an agent to “optimise” and accept prettier code as evidence. Give it a\nmeasurement loop: profile, change, rerun, compare. For ORM work, have it run\n`EXPLAIN`\n\nagainst a representative database and iterate on query\ncost. I watched an agent replace a disastrous `.distinct()`\n\nchain\nwith the `EXISTS`\n\nsubquery I would have written by hand — but only\nafter it could see the query plan.\n\n## Do not outsource comprehension\n\nDon’t advance past generated code until you can explain its purpose, trade-offs and interactions. Use agents to accelerate understanding, not bypass it. Personal comprehension and architectural ownership are what allow the next high-leverage decision; hidden code you don’t understand is merely debt with a faster creation rate.\n\nAlso, don’t get emotionally attached to generated work. If the result is suboptimal, throw it away, refine the prompt and retry. The marginal cost of a fresh attempt is now tiny; the maintenance cost of keeping bad code is not.\n\n## Make prompts part of the repository\n\nPersistent project guidance belongs next to the domain it governs. Check\nreview rules and engineering constraints into `AGENTS.md`\n\n, put\npackage-specific guidance in subdirectories and allow local overrides where\nappropriate. Versioned prompts are reviewable; prompts living in everyone’s\nhome directory become folklore.\n\nTurn repeated workflows into small skills, but only after several real loops work. “Let’s throw AI at it” is not an architecture. Build the working cases, extract what they share, then standardise. Keep the skills concise and delete ones that stop earning their keep. Sometimes a simple prompt does 95% of the job; don’t reach for a complex AST checker when a cheap advisory check is all you need.\n\n## Assume review is the bottleneck\n\nAs code generation gets cheaper, review gets more expensive. Keep AI-authored PRs surgical, incremental and easy to inspect. Self-review in a clean context, run an adversarial review, rewrite the commit history, resolve findings and pass CI before asking a human to look.\n\nLLMs are non-deterministic, so one clean report means little. Run the same review rules locally with clean-context reviewers, then use the PR bot as the last line of defence — not a substitute for your own quality check. A good red-team reviewer reconstructs intent first, identifies invariants and trust boundaries, then reports cause, failure mode, reproduction and the smallest safe fix, severity ordered.\n\n## Security boundaries must be structural\n\nTurn on sandboxing. Use least privilege. Keep network and sensitive filesystem access off unless the task needs them. Never leave an unattended agent with broad access to production, customer data or your “god power” accounts. Agents still hallucinate, follow prompt injection and take erratic actions.\n\nPrompts are not access controls. “Only read these tables” is not a security boundary. For browser agents, I issue a short-lived login URL that creates a session with only the required permissions, then require all mutations through the audited UI — no arbitrary POSTs. If the agent interacts with a human, disclose that it is an AI before the interaction starts.\n\n## Format data for the model, not the tokenizer\n\nHard no on removing repeated keys from large inputs merely to save tokens. LLMs\nstill struggle with dense, unlabeled data such as tables. Repeat the keys and\nmake relationships explicit. If compactness matters, compress the\n*output*: it’s usually the larger side of the bill, and APIs can enforce\na precise output schema without the model having seen that format during\ntraining.\n\n## Make long-running agents observable and steerable\n\nTreat an agent like any other long-running job. Notify yourself when it blocks\nfor input — Codex supports `notify = [\"notify-codex\"]`\n\nin\n`~/.codex/config.toml`\n\n— ask a side-chat for a status report, and\ninterrupt only when the current path is wrong. In Codex CLI, Enter steers after\nthe current step, Enter+Escape interrupts immediately, and Tab queues\ninstructions for after the current turn. Queueing “run the tests, then review\nthe diff” is considerably better than hovering over the terminal like a worried\nparent.\n\n## Force useful disagreement\n\nDon’t ask a model for “the answer” to a disputed question. First ask it to steelman each position independently, including the premises, evidence, rebuttals and conditions under which each would be correct. For cross-domain problems, run separate security, performance, product and operations reviewers, then give their outputs to a final synthesis pass. Parallelise only independent work; correlated agents produce five copies of the same mistake.\n\nWhen an explanation is too abstract, iteratively lower the assumed knowledge level until the model uses concrete examples. When a recommendation is too generic, state your must-haves, exclusions, acceptable exceptions and decision rules. Prompting is a control loop, not a magic sentence.\n\n## Make the agent learn you\n\nOne useful meta-prompt is:\n\n```\nGo through my conversation history — just the threads, not skills or global\nprompts — and distil the coding, engineering and design principles I repeatedly\nenforce. List them concisely and cite the conversations they came from.\n```\n\nReview the result, remove accidental preferences, then turn the durable parts into project guidance. Also add this small rule to any coding agent:\n\n```\nIf you see a change you made suddenly change or disappear, assume the user\nchanged it. Do not put it back without asking.\n```\n\nThat one sentence prevents a surprisingly common form of artificial stubbornness.", "url": "https://wpnews.pro/news/ai-pro-tips", "canonical_source": "https://blog.oxplot.com/ai-pro-tips/", "published_at": "2026-08-02 12:27:31+00:00", "updated_at": "2026-08-16 13:41:39.514911+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-agents", "developer-tools"], "entities": ["Slack", "CLI agent"], "alternates": {"html": "https://wpnews.pro/news/ai-pro-tips", "markdown": "https://wpnews.pro/news/ai-pro-tips.md", "text": "https://wpnews.pro/news/ai-pro-tips.txt", "jsonld": "https://wpnews.pro/news/ai-pro-tips.jsonld"}}