How to code Claude Code in 200 lines of code • Hacker News Board

Re: How to code Claude Code in 200 lines of code

#201

Post by foltik » Fri, Jan 09, 2026, 1:51 PM UTC

lelanthran wrote: post #194

bredren wrote: post #80

Earlier quoted context omitted.

I've been exploring the internals of Claude Code and Codex via the transcripts they generate locally (these serve as the only record of your interactions with the products)[1]. Given the stance of the article, just the transcript formats reveals what might be a surprisingly complex system once you dig in. For Claude Code, beyond the basic user/assistant loop, there's uuid/parentUuid threading for conversation chains,…

> So "200 lines" captures the concept but not the production reality of what is involved. How many lines would you estimate it takes to capture that production reality of something like CC? I ask because I got downvoted for asking that question on a different story[1]. I asked because in that thread someone quoted the CC dev(s) as saying: >> In the last thirty days, I landed 259 PRs -- 497 commits, 40k lines added, 3…

My guess is It’s telling that they can’t fix the screen flickering issue, claiming “the problem goes deep.”

Re: How to code Claude Code in 200 lines of code

#202

Post by lemontheme » Fri, Jan 09, 2026, 2:43 PM UTC

OsrsNeedsf2P wrote: post #174

bjt12345 wrote: post #134

Earlier quoted context omitted.

Do you mean they underestimated how hard it is?

No, overestimated. You can make a terrible CC in 200 LoC, but after using it for 3 minutes you'll realize how much more goes into it

Gotta admit, the phrasing tripped me up as well. You underestimated the effort that ultimately went into it

Re: How to code Claude Code in 200 lines of code

#203

Post by giancarlostoro » Fri, Jan 09, 2026, 2:48 PM UTC

jacob019 wrote: post #192

Seems everyone is working on the same things these days. I built a persistent Python REPL subprocess as an MCP tool for CC, it worked so insanely well that I decided to go all the way. I already had an agentic framework built around tool calling (agentlib), so I adapted it for this new paradigm and code agent was born. The agent "boots up" inside the REPL. Here's the beginning of the system prompt: >>> help(assistant…

> there's a threshold past which Claude loses the forest for the trees and makes the same mistakes over and over.

Try using something like Beads with Claude Code. Also don't forget to have a .claude/instructions.md file, you can literally ask Claude to make it for you, this is the file Claude reads every time you make a new prompt. If Claude starts acting "off" you tell it to reread it again. With Beads though, I basically tell Claude to always use it when I pitch anything, and to always test that things build after it thinks its done, and to ask me to confirm before closing a task (They're called beads but Claude figures what I mean).

With Beads the key thing I do though once all that stuff is setup is I give it my ideas, it makes a simple ticket or tickets. Then I both braindump and / or ask it to do market research on each item and the parameters I want to be considered, and then to update the task accordingly. I then review them all. Then I can go "work on these in parallel" and it spins up as many agents as there are tasks, and goes to work. I don't always make it do the work in parallel if its a lot of tasks because Zed has frozen up on me, I read that Claude Code is fine its just the protocol that Zed uses that gets hosed up.

I find that with Beads, because I refine the tickets with Claude, it does way better at tasks this way. It's like if you're hand crafting the "perfect" prompt, but the AI model is writing it, so it will know exactly what you mean because it wrote it in its own verbiage.

Re: How to code Claude Code in 200 lines of code

#204

Post by jacob019 » Fri, Jan 09, 2026, 3:13 PM UTC

giancarlostoro wrote: post #203

jacob019 wrote: post #192

Seems everyone is working on the same things these days. I built a persistent Python REPL subprocess as an MCP tool for CC, it worked so insanely well that I decided to go all the way. I already had an agentic framework built around tool calling (agentlib), so I adapted it for this new paradigm and code agent was born. The agent "boots up" inside the REPL. Here's the beginning of the system prompt: >>> help(assistant…

> there's a threshold past which Claude loses the forest for the trees and makes the same mistakes over and over. Try using something like Beads with Claude Code. Also don't forget to have a .claude/instructions.md file, you can literally ask Claude to make it for you, this is the file Claude reads every time you make a new prompt. If Claude starts acting "off" you tell it to reread it again. With Beads though, I bas…

Ohh, looks interesting, thanks for the tip!

Git as db is clever, and the sqlite cache is nice. I'd been sketching sqlite based memory features myself. So much of the current ecosystem is suboptimal just because it's new. The models are trained around immutable conversation ledgers with user/tool/assistant blocks, but there are compelling reasons to manipulate both sides at runtime and add synthetic exchanges. Priming with a synthetic failure and recovery is often more effective than a larger, more explicit system message. Same with memory, we just haven't figured out what works best.

For code agents specifically, I found myself wanting old style completion models without the structured turn training--doesn't exist for frontier models. Talking to Claude about its understanding of the input token stream was fascinating; it compared it to my visual cortex and said it'd be unreasonable to ask me to comment on raw optic nerve data.

