Cole-Medin

Cole Medin explains his revised AI software factory in this 19-minute talk on his channel. Agents handle implementation; people own the release plan and final acceptance. Why he changed the design His original “dark factory” took a broad application brief and aimed to ship directly to production. Better coding models still make assumptions about what customers want and how a codebase should evolve. He keeps people involved in product decisions and maintenance while agents work through a bounded release. Plan one release Define a proof of concept for a new app, or a small bundle of changes for an existing one. Medin targets roughly 10–20 tickets, with explicit requirements and exclusions. Create holdout scenarios: acceptance tests hidden from the implementing agent to discourage coding only for visible tests. Map dependencies, then label tickets so independent work can run in parallel. Choose human approval points by risk: regulated changes may need ticket and pull-request review. Run the build loop Each run claims one issue and produces a pull request, a proposed code change. Route simple tasks through a fast workflow; reserve deeper iteration for complex work. Validate behavior by using the app: click buttons, enter text, and check the outcome. Review code separately for simplicity, maintainability, and sound implementation. Send failures back for repair, with retry limits; merge into staging only after review and automated checks pass. Supervise the factory A manager agent checks the whole queue every 2–3 hours for stuck work and changed dependencies. It can realign tasks, rescue a run, or ask a person to intervene. Protect mission.md, engineering.md, and global rules from factory edits so agents cannot rewrite their own boundaries. Use different models for different steps. Medin reports hundreds of weekly runs within rate limits, without a measured total-cost breakdown. Test the release in staging People test the assembled release in staging, a pre-production environment, to check whether it matches their intent. Turn feedback into new issues; the same factory implements the corrections. Repeat until the release is ready, then approve production and plan the next batch. “We don’t want the agent to assume our intent even if it is a very capable model.” — Cole Medin, 6:24 ...

Cole Medin walks through his personal AI content engine and a free skill for building a customized version in about 14 minutes. Filter before asking a model Collect from RSS, Reddit, YouTube, Hacker News, GitHub, research papers, and product changelogs. Store seen items centrally so repeat announcements do not trigger repeat model calls. Remove stale items and other obvious rejects with ordinary code before spending tokens. Clean headers, footers, and irrelevant fields out of source text before model processing. Use a cascade, not one expensive judgment per item Jev provides the first model-based relevance decisions; an LLM handles remaining ambiguity and digest preparation. Ask whether an item is relevant, genuinely new and concrete, or merely a toy demonstration. Medin says removing the LLM altogether made his filtering worse: both useful omissions and irrelevant inclusions increased. His example run processed 864 posts for about $0.03 in Jev calls and $0.42 in Claude Haiku calls—not a complete bill for collection, hosting, or maintenance. Engagement thresholds are his shortcut, not a quality guarantee; they can bury useful niche work. Build around your interests The build-signal-engine skill interviews you about interests, sources, access methods, and information you previously missed. Start with one working source end to end, then add connectors, filters, decisions, digest formatting, and scheduling in tested stages. Apify is Medin’s collection option, not a requirement; the description includes a referral link. Keep source definitions in one JSON configuration and preferences in a readable profile. Editing that profile does not change the running pipeline automatically: ask the coding agent to implement the differences. “We should truly understand how it’s working.” — Cole Medin, 2:24 ...

