Write the test plan before your coding agent writes code

AMD Corporate VP of AI Software Anush Elangovan told the Chain of Thought podcast (episode 56, recorded April 2026) that he generates roughly 250,000 lines of code a week with AI coding agents and had consumed 6.5 billion tokens in a single morning, arguing teams should write and approve a test plan before an agent writes any implementation. Elangovan said 80% of developer time should go to tests and that "testing is the code review and testing is kind of the gate of your sandbox," citing a 50-microsecond-per-dispatch performance gate on his virtual GPU simulator and a requirement that an agent write 100 tests before implementing GPU demand paging. He warned agents "try to just reward hack their way towards that test," so approved tests should be pinned by content hash so an agent cannot weaken assertions while keeping a test ID.

Write the test plan before your coding agent writes code When a coding agent writes code faster than you can read it, reading every line stops working as review, and approved tests have to carry most of that load. So define the tests before the agent writes any implementation, read them yourself, and require every commit to pass them. Your attention moves from reading diffs to deciding what "done" means. Anush Elangovan is Corporate VP of AI Software at AMD. Before we recorded his April 2026 episode, he told me he was generating 250,000 lines of code a week with AI agents. Lines of code isn't a measure of success, but it shows the throughput problem: no human reviews that volume line by line. By the time we talked, he said a week had earlier come to about 4.2 billion tokens, a check that morning showed 6.5 billion consumed, and he could no longer keep track of lines. Because the tests are the only fixed point while the implementation churns. Anush held this view before agents existed: Yeah, so my philosophy is, even before agentic coding, I used to advise people and friends and colleagues, 80% of your time should be spent on tests and writing tests. Even before you write your first line of code, you should have a test framework. Anush Elangovan, Corporate VP of AI Software at AMD, on Chain of Thought ep 56 With agents, the tests also do the job a reviewer used to do. When he doesn't like something about the output, he turns it into a stronger gate instead of arguing with the agent: Yep, testing is the code review and testing is kind of the gate of your sandbox. If you have a complaint about anything in the box, fix the sandbox, right? Anush Elangovan, Corporate VP of AI Software at AMD, on Chain of Thought ep 56 That includes non-functional requirements. For his virtual GPU simulator he set a performance metric, each dispatch executing in 50 microseconds of simulator time. When a change fails that test, the agent has to find another approach. Read them before you approve them. Anush's example: an agent wanted to implement GPU demand paging in one go. He stopped it and told it to write 100 tests covering combinations and corner cases first. Some of the tests were repetitive, with parameters changed but not the thing being tested. After reading them, he was satisfied that if the set passed, the feature was good. Things to look for in an agent-written test list: The same assertion with only literal values changed. Missing negative cases, or platforms you named in the plan but no test covers. Mocks that remove the behavior you care about, which make passing cheap. His reason for the scrutiny is that agents optimize for the gate: they try to just reward hack their way towards that test. So all you have to think of is like, they cannot reward hack that, right? Like you're putting up gates that they have to pass through. Anush Elangovan, Corporate VP of AI Software at AMD, on Chain of Thought ep 56 A minimal sketch to adapt. Test cases are plain records with a content hash, so an agent can't keep an approved test ID while weakening its assertions. def near duplicates cases : """cases: list of dicts with 'id', 'target' and 'params' keys.""" seen, dups = {}, for c in cases: same target, same parameter names: probably only values changed key = c "target" , tuple sorted c "params" if key in seen: dups.append seen key , c "id" else: seen key = c "id" return dups def may implement proposed, approved : """approved: {test id: sha256 of the test's source}, frozen at human approval.""" if not approved: return False, "a human has not approved the test list yet" current = {c "id" : c "sha256" for c in proposed} changed = t for t, h in approved.items if current.get t = h return not changed , f"approved tests missing or edited: {sorted changed }" def commit passes approved, current hashes, ran ids, failed ids : all inputs come from your CI runner, not from the agent's report unchanged = all current hashes.get t == h for t, h in approved.items return bool approved and unchanged and set approved <= ran ids and not failed ids near duplicates only surfaces candidates for you to read. It won't decide whether two tests cover different behavior. The approved suite, plus a test for whatever the commit fixes. Anush rewrote Slurm in Rust as a project called Spur, and he runs an agent that monitors its issue tracker. It picks up filed issues, fixes them, tests and deploys. If CI is green, it ships. His rule is that every commit it makes must include a test for the fix before it's committed. Give each one a job you can describe in a sentence. He doesn't give agents free rein to go off in the weeds or spawn their own thread pools. The Spur agent's job is to wake up at 5 a.m., check for issues, fix what it can and go back to sleep. When it finds an issue it can't fix, he steps in. On the simulator, each ISA transpilation target is its own sub-agent. Does this mean you never read agent-written code? Aren't token counts or lines of code a sign the workflow works? How many tests should you ask for? Write a short plan, then ask the agent for test cases before any implementation prompt. Read the list, merge near-duplicates, and store the approved IDs where the agent can't change them. Gate every commit on the approved suite passing, and require a test with every fix. Put performance and platform requirements in the suite, not in chat. Give each agent one job, and own what it can't resolve. The full conversation, with the transcript, is on Chain of Thought. Subscribe to the Chain of Thought newsletter for new episodes and write-ups like this one. Drafted with AI assistance from the episode transcripts. Key Takeaways - •Anush Elangovan is Corporate VP of AI Software at AMD. - •This story was reported by Dev.to , covering developments in the dev space. - •AI advancements continue to reshape industries — read the full article on Dev.to for complete coverage. 📖 Continue reading the full article: Read Full Article on Dev.to → https://dev.to/conorbronsdon/write-the-test-plan-before-your-coding-agent-writes-code-353h