Live data from Hacker News

EvanFlow – A TDD driven feedback loop for Claude Code

github.com

61–70 of 75 posts

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#61

The refactor step is the silent casualty in AI-assisted TDD. Once the test is green, Claude optimizes for moving to the next test, not for cleaning up the impl that just passed. An "iterate-until-clean" pass at the end is a different thing: you're refactoring cold code, not refactoring with a freshly-written test as the safety net.

mmm good point! just shipped a fix that puts RED → GREEN → REFACTOR per cycle with the fresh test as safety net just like beck intended. macro/cross-cycle refactor lives in iterate now as its own separate thing so the two don't conflate. thanks for the catch : )

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#62

Curious, In the repo you mention > Several rules come from 2025-2026 industry research on agentic coding failure modes What are some of the papers you read?

With no disrespect intended because this is also how I would do it (but I wouldn't publish and name it after myself!) - they didn't read the research. They had the AI that actually created this do that for them.

fair to call out but half true. i did send claude off to look up specific stats on failure modes (62% assertion correctness, etc), but the design decisions came from my own reading of anthropic's reports, the columbia daplab paper i cited, and a mix of matt pocock's lectures + my own anecdotal experience running this loop on real projects.

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#63
post #8

Two questions 1) Do you not feel self-conscious or weird about calling this "EvanFlow"? Seems like a lot of people these days are naming their AI tools/skills/whatever after themselves which seems self-absorbed. Either that or they hope that if their thing takes off like OpenClaw did then they'll grab the fame that comes along with it. 2) Why does your TDD flow miss the refactor step of TDD?

1): you have things backwards, the EvanFlow is not something i came up with but rather something i discovered similar to the dao. i am named Evan after the EvanFlow not the other way around.

2): you're right and dmitry called this out below too. shipped a fix that puts REFACTOR per-cycle, instead of being a deferred "after all tests pass" step. the old step 4 was iterate-shaped not TDD-shaped.

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#64
post #17

I’ve thought of going down the TDD model for LLMs as a way of providing constraints on their behavior. I would think that “vertical slice” TDD would encourage the LLM to start tailoring the tests to the implementation rather than establishing the invariants up front, though. I was considering “horizontal” TDD to force the agent to implement constraints before coding to them.

yeah went back and forth on exactly this trade-off, you're right that vertical can produce tests tailored to the impl. horizontal forces invariants up front but the failure mode flips: you're tailoring tests to the architecture you imagined before any feedback from working code. so it's invariants-vs-behaviors, both have a tailoring failure mode just on different axes. compromise i landed on: vertical + an explicit anti-tailoring grill check at each cycle. definitely gonna tweak with more as i keep refining.

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#65
post #20

To be honest, the official superpowers/brainstorming skill already does TDD so well, I don't see that much of a need for this. TDD is definitely the way to go with agentic development.

how?i saw superpowers/brainstorming but never saw tdd code produced

Just tell it to use TDD

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#66
The refactor-per-cycle fix lands in the right place. The harder problem shows up when EvanFlow forks into parallel coder/overseer mode: unit tests pass per agent, but the seams break at merge. Your note that "integration tests at touchpoints ARE the cohesion contract" is exactly right, but enforcement is what makes it stick. Each parallel branch needs its own failing test that can't be masked by another branch's green run. Worktree isolation handles this cleanly since each agent's environment is separate. Without that, vertical-slice TDD in parallel collapses to "tests pass somewhere."

On jtfrench's unanswered question about dumb zone evasion: context length is what drives the drift. Agents go off-track when a loop runs long enough that early design context falls out. Resetting at each RED-GREEN-REFACTOR boundary keeps cycles short enough to avoid it. The hard cap of 5 iterate rounds is the same instinct applied at the macro level.

We ran into the parallel integration seam problem building tonone, a 23-agent Claude Code plugin where each domain agent works in its own worktree and integration tests are the merge contract.

https://github.com/tonone-ai/tonone if curious.

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#67
post #20

To be honest, the official superpowers/brainstorming skill already does TDD so well, I don't see that much of a need for this. TDD is definitely the way to go with agentic development.

how?i saw superpowers/brainstorming but never saw tdd code produced

There is another skill for tdd. You can activate it manually or tell the harness to

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#68
post #17

I’ve thought of going down the TDD model for LLMs as a way of providing constraints on their behavior. I would think that “vertical slice” TDD would encourage the LLM to start tailoring the tests to the implementation rather than establishing the invariants up front, though. I was considering “horizontal” TDD to force the agent to implement constraints before coding to them.

yeah went back and forth on exactly this trade-off, you're right that vertical can produce tests tailored to the impl. horizontal forces invariants up front but the failure mode flips: you're tailoring tests to the architecture you imagined before any feedback from working code. so it's invariants-vs-behaviors, both have a tailoring failure mode just on different axes. compromise i landed on: vertical + an explicit a…

What if you don’t ask for code yet. Prompt only for tests with maybe a minimal interface context that tests can code against?

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#69
post #8

Two questions 1) Do you not feel self-conscious or weird about calling this "EvanFlow"? Seems like a lot of people these days are naming their AI tools/skills/whatever after themselves which seems self-absorbed. Either that or they hope that if their thing takes off like OpenClaw did then they'll grab the fame that comes along with it. 2) Why does your TDD flow miss the refactor step of TDD?

Jesus mate, talk about loaded questions.

“Who are you? How dare you create anything”

Re: EvanFlow – A TDD driven feedback loop for Claude Code

#70
post #17

I’ve thought of going down the TDD model for LLMs as a way of providing constraints on their behavior. I would think that “vertical slice” TDD would encourage the LLM to start tailoring the tests to the implementation rather than establishing the invariants up front, though. I was considering “horizontal” TDD to force the agent to implement constraints before coding to them.

[dead]
Post reply on HN