Cole Medin uses reverse engineering and his own software-factory experiments to explain which skills still matter as agents improve (15:58). Code generation is not the whole job Delegate implementation, but stay responsible for planning, clarifying intent, and validating the result. A “meat proxy” forwards a ticket to an agent and pastes its answer back without adding judgment. Making colleagues review a giant “Claude said” response transfers your work rather than completing it. Why reverse engineering is an unusually favorable task Reverse Engineer Anything starts with a working application: the reference already expresses much of the target behavior. New products usually begin with incomplete ideas, not a finished target that an agent can compare against. Supply concrete examples where possible; otherwise build the missing reference through questions, requirements, and acceptance criteria. A successful reconstruction is not proof that all engineering is solved—or that automated validation is perfectly reliable. The 2D-to-3D example Medin’s autonomous factory produced a working 2D game, but his intended visual direction was 3D. Several attempts with a powerful model and elaborate workflow still missed that intent. A Zelda visual reference plus repeated side-by-side comparisons brought the prototype closer to his goal. He describes an early proof of concept with visible glitches, not a release-ready game. The “twice as good” test Ask: if the next model were twice as capable, would this skill matter more or less? His lower-priority examples: prompt tricks, hand-built reasoning loops, and enormous generic rule files. His higher-priority examples: planning, validation, references, and the tools and workflows surrounding an agent—its “harness.” Turn mistakes into improvements to that workflow; do not treat stronger models as a substitute for product judgment. “Large language models can’t read your mind.” ...

Cole Medin walks through four decision-model uses in his AI second brain, on his channel (13 minutes). The video is sponsored by OpenRouter; his cost and speed figures are his own reported experience, not independent benchmarks. Why a decision model? Jev takes a state and multiple-choice questions, answering them in parallel instead of generating prose. An LLM still drafts the actual email or performs nuanced editorial review. Cole says it is faster and cheaper than using an LLM for every small decision. His transcript says 38,000 calls and 55.3 million input tokens in a week cost about $21; the video description instead says $2, so treat the price claim as inconsistent. Four jobs in the second brain Email triage: decide whether a message merits a drafted reply; skip low-priority mail. Cole reviews and sends replies himself rather than letting the system send automatically. Prompt-injection screening: classify incoming email for requests to forward data, change memory or settings, escape instruction boundaries, or impersonate the owner. His demo labels mail as draft, skip, or attack; a separate LLM used to do the screening. News filtering: first pass over RSS, YouTube, and Reddit items; categorize and score relevance. Send borderline audience-fit questions to a smaller LLM with broader context. Cole found Jev alone insufficient for that final judgment. Deduplication: compare incoming facts with existing entity notes before paying an LLM to update the knowledge base. He favors false negatives over silently discarding useful new information. Where not to overclaim He shows probabilities and thresholding, but supplies no independently validated attack-detection or deduplication benchmark in this talk. A classifier is not a complete security boundary for untrusted email. The useful pattern is cheap, narrow decisions first; richer contextual reasoning only where needed. For content filtering, he explicitly keeps the LLM in the loop. “Jev is great at making those initial calls, what is just noise that we can easily skip.” — ~8:53 ...

Cole Medin presents four practical ways to pair Jev with coding agents. His central pattern is not to replace the LLM: let the LLM build the harness and act on results, while Jev makes frequent, bounded decisions in the middle. What Jev is for Jev takes a description of the current state plus a fixed set of questions or choices, then returns answers with confidence scores. Medin says this decision-only design is 20–200× faster and 40–1,000× cheaper than using a generative LLM for the same kind of classification; those are product claims, not independent measurements in this video. It cannot generate free-form text or invent the action space. The workflow must define the state, legal choices, thresholds, and fallback behavior. 1. A security hook before tool use Coding agents may read secrets, delete data, exfiltrate information, or drift away from the assigned task—even when instructions say not to. A pre-tool-use hook can inspect the tool name, arguments, working directory, and intended effect before allowing an action. Regex rules are fast but brittle: the same risky operation can be expressed as a shell command, Python script, direct file read, or many other forms. An LLM judge is more flexible, but adding a model call before thousands of tool calls creates latency and cost. Medin’s early comparison reports Jev at roughly a quarter-second per check, with fewer false positives than his regex hook and nearly all of his hand-labeled risky calls blocked. The video does not provide the dataset or raw results. 2. Playtesting as a user would Unit tests cannot show whether a game actually feels playable or whether a feature breaks during live interaction. Jev receives game state and chooses among legal actions quickly enough to attack, dodge, and navigate in real time. The run can expose bugs that deterministic tests miss because it exercises the game through the same interaction loop as a player. The LLM still builds the state adapter and action harness, then diagnoses and fixes whatever the playtest finds. 3. Faster browser testing Browser automation is another bounded loop: inspect the current page, choose a button or field, execute the action, and observe the next state. Jev can handle repeated choices such as what to focus or click; an LLM is still needed when a page requires original free-form text or broader visual judgment. Medin demonstrates this split on Dino Chat: text is generated in advance, Jev chooses interface actions, and an LLM can review the resulting trace for bugs. 4. Route work before spending tokens A GitHub issue can first be classified as a bug or feature, then routed to the matching skills and workflow. A second decision selects a model tier based on task difficulty, avoiding an expensive frontier model for routine work. Medin reports agreeing with Jev on all 12 issue-routing trials and on 15 of 16 pull-request review classifications. These are small, self-judged samples, not a production benchmark. The reusable architecture An LLM defines the harness, state representation, and available actions. Jev makes frequent, narrow decisions inside that structure. Deterministic code enforces thresholds and executes approved actions. The LLM interprets failures, repairs code, or handles open-ended work. “Jev is never really the end of our workflow. It’s always just making parts of our workflows faster and more efficient.” ...

