Wait, did people in the tech world not know this? If this is some shocking revelation to engineers we are in trouble.
Any and every "AI" experience is just kiddie level program mg wrapping LLMs.
How to code Claude Code in 200 lines of code
231–240 of 249 posts
Re: How to code Claude Code in 200 lines of code
#232> This is the key insight: we’re just telling the LLM “here are your tools, here’s the format to call them.” The LLM figures out when and how to use them. This really blew my mind back then in the ancient times of 2024-ish. I remember the idea of agents just reached me and I started reading various "here I built an agent that does this" articles, and I was really frustrated at not understanding how the hell LLM "know…
Running a command in a shell is a string of text. LLMs produce text and it's easy to write a program that then executes that text as a process. I don't see what's magical about it at all.
Re: How to code Claude Code in 200 lines of code
#233Something I would add is planning. A big "aha" for effective use of these tools is realizing they run on dynamic TODO lists. Ex: Plan mode is basically bootstrapping how that TODO list gets seeded and how todos ground themselves when they get reached, and user interactions are how you realign the todo lists. The todolist is subtle but was a big shift in coding tools, and many seem to be surprised when we discuss it -…
It’s surprising how simple TodoWrite and TodoRead tools are in planning and making sure an Agent follows the plan.
This is supposed to be an emulator of Claude’s own TodoWrite and TodoRead, which does a full update of a todo.json for every task update. A nice use of composition of edit tool - https://github.com/joehaddad2000/claude-todo-emulator
Re: How to code Claude Code in 200 lines of code
#234All you actually need is 50 lines and one tool.
If your agent can execute Bash commands, it can do anything, including reading files (with cat), writing them (with sed / patch / awk /perl), grepping, finding, and everything else you may possibly need. The specialized tools are just an optimization to make things easier for the agent. They do increase performance (in the "how much can this do", not the "how fast is this" sense), but they're not strictly required.
IMHO, this is one of the more significant LLM-related discoveries of 2025. You don't need a context-polluting Github MCP that takes 10+% of your precious context window, all you need is the gh cli, which the agent already knows how to use.
Re: How to code Claude Code in 200 lines of code
#235Something I would add is planning. A big "aha" for effective use of these tools is realizing they run on dynamic TODO lists. Ex: Plan mode is basically bootstrapping how that TODO list gets seeded and how todos ground themselves when they get reached, and user interactions are how you realign the todo lists. The todolist is subtle but was a big shift in coding tools, and many seem to be surprised when we discuss it -…
It’s surprising how simple TodoWrite and TodoRead tools are in planning and making sure an Agent follows the plan. This is supposed to be an emulator of Claude’s own TodoWrite and TodoRead, which does a full update of a todo.json for every task update. A nice use of composition of edit tool - https://github.com/joehaddad2000/claude-todo-emulator
Complex planning and orchestration for Multi-step usecases or persistent Todo lists is achievable by spinning up your own tools that does something similar to this.
By extending Claude Todo emulator, It was possible to make the agent come up with Multi-step Hierarchical plans and follow it and track updates on it for usecases like Oncall Troubleshooting Runbooks.
PS: the above open source repo does not provide single task update as a tool, which is not hard to implement on your own
Re: How to code Claude Code in 200 lines of code
#236Excellent article on the internals of coding CLIs.
I learned a similarly powerful way to build DIY coding CLIs from this Martin Fowler post, which uses PydanticAI and MCP-based tools: https://martinfowler.com/articles/build-own-coding-agent.htm...
Once you understand the underlying LLM tool-calling protocols described here—and how MCP tool calls work (they’re conceptually very similar)—most coding CLIs stop feeling like magic. Anthropic’s own deep dive on MCP was especially useful for me in seeing how to integrate this into a DIY “Claude Code”-style CLI, and even adapt the same approach for non-coding agents as well: https://www.deeplearning.ai/short-courses/mcp-build-rich-con...
Re: How to code Claude Code in 200 lines of code
#237I don't code in Python much. Are those type annotations really how people are using them, or is it just for the example?
def list_files_tool(path: str) -> Dict[str, Any]:
{
"path": str(full_path),
"files": all_files
}
Re: How to code Claude Code in 200 lines of code
#238How much code could Claude Code code if Claude Code could code Claude?
Re: How to code Claude Code in 200 lines of code
#239Something I would add is planning. A big "aha" for effective use of these tools is realizing they run on dynamic TODO lists. Ex: Plan mode is basically bootstrapping how that TODO list gets seeded and how todos ground themselves when they get reached, and user interactions are how you realign the todo lists. The todolist is subtle but was a big shift in coding tools, and many seem to be surprised when we discuss it -…
I’m a DIY (or, less generously and not altogether inaccurately, NIH) type who thinks he could do a good job of smarter context management. But, I have no particular reason to know better than anyone else. Tell me more. What have you seen? What kinds of approaches? Who’s working on it?
I'm optimistic most people can, given the time and resources
In the CCC video, you may enjoy the section on how we are moving to eval-driven AI coding for how we more methodically improve agents. Even more so, the slides before on motivating why it gets harder to improve quality as you go on.
One big rub is it's one of those areas where people grossly misunderestimate what is needed for the quality goals they're likely targeting, and if a long-living artifact to be maintained, the on-going costs. It's similar to junior engineers or short-term contractors who never had to build production-grade software before and haven't had to live with their decisions: These are quite learnable engineering skills, and I've found it useful to burn your fingers before having confidence in the surprising weight of cost/benefit decisions. The more autonomy and expectations you are targeting for the agent, the more so.
Re: How to code Claude Code in 200 lines of code
#240A lot of software is like this. You can build a bare bones but functional version for 1x investment or something that addresses every bell and whistle (often with market research saying it’s really needed) for 1000x. The 1000x version is better, but not remotely 1000x better.
A lot of SaaS has turned into this too. Take a bloated monstrosity like Salesforce and I bet 95% of customers would be very happy with a “bare bones” version that costs 1 10th the price.