Harshavardhan Katkam

Thanks, Kartik. Yes, and you've named the exact case. Next up is Day 01, the 40-line loop. Day 06 hand-rolls tool calling and breaks it on purpose: a tool name the model invented, arguments cut off mid-JSON, a parameter that doesn't exist. None of them crash the loop. Each one goes back to the model as the tool's result, an error message listing what's valid, so it can correct itself on the next turn. Day 04 covers the same idea for the final answer: a strict schema instead of parsing prose. And glad "fluently wrong" landed. It's the one idea I'd want a beginner to keep.

Thanks! Real codebases are the point. Day 07 is the first full run, on a well-known open-source Python project pinned to one release, so anyone can reproduce the result and check the map against the actual source. Later it gets scored against a second project too.

Thanks, Kartik. The stop-reason trap is a good one; a truncated answer that looks finished is exactly the kind of bug the series is about. Tool-call failures are handled in week one, not deferred. On day 06 a bad call doesn't crash the loop: an invented tool name, arguments cut off mid-JSON, or a wrong parameter go back to the model as the tool's result, an error message listing what's valid, so it can correct itself next turn. The loop is also capped at a fixed number of turns, so a model that keeps calling tools can't run forever. Week four's hardening (day 28) is about the failures that don't raise anything: a run that finishes cleanly with a map that's quietly wrong. On truncation: day 05 sets max_tokens so a cut-off answer surfaces as malformed JSON rather than passing as finished. You've convinced me it's worth checking finish_reason explicitly as well.

Thanks, Julian. That's exactly the bet. Once you've written the loop yourself, a framework stops being magic and becomes a set of choices you can judge. That's why LangGraph only shows up in week 3, after the hand-built version has already hit the problems it solves. Curious which part of the loop fought you hardest?

Agreed, and that's the bar I'm holding it to. From day 01 the loop only counts a step when a tool result comes back, and the map has to point at what it read: a file and a line, not a summary of a summary. What I'd refuse to call done on day 30: a map whose claims don't cite a file and line the agent actually opened a "better" version that hasn't been scored against the eval set any version that can write to the repo it's reading. It writes docs, never code. If it can't show its evidence, it's narration, and you're right that 30 days of that would teach the wrong thing. Thanks for pushing on it.