Cole Medin explains why coding agents can spend more context finding the right code than editing it, then demos Sonar Vortex as a direct-lookup alternative. This 2½-minute video is sponsored by Sonar. Where the tokens go A nontrivial change starts with repeated searches and file reads before the agent edits a line. The search operation is cheap; loading every plausible file into context is not. Name-based search is also brittle: relevant code can be missed when its name differs from the agent’s guess. The real question is structural: which code participates in this requested change? The proposed fix Sonar already parses the repository; Sonar Vortex exposes that model to the coding agent. It answers relationships directly: which classes implement an interface, what calls a function, what that function calls, and the exact file and line. Its local graph needs neither a compiler nor a language server and, according to the demo, refreshes about a millisecond after an edit. That matters mid-turn, when the repository may not compile yet. What the demo claims Cole’s first run spent about 80,000 tokens on search and file reading. With Vortex, a direct lookup plus a follow-up context request used roughly the same token budget as the original search phase alone. Sonar’s test — six refactoring tasks across ten runs — reported median token savings ranging from 6% to 34%. Supported languages shown: Java, C#, JavaScript, TypeScript, Python, and Rust. The product runs through SonarQube Cloud with the Sonar Agent Essentials add-on. The useful idea beyond the product Repository context should be selected from code relationships, not accumulated through increasingly broad text searches. A graph index can reduce both token cost and omission risk, but the measurements here come from the vendor and a sponsored demo rather than an independent benchmark. “The search itself is fast and cheap, but reading through all these files takes so much context before you’re even changing a single line of code.” ...