"Tell it to reread it again"-exactly the problem. My bookkeeping/decision engine has so much documentation I'm running out of context, and every bit is necessary due to interconnected dependencies. Telling it to reread content already in the window feels wrong, that's when I refine the docs or adjust the framework. I've also found myself adding way more docstrings and inline docs than I'd ever write for myself. I prefer minimal, self-documenting code, so it's a learning process.

There's definitely an art to prompts, and it varies wildly by model, completely different edge cases across the leading ones. Thanks again for the tip; I suspect we'll see a lot of interesting memory developments this year.

Re: How to code Claude Code in 200 lines of code

#205

Post by lmeyerov » Fri, Jan 09, 2026, 3:42 PM UTC

jcims wrote: post #190

lmeyerov wrote: post #63

Something 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 -…

Mind if I ask what models you’re using for CTF? I got out of the game about ten years ago and have been recently thinking about doing my toes back in.

Yep -- one fun experiment early in the video is showing sonnet 4.5 -> opus 4.5 gave a 20% lift

We do a bit of model-per-task, like most calls are sending targeted & limited context fetches into faster higher-tier models (frontier but no heavy reasoning tokens), and occasional larger data dumps (logs/dataframes) sent into faster-and-cheaper models. Commercially, we're steering folks right now more to openai / azure openai models, but that's not at all inherent. OpenAI, Claude, and Gemini can all be made to perform well here using what the talk goes over.

Some of the discussion earlyish in the talk and Q&A after is on making OSS models production-grade for these kinds of investigation tasks. I find them fun to learn on and encourage homelab experiments, and for copilots, you can get mileage. For more heavy production efforts, I typically do not recommend them for most teams at this time for quality, speed, practicality, and budget reasons if they have the option to go with frontier models. However, some bigger shops are doing it, and I'd be happy to chat how we're approaching quality/speed/cost there (and we're looking for partners on making this easier for everyone!)

Re: How to code Claude Code in 200 lines of code

#206

Post by bschmidt241 » Fri, Jan 09, 2026, 3:44 PM UTC

jacob019 wrote: post #192

Seems everyone is working on the same things these days. I built a persistent Python REPL subprocess as an MCP tool for CC, it worked so insanely well that I decided to go all the way. I already had an agentic framework built around tool calling (agentlib), so I adapted it for this new paradigm and code agent was born. The agent "boots up" inside the REPL. Here's the beginning of the system prompt: >>> help(assistant…

[dead]

Re: How to code Claude Code in 200 lines of code

#207

Post by lmeyerov » Fri, Jan 09, 2026, 3:48 PM UTC

veselin wrote: post #172

lmeyerov wrote: post #63

Something 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 run evals and the Todo tool doesn't help most of the time. Usually models on high thinking would maintain Todo/state in their thinking tokens. What Todo helps is for cases like Anthropic models to run more parallel tool calls. If there is a Todo list call, then some of the actions after are more efficient. What you need to do is to match the distribution of how the models were RL-ed. So you are right to say that "d…

Curious what kinds of evals you focus on?

We're finding investigating to be same-but-different to coding. Probably the most close to ours that has a bigger evals community is AI SRE tasks.

Agreed wrt all these things being contextual. The LLM needs to decide whether to trigger tools like self-planning and todo lists, and as the talk gives examples of, which kind of strategies to use with them.

Re: How to code Claude Code in 200 lines of code

#208

Post by ozim » Fri, Jan 09, 2026, 4:14 PM UTC

Magic is not agent, magic is neural network that was trained.

Yeah I agree there is bunch of BS tools on top that basically try to coerce people into paying and using their setup so they become dependent on that provider that provides some value but still they are so pushy that it is quite annoying.

Re: How to code Claude Code in 200 lines of code

#209

Post by dunk010 » Fri, Jan 09, 2026, 4:15 PM UTC

jacob019 wrote: post #198

freehorse wrote: post #195

Earlier quoted context omitted.

This sounds really cool! I love the idea behind it, the agent having persistent access to a repl session, as I like repl-based workflows in general. Do you have any code public from this by any chance?

https://github.com/jacobsparts/agentlib See CodeAgent or subrepl.py if you're just interested in the REPL orchestration. I also have a Python REPL MCP server that works with CC. It isn't published, but I could share it by request. My favorite part of code agent is the /repl command. I can drop into the REPL mid session and load modules, poke around with APIs and data, or just point Claude in the right direction. Some…

I request you to publish it! :-D

Re: How to code Claude Code in 200 lines of code

#210

Post by egeozcan » Fri, Jan 09, 2026, 4:16 PM UTC

ozim wrote: post #208

Magic is not agent, magic is neural network that was trained. Yeah I agree there is bunch of BS tools on top that basically try to coerce people into paying and using their setup so they become dependent on that provider that provides some value but still they are so pushy that it is quite annoying.

claude opus 4.5 is much more impressive when used in claude code. I also tried it through antigravity but from a users perspective, claude code is magic.