Cole Medin (17 min) argues the most underused asset in an AI coding setup is the transcript graveyard on your own disk — every conversation with your agent, already written to a file, and almost never read back. The premise Every conversation your coding agent has is stored as a file on your machine — Claude Code writes JSONL, split by project. Those files hold every prompt you sent, every tool or MCP server the agent called, every thought it had. The agent already knows this — ask “where are all Claude Code conversations stored?” and it can point you at the folder. Cole finds agents reach for those files even when a separate memory system exists, because they’re that rich. The blocker is volume: thousands of these files are too messy to read by hand — and Claude Code deletes them after 30 days by default. So the setup needs two things: somewhere transcripts live permanently, and a database that turns them into structure (sessions, turns, tool calls). The two-sentence version Just ask: do a deep dive into past conversations, identify opportunities to make the agent more efficient or reliable, suggest the top 10 improvements as a concise bullet list. Bounding the output matters — before Opus 5.5 he’d get “a million different things that barely mattered at all.” It loads a skill he built for the process and runs shell commands across the files. Real example it surfaced: hitting the concurrent sub-agent limit constantly. Follow-up prompt — “what can I change in our AI layer to fix issue #3?” — pointed at the specific sub-agent responsible. His definition of AI layer: sub-agents, hooks, rules, skills, and the rest of the .claude folder. It’s written into the skill so the agent knows it’s auditing itself. Why that approach hits a wall The agent either reads hundreds of thousands of tokens of JSONL to find every pattern, or it cherry-picks a few files and returns surface-level findings. Neither is reliable, and you re-pay the token cost every time you ask. He name-checks existing options (CC usage, Claude Mem) but says they’re memory systems, not instruments for making the agent measurably more efficient over time. The real system: volume + tables + Genie Install the Databricks CLI, connect it to your coding agent of choice (Claude Code, Codex, Pi) as an MCP server. Create a volume in Unity Catalog and upload the transcripts — either through the MCP server or plain drag-and-drop. Point Genie (Databricks’ built-in agent) at the volume path and have it process every JSONL with Spark instead of burning model tokens. He flagged the hard part honestly: the session transcripts have “inconsistent nested schemas across records” — every conversation is formatted a bit differently. Two-step prompting he recommends: first make Genie understand the data and prove the shape back to you, then have it create the tables and load everything. Result: turns, tool_calls, and sessions tables, populated, with row counts and columns reported back. He says he wrote none of the generated code. Then query from your coding agent through the MCP server — Claude Code becomes the orchestrator asking questions, Genie is the brains writing SQL over structured data. The privacy caveat he raises himself You’re uploading coding-agent conversations into a third-party platform — he says be okay with that before starting. Databricks doesn’t train on the data, and the bar is that you shouldn’t be handing sensitive material to a coding agent in the first place. If your JSONL files carry API keys, scrub them first — the MCP server can do the scrubbing before upload. What he actually changed +38 lines of global rules targeting the failure patterns Genie surfaced — including “never guess a path,” which he says agents do constantly if you don’t forbid it. More permissions in settings.json so the agent works with Git more cleanly. A hook (his favorite change): a session-tree script that fires at the start of every conversation and injects the real repository layout, so the agent stops guessing paths while gathering context. Why a hook beats a rule: a codebase layout hard-coded in global rules goes stale and has to be maintained by hand — injected at runtime, it’s always current. “Your past conversations with your coding agent are a gold mine. There are a lot of different ways to structure the conversations and gather insights from them and act on them.” ...

Cole Medin, 14 minutes (with a sponsor spot for Scrimba Explain). The premise is the practical consequence of harness engineering and software factories: once agents write most of the code, model quality stops being the binding constraint — tokens per week does. The trigger He hit the rate limit on his $200/month Claude Max plan and his $200/month Codex Pro plan in the same week, both days away from reset, without a big jump in workload Opus 5.5 helps, but not nearly enough; the limits have been tightening all year So “just be more token-efficient” stops working as a strategy. The lever is which model does which step The routing rule Planning and review get the most capable model. Implementation gets a cheap one. The plan is the highest-leverage step: with a well-written plan, the implementer doesn’t have to be that capable — planning with Fable 5.1 and implementing with a small model lands essentially where Fable-for-everything does Implementation is the token-heavy part of the workflow, so that’s where the savings come from Exceptions: genuinely novel or unexplored work can justify a large model end to end; small, bounded tasks with a human in the loop can run open models for everything Same game, built three ways A storm-chasing multiplayer game on Neptune, built three times from the same PRD through his AI Software Factory: ...

Cole Medin with a 90-second announcement (a sponsored spot for Amazon Developer) about the Build, Ship, Shape hackathon — and the part that matters past the prize money: Amazon has made MCP the way outside services plug into Alexa+. What Amazon actually adopted Alexa+ integrations run over MCP, the open standard — not a bespoke Amazon SDK you’d have to learn from scratch Transport is Streamable HTTP on spec 2025-11-25 or later An MCP server you already have works with minimal changes: you provide the tools, Alexa+ supplies the conversation, the screen and the voice The hackathon, in short Four tracks in one global event: Alexa+, Fire TV, Ring, and Bee (the wearable) — the first time all four are open to outside developers at once $190K in value across cash and AWS credits (Devpost lists $138,000 of that as cash) Alexa+ track: $25,000 cash + $15,000 AWS credits for first place, plus a 1:1 with the Amazon Developer team Solo or team, no experience required — the pitch is that you build the thing you’d build anyway Submissions close October 23, 2026, 7:00pm UTC (3pm ET) Roughly 12,200 people had registered when this was captured The Alexa+ track specifically Bring a self-hosted MCP server or an Agent Skill and show it working No Echo needed: you can simulate the Alexa+ side in a web app using your own agentic tools — the repo just has to include the simulation’s source code The required tech has to be live in the code (an import, an entry point, a loaded MCP/agent config), not a mention in the README Feedback you submit goes directly to the product teams building the platform Extra ways to win (mini challenges) AWS Builder: use Bedrock, AgentCore, Strands SDK, Kiro Crew or SageMaker with documented integrations Open Source: ship an additional open-source project, or a branch/fork/PR against a public repo during the window — it does not need to be merged What they’re judging Tech implementation (how well it uses the required APIs/SDKs), design (a coherent, intuitive product experience), potential impact (a credible case for real customer needs), and quality of the idea “You don’t have to learn anything new. You just build the MCP server you’d create anyway. It’s just that it runs in something that lives in people’s kitchens.” — Cole Medin ...

Cole Medin (16 min) is a year into his personal AI second brain — an agent that builds a knowledge base as he works — and this one answers the question he says he keeps getting: how do you turn a second brain into a team brain? ...

Cole Medin walks through “drive screen” — a coding-agent skill that lets Claude Code or Codex drive his entire desktop using nothing but shell commands. 13 minutes, no harness, no dependencies. The pitch: computer use without the harness Cole says he was a computer-use skeptic: tools like Claude’s built-in computer use, Codex computer use, and the open-source options were “bloated and hard to manage” — hard to customize as little failure modes show up. His claim: with frontier models (Fable 5.1, GPT-6 Astra), an agent can drive the screen reliably through PowerShell on Windows, AppleScript on Mac, and plain shell on Linux. Nothing gets installed. Tested across Mac, Linux, and Windows, plus multiple monitors and display settings. The skill is a little under 400 lines. The broader takeaway he keeps returning to: tasks he had written off as “the LLM can’t do that” (computer use, editing video) no longer need a specialized tool — just try it. What he actually uses it for Morning setup — one prompt (“get my morning set up, here’s what I’m working on”) opens browser tabs, Obsidian notes, desktop apps, and Docker containers. He estimates 10–15 minutes saved daily. Staging demos and recordings every day. Testing desktop apps — the skill was born from wanting to try open-source projects (e.g. Kestrel) that have a UI and can’t be exercised through browser automation. The first test: hand Claude a GitHub URL, tell it to research the repo, launch the app, and drive the screen to test features, then leave it open. It worked end to end. Driving other agent sessions — watching for approval prompts and auto-driving them. How the skill is built It starts by asking whether screen control is needed at all. The skill explicitly tells the agent to push back, because screen control is the slowest and least reliable way to make a computer do something — browser automation is often the better answer. Ships with a custom CLI of scripts for window discovery, focusing, typing, and pasting — packaging his hours of testing into deterministic commands instead of having the agent improvise shell syntax in real time. This is the main reliability win. Hard rules — lessons learned the hard way, encoded. A control loop — discover the window, screenshot it, focus, then act. Traps — failure patterns he kept hitting with browser tabs, desktop apps, and other agent sessions. You can delete or add your own. Security and prompt injection The obvious risk: indirect prompt injection arriving on screen, which the agent reads and acts on. He links HiddenLayer’s writeup on indirect prompt injection against Claude computer use. His position, which he admits may age badly: with the newest models, prompt injection is much less of a concern than it used to be — and he avoids using the skill for anything production-grade, keeping it to simple tasks like morning setup and desktop-app testing. Anything production still gets a full harness. He also notes the skill is token-efficient: the slowness is waiting on screen input, not burning tens of thousands of tokens. Install Skill folder: github.com/coleam00/skills under .claude/skills/drive-screen — drop it into any project, hand the URL to your coding agent, or take the ideas and install nothing. “Screen control is the slowest and least reliable way to make a computer do something. So it’s the most adaptable and flexible, but it’s the slowest.” ...

Cole Medin’s full walkthrough of standing up his open-source “software factory” — the autonomous issue-in, merged-PR-out harness he’s been building this year — on a remote VPS, with Codex running GPT-6 Astra as the worker model (16 min). On the AGI talk Jensen Huang reportedly declared AGI achieved because of Astra. Medin’s response: don’t buy the hype — and then concedes he’s starting to buy into it, just not the AGI part On benchmarks Astra and Fable 5.1 look equivalent. After a week of head-to-head testing, he says Astra comes out on top a majority of the time His specific claim: it’s the first model that “gets” him — far less time spent communicating intent, and notably fewer weird assumptions than Opus 5 made over the past few months Still “has its moments.” That’s his evidence that we are not at AGI, whatever the benchmarks show What a software factory actually is The pitch: a fully autonomous harness where the PRD goes in and shipped code comes out — he also calls it the “dark factory” Earlier this year the idea was unrealistic; the models and the harnesses weren’t reliable enough. With Astra he says he can see the light at the end of the tunnel Honest framing throughout: not close to 100% reliable for arbitrary code, and he calls the project early alpha while he keeps refining it Operating loop, in his description: Input is always an issue (a PRD split into issues, or issues you write directly) A triage workflow reads the issue against the factory’s rules and mission context, decides accept or reject, and ranks by priority It runs the work through to a pull request that is fully reviewed Most of the time it merges automatically; it escalates to a human only when it has to He’s been using it on his own projects — Archon (the open-source harness underneath), games, whatever he’s building that week The deploy, which is mostly prompts Two supported starting points: a brand-new repo where you only have a PRD, or bolting the factory onto an existing codebase. His demo uses a small existing link-shortener app because it means less initial setup The whole setup is: give your coding agent the cheat-sheet URL from the repo and say “help me set this up.” It interviews you to establish the factory’s core context files, then walks the deployment He deploys with Codex on GPT-6 Astra, though he says Claude Code and Codex are the two he’s tested heavily and either works Hostinger’s MCP plugin lets the agent manage the VPS directly (this video is sponsored by Hostinger; the real requirement is just an Ubuntu box in the cloud). He installs the plugin user-scoped, authenticates in the browser, then asks it to list his instances as a smoke test The plugin deliberately can’t create instances — he doesn’t want an agent holding that power — so you spin up the VM yourself and hand the agent the VM ID and public IP The agent then rips through SSH access, firewall rules, and installing the factory’s dependencies Two steps stay manual, because you shouldn’t hand over credentials: GitHub auth and OpenAI/Codex login. Both use device-code flows you complete in a browser Gotcha worth copying: enable device code authorization for Codex in ChatGPT settings → Security and login, or remote auth gets needlessly painful Sanity check on the box: codex exec a hello to confirm the model answers before continuing Tell the setup agent “I’m done” and it installs the factory plus Archon, confirms Codex is live, and installs your target repo Proving it end to end The cheat sheet doesn’t stop at install — it drives a first test issue, created through the GitHub CLI in your repo He takes the agent’s own recommendation for the issue rather than inventing one The factory triages it (marked “archon ready”), runs the workflows, and produces a pull request The test he ran was trivial on purpose — the point is proving the trigger path and the workflows work with the coding-agent auth on the remote machine After the first PR validates, you close the setup session. The factory keeps running 24/7 on the box, accepting any GitHub issue you file The agent can even update DNS records through the same plugin, if your domain is already there Caveats he states plainly Still early alpha, still not reliable for everything, and he’d be the first to say so The guide is intentionally platform-flexible, which means parts are high-level: expect the agent to hit snags and hand you commands to run, especially around authentication He’s promising more content on how the internals work and how to make the whole thing token-efficient — that’s the part this video skips “We literally go from issue all the way to validated and merged code.” — Cole Medin ...

Cole Medin on the security gap in AI coding workflows (17 min, partnered with Sonar; Archon, the harness builder he uses, is his own open-source project). His premise: agents are already better and faster than humans at a lot of code — but security is where they fall short far more than reusability, documentation or performance, and almost nobody is building for it. ...

Cole Medin on the permission pattern he uses so AI coding agents can operate real infrastructure without holding the keys — a ~2-minute spotlight, sponsored by Kestra (their 2.0 just shipped; the core stays Apache-2.0). Why trust breaks at the boundary He has used coding agents to write every line of code this year — but still monitors and validates everything The limiter isn’t the model, it’s what the agent can reach: the moment it touches real infrastructure you hand it a cloud key, a database URL, shell access — everything, including the ability to wipe the database The fix: an orchestrator between the agent and the infra Wrap the coding agent in an orchestrator that gives it workflows to do the things you want — and nothing more Operations are written once as YAML in Git; the agent never gets access to the credentials the orchestrator uses The agent simply receives a list of workflows it is allowed to invoke, and credentials are used inside those flows — “that is the entire permission model” What the permission surface looks like in practice The example agent can restart services and scale replicas — nothing else Flows are plain YAML files defined alongside the agent, so everything is manageable in Git Observability is what makes unattended runs OK Every call comes back as a normal execution with inputs, logs, and results visible in the dashboard When agents run without you, you can still open and read what they did Open source Kestra 2.0 is officially out; the core is Apache 2.0, and the AI-agent piece is part of the open-source core, not behind an enterprise paywall “What limits my trust is not the model itself — it’s what it can reach.” — Cole Medin ...

Cole Medin runs through 11 small tweaks that make any coding agent — Claude Code, Codex, whatever — noticeably more reliable, without scrapping your workflow. The through-line: agents are prediction machines, not deterministic programs, so reliability comes from shrinking their decision space and moving guarantees into deterministic mechanisms. ~17 minutes. Rules and context 1. Write for the agent, not the human. Humans interpret high-level docs in context; agents make assumptions. Be blunt — file paths, numbers, exact commands. 2. Your instruction files rot. “Rule drift”: 1 in 4 repos have stale AI rules referencing deleted files or replaced databases. Audit them against the codebase. 5. Less context is more. Too many rules hurts as models improve. Keep global rules under ~200–300 lines; drop generic advice and move the rest to task-specific context files. Conversation hygiene 3. /compact loses ~90% of detail. Compacting a bloated conversation breeds hallucination. Give smaller work chunks, or write your own handoff doc and start fresh. 7. Don’t escalate mid-task. A bigger model can’t rescue a tainted conversation — mistakes compound within a session. Write a handoff doc and burn it. 10. Over-revision degrades quality. 85% of the time an earlier iteration was better. The model “fixes” things just to appease you. Determinism over frameworks 4. Load-bearing rules → hooks. Rules are probabilistic (the agent will “forget” to run tests); hooks are deterministic — fire on an event and route failures back. 6. Subagents eat your rate limit. Parallel fanouts cost more than you think — 39% of his weekly usage came from 4+ parallel sessions. 8. You don’t need coordinators. Team-lead frameworks and agent mailboxes are unreliable. A plain delegator agent gets most of the scale with far more reliability. Validation 9. Never let the writer approve the work. The writer carries its own bias. Review in a fresh conversation with a handoff doc — no assumptions carried over. 11. Validation is a system, not a step. Plan the full harness — test conventions, tools, edge cases — before writing any code, not as an afterthought. “Your number one job when you’re planning any work with your coding agent is to reduce the number of assumptions that it’s making.” — Cole Medin ...