[HN Gopher] How to Code Claude Code in 200 Lines of Code
___________________________________________________________________
How to Code Claude Code in 200 Lines of Code
Author : nutellalover
Score : 176 points
Date : 2026-01-08 19:54 UTC (3 hours ago)
(HTM) web link (www.mihaileric.com)
(TXT) w3m dump (www.mihaileric.com)
| bjacobso wrote:
| https://www.youtube.com/watch?v=aueu9lm2ubo
| vrosas wrote:
| Unless there's context, I'm never clicking on a naked youtube
| link.
| pests wrote:
| Are you worried google is going to hack you or something?
| handfuloflight wrote:
| He was told they were never gonna give up.
| prodigycorp wrote:
| This article was more true than not a year ago but now the
| harnesses are so far past the simple agent loop that I'd argue
| that this is not even close to an accurate mental model of what
| claude code is doing.
| splike wrote:
| I'm interested, could you expand on that?
| prodigycorp wrote:
| Off the top of my head: parallel subagents, hooks, skills,
| and a much better plan mode. These features enable way better
| steering than we had last year. Subagents are a huge boon to
| productivity.
| rtgfhyuj wrote:
| are subagents just tools that are agents themselves?
| dkdcio wrote:
| pretty much...they have their own system prompts, you can
| customize the model, the tools they use, etc.
|
| CC has built in subagents (including at least one not
| listed) that work very well:
| https://code.claude.com/docs/en/sub-agents#built-in-
| subagent...
|
| this was not the case in the past, I swore off subagents,
| but they got good at some point
| dkdcio wrote:
| it seems to have changed a ton in recent versions too -- I
| would love more details on what exactly
|
| I find it doing what I in the past had to interrupt and tell it
| to do fairly frequently now
| terminalshort wrote:
| For one thing it seems to splitting up the work and making
| some determination of complexity, then allocating it out to a
| model based on that complexity to save resources. When I run
| Claude with Opus 4.5 and run /cost I see tokens for Opus 4.5,
| but also a lot in Sonnet and Haiku, with the majority of
| tokens actually being used by Haiku.
| nyellin wrote:
| Haiku is called often, but not always the way you think.
| E.g. every time you write something CC invokes Haiku
| multiple times to generate the 'delightful 1-2 word phrase
| used to indicate progress to the user' (Doing Stuff,
| Wizarding, etc)
| dkdcio wrote:
| it's also used in the Explore agent and for other things
| too
| lukan wrote:
| The article was also published one year ago on january 2025.
|
| (Should have 2025 in the title? Time flies)
| llmslave2 wrote:
| Claude Code didn't exist in January 2025. I think it's a typo
| and should be 2026.
| prodigycorp wrote:
| You're right. No wonder the date felt odd. iirc Claude code
| was released around march.
| dkdcio wrote:
| late Feb. 2025:
| https://www.anthropic.com/news/claude-3-7-sonnet
| alright2565 wrote:
| But does that extra complexity actually improve performance?
|
| https://www.tbench.ai/leaderboard/terminal-bench/2.0 says yes,
| but not as much as you'd think. "Terminus" is basically just a
| tmux session and LLM in a loop.
| prodigycorp wrote:
| I'm not a good representative for claude code because I'm
| primarily a codex user now, but I know that if codex had
| subagents it would be at least twice as productive. Time
| spent is an important aspect of performance so yup, the
| complexity improved performance.
| nyellin wrote:
| Not necessarily true. Subagents allow for parallelization
| but they can decrease accuracy dramatically if you're not
| careful because there are often dependencies between tasks
| and swapping context windows with a summary is extremely
| lossy.
|
| For the longest time, Claude Code itself didnt really use
| subagents much by default, other than supporting them as a
| feature eager users could configure. (Source is reverse
| engineering we did on Claude code using the fantastic CC
| tracing tool Simon Willison wrote about once. This is also
| no longer true on latest versions that have e.g. an Explore
| subagent that is actively used.)
| prodigycorp wrote:
| You're right that subagents were more likely to cause
| issues than be helpful. But, when properly understood,
| lead to so much time saved through parallelization for
| tasks that warranted it.
|
| I was having codex organize my tv/movie library the other
| day by having it generate. most of the files were not
| properly labeled. I had codex generate transcripts,
| manually search the movie db to find descriptions of show
| episodes, and match the show descriptions against the
| transcripts to figure out which episode/season the show
| belonged to.
|
| Claude Code could have parallelized those manual checks
| and finished that task at 8x the speed.
| terminalshort wrote:
| Are subagents a fundamental change, or just acting as inner
| loops to the agentic loop similar to the one in the
| article?
| steveklabnik wrote:
| Subagents, in my understanding, are just a tool call from
| the perspective of the parent.
| qsort wrote:
| Obviously modern harnesses have better features but I wouldn't
| say it invalidates the mental model. Simpler agents aren't that
| far behind in performance if the underlying model is the same,
| including very minimal ones with basic tools.
|
| I'd say it's similar to how a "make your own relational DB"
| article might feature a basic B-tree with merge-joins. Yeah,
| obviously real engines have sophisticated planners, multiple
| join methods, bloom filters, etc., but the underlying mental
| model is still accurate.
| prodigycorp wrote:
| You're not wrong but I still think that the harness matters a
| lot when trying to accurately describe Claude Code.
|
| Here's a reframing:
|
| If you asked people "what would you rather work with, today's
| Claude Code harness with sonnet 3.7, or the 200 line agentic
| loop in the article with Opus 4.5, which would you choose?"
|
| I suspect many people would choose 3.7 with the harness.
| Moreover, that is true, then I'd say the article is no longer
| useful for a modern understanding of Claude Code.
| rfw300 wrote:
| Any person who would choose 3.7 with a fancy harness has a
| very poor memory about how dramatically the model
| capabilities have improved between then and now.
| prodigycorp wrote:
| I'd be very interested in the performance of 3.7 decked
| out with web search, context7, a full suite of skills,
| and code quality hooks against opus 4.5 with none of
| those. I suspect it's closer than you think!
| CuriouslyC wrote:
| Skills don't make any difference above having markdown
| files to point an agent to with instructions as needed.
| Context7 isn't any better than telling your agent to use
| trafilatura to scrape web docs for your libs, and having
| a linting/static analysis suite isn't a harness thing.
|
| 3.7 was kinda dumb, it was good at vibe UIs but really
| bad at a lot of things and it would lie and hack rewards
| a LOT. The difference with Opus 4.5 is that when you go
| off the Claude happy path, it holds together pretty well.
| With Sonnet (particularly <=4) if you went off the happy
| path things got bad in a hurry.
| prodigycorp wrote:
| Yeah. 3.7 was pretty bad. I remember its warts vividly.
| It wanted to refactor everything. Not a great model on
| which to hinge this provocation.
|
| But skills do improve model performance, OpenAI posted
| some examples of how it massively juiced up their results
| on some benchmarks.
| aszen wrote:
| I don't think so, model improvements far outweigh any
| harness or tooling.
|
| Look at https://github.com/SWE-agent/mini-swe-agent for
| proof
| prodigycorp wrote:
| Yes but people aren't choosing CC because they are
| necessarily performance maximalists. They choose it
| because it has features that make it behave much more
| nicely as a pair programming assistant than mini-swe-
| agent.
|
| There's a reason Cursor poached Boris Cherney and Cat Wu
| and Anthropic hired them back!
| aszen wrote:
| They nailed down the UX I would say and the models
| themselves are a lot better even outside of CC
| prodigycorp wrote:
| I don't think I disagree with you about anything, I'm
| trying to split hairs at this point.
| CuriouslyC wrote:
| Less true than you think. A lot of the progress in the last
| year has been tightening agentic prompts/tools and getting out
| of the way so the model can flex. Subagents/MCP/Skills are all
| pretty mid, and while there has been some context pruning
| optimization to avoid carrying tool output along forever,
| that's mainly a benefit to long running agents and for short
| tasks you won't notice.
| prodigycorp wrote:
| All of these things you mentioned are put into a footnote of
| the article.
| pama wrote:
| Agreed. You can get a better model using the codex-cli repo and
| having an agent help you analyze the core functionality.
| kirjavascript wrote:
| here's my take, in 70 lines of code:
| https://github.com/kirjavascript/nanoagent/blob/master/nanoa...
| fragmede wrote:
| I mean, if you take out the guard rails, here's codex in 46
| lines of bash: #!/usr/bin/env bash
| set -euo pipefail # Fail fast if
| OPENAI_API_KEY is unset or empty :
| "${OPENAI_API_KEY:?set OPENAI_API_KEY}"
| MODEL="${MODEL:-gpt-5.2-chat-latest}"
| extract_text_joined() { # Collect all text fields
| from the Responses API output and join them jq -r
| '[.output[]?.content[]? | select(has("text")) | .text] |
| join("")' } apply_writes() {
| local plan="$1" echo "$plan" | jq -c '.files[]' |
| while read -r f; do local path content
| path="$(echo "$f" | jq -r '.path')" content="$(echo
| "$f" | jq -r '.content')" mkdir -p "$(dirname
| "$path")" printf "%s" "$content" > "$path"
| echo "wrote $path" done } while true;
| do printf "> " read -r USER_INPUT || exit 0
| [[ -z "$USER_INPUT" ]] && continue # File list
| relative to cwd TREE="$(find . -type f -maxdepth 6
| -print | sed 's|^\./||')" USER_JSON="$(jq -n --arg
| task "$USER_INPUT" --arg tree "$TREE" \
| '{task:$task, workspace_tree:$tree, rules:[
| "Return ONLY JSON matching the schema.", "Write
| files wholesale: full final content for each file.",
| "If no file changes are needed, return files:[]"
| ] }')" RESP="$( curl -s
| https://api.openai.com/v1/responses \ -H
| "Authorization: Bearer $OPENAI_API_KEY" \ -H
| "Content-Type: application/json" \ -d "$(jq -n
| --arg model "$MODEL" --argjson user "$USER_JSON"
| '{model:$model,input:[{role:"system",content:"You output only
| JSON file-write plans."},{role:"user",content:$user}],text:{for
| mat:{type:"json_schema",name:"file_writes",schema:{type:"object
| ",additionalProperties:false,properties:{files:{type:"array",it
| ems:{type:"object",additionalProperties:false,properties:{path:
| {type:"string"},content:{type:"string"}},required:["path","cont
| ent"]}}},required:["files"]}}}')" )"
| PLAN="$(printf "%s" "$RESP" | extract_text_joined)"
| apply_writes "$PLAN" done
| ulaw wrote:
| How many Claudes could Claude Code code if Claude Code could code
| Claude?
| tuhgdetzhh wrote:
| "if Claude Code could code Claude?"
|
| Claude Code already codes Claude Code.
|
| The limit is set by the amount of GPUs and energy supply.
| handfuloflight wrote:
| The human element of the Anthropic organization also has some
| limits placed there.
| Okkef wrote:
| Claude has a nice answer to your riddle:
|
| Claude Code could code all the Claudes Claude Code could code,
| because Claude Code already coded the Claude that codes Claude
| Code.
|
| Or more philosophically: The answer is recursively infinite,
| because each Claude that gets coded can then help code the next
| Claude, creating an ever-improving feedback loop of Claude-
| coding Claudes. It's Claudes all the way down!
| nyellin wrote:
| There's a bit more to it!
|
| For example, the agent in the post will demonstrate 'early
| stopping' where it finishes before the task is really done. You'd
| think you can solve this with reasoning models, but it doesn't
| actually work on SOTA models.
|
| To fix 'early stopping' you need extra features in the agent
| harness. Claude Code does this with TODOs that are injected back
| into every prompt to remind the LLM what tasks remain open. (If
| you're curious somewhere in the public repo for HolmesGPT we have
| benchamrks with all the experiments we ran to solve this - from
| hypothesis tracking to other exotic approaches - but TODOs always
| performed best.)
|
| Still, good article. Agents really are just tools in a loop. It's
| not rocket science.
| rtgfhyuj wrote:
| why would it early stop? examples?
| embedding-shape wrote:
| Not all models are trained with long one-shot task following
| by themselves, seems many of them prefer closer interactions
| with the user. You could always add another layer/abstraction
| above/below to work around it.
| hazrmard wrote:
| This reflects my experience. Yet, I _feel_ that getting
| reliability out of LLM calls with a while-loop harness is
| elusive.
|
| For example
|
| - how can I reliably have a decision block to end the loop (or
| keep it running)?
|
| - how can I reliably call tools with the right schema?
|
| - how can I reliably summarize context / excise noise from the
| conversation?
|
| Perhaps, as the models get better, they'll approach some
| threshold where my worries just go away. However, I can't
| quantify that threshold myself and that leaves a cloud of
| uncertainty hanging over any agentic loops I build.
|
| Perhaps I should accept that it's a feature and not a bug? :)
| nyellin wrote:
| Re (1) use a TODOs system like Claude code.
|
| Re (2) also fairly easy! It's just a summarization prompt. E.g.
| this is the one we use in our agent:
| https://github.com/HolmesGPT/holmesgpt/blob/62c3898e4efae69b...
|
| Or just use the Claude Code SDK that does this all for you!
| (You can also use various provider-specific features for 2 like
| automatic compaction on OpenAI responses endpoint.)
| nyellin wrote:
| Forgot to address the easiest part:
|
| > - how can I reliably call tools with the right schema?
|
| This is typically done by enabling strict mode for tool calling
| which is a hermetic solution. Makes llm unable to generate
| tokens that would violate the schema. (I.e. LLM samples tokens
| only from the subset of tokens that lead to valid schema
| generation.)
| jackfranklyn wrote:
| The benchmark point is interesting but I think it undersells what
| the complexity buys you in practice. Yes, a minimal loop can
| score similarly on standardised tasks - but real development work
| has this annoying property of requiring you to hold context
| across many files, remember what you already tried, and recover
| gracefully when a path doesn't work out.
|
| The TODO injection nyellin mentions is a good example. It's not
| sophisticated ML - it's bookkeeping. But without it, the agent
| will confidently declare victory three steps into a ten-step
| task. Same with subagents - they're not magic, they're just a way
| to keep working memory from getting polluted when you need to go
| investigate something.
|
| The 200-line version captures the loop. The production version
| captures the paperwork around the loop. That paperwork is boring
| but turns out to be load-bearing.
| _andrei_ wrote:
| yes, it's an agent
| erichocean wrote:
| The tip of the sphere in agentic code harnesses today is to RL
| train them as dedicated conductor/orchestrator models.
|
| Not 200 lines of Python.
| aszen wrote:
| Can you elaborate on this?
| 8note wrote:
| as a comparison, the gemini cli agent with gemini 2 half the
| time writes its own tool call parameters incorrectly. it
| didnt quite know when to make a tool call, which tool result
| was the most recent(it always assumed the first one was the
| one to use, rather than the last one, when multiple reads of
| the same file were in context) etc.
|
| gemini 3 has pretty clearly been trained for this workflow of
| text output, since it can actually get the right calls in the
| first shot most of the time, and pays attention to the end of
| the context and not just the start.
|
| gemini 3 is sitting within a format of text that it has been
| trained to be in, where for gemini 2, it only had the prompt
| to tell it how to work within the tool
| libraryofbabel wrote:
| It's a great point and everyone should know it: the core of a
| coding agent is really simple, it's a loop with tool calling.
|
| Having said that, I think if you're going to write an article
| like this and call it "The Emperor Has No Clothes: How to Code
| Claude Code in 200 Lines of Code", you should _at least include a
| reference_ to Thorsten Ball 's excellent article from wayyy back
| in April 2025 entitled "How to Build an Agent, or: The Emperor
| Has No Clothes" (https://ampcode.com/how-to-build-an-agent)! That
| was (as far as I know) the first of these articles making the
| point that the core of a coding agent is actually quite simple
| (and all the _deep_ complexity is in the LLM). Reading it was a
| light-bulb moment for me.
|
| FWIW, I agree with other commenters here that you do need quite a
| bit of additional scaffolding (like TODOs and much more) to make
| modern agents work well. And Claude Code itself is a fairly
| complex piece of software with a lot of settings, hooks, plugins,
| UI features, etc. Although I would add that once you have a
| minimal coding agent loop in place, you can get it to bootstrap
| its own code and add those things! That is a fun and slightly
| weird thing to try.
|
| (By the way, the "January 2025" date on this article is clearly a
| typo for 2026, as Claude Code didn't exist a year ago and it
| includes use of the claude-sonnet-4-20250514 model from May.)
|
| Edit: and if you're interested in diving deeper into what Claude
| Code _itself_ is doing under the hood, a good tool to understand
| it is "claude-trace"
| (https://github.com/badlogic/lemmy/tree/main/apps/claude-
| trac...). You can use it to see the whole dance with tool calls
| and the LLM: every call out to the LLM and the LLM's responses,
| the LLM's tool call invocations and the responses from the agent
| to the LLM when tools run, etc. When Claude Skills came out I
| used this to confirm my guess about how they worked (they're a
| tool call with all the short skill descriptions stuffed into the
| tool description base prompt). Reading the base prompt is also
| interesting. (Among other things, they explicitly tell it not to
| use emoji, which tracks as when I wrote my own agent it was
| indeed very emoji-prone.)
| KellyCriterion wrote:
| can you show us the >>core of a coding agent which is,
| according to your words, >>really simple and would you mind
| sharing a URL so I could check it out then?
| libraryofbabel wrote:
| It's in TFA or in the https://ampcode.com/how-to-build-an-
| agent article I linked? Or is that not what you're looking
| for?
| KellyCriterion wrote:
| Sorry, sounded like "your version", instead of the one
| listed :-)
| aszen wrote:
| The most imp part is editing code, to do that reliably Claude
| models are trained on their own str replace tool schema I
| think. Models find it hard to modify existing code, they also
| can't just rewrite whole files bcz that's expensive and doesn't
| scale.
| libraryofbabel wrote:
| Yeah, there is definitely some RLVR training going on for the
| Claude LLMs to get them good at some of the specific tool
| calls used in Claude Code, I expect. Having said that, the
| string replacement tool schema for file edits is not very
| complicated at all (you can see it in the tool call schema
| Claude Code sends to the LLM), so you could easily use that
| in your own 200-300 line agent if you wanted to make sure
| you're playing to the LLM's strengths.
| aszen wrote:
| Yeah that's one example, but I suspect they train the model
| on entire sequences of tool calls, so unless you prompt the
| model exactly as them you won't get the same results.
|
| There's a reason they won the agent race, their models are
| trained to use their own tools.
| libraryofbabel wrote:
| Agree, the RLVR tasks are probably long series of tool
| calls at this point doing complex tasks in some simulated
| dev environment.
|
| That said, I think it's hard to say how much of a
| difference it really makes in terms of making Claude Code
| _specifically_ better than other coding agents using the
| same LLM (versus just making the LLM better for _all_
| coding agents using roughly similar tools). There is
| probably some difference, but you 'd need to run a lot of
| benchmarks to find out.
| embedding-shape wrote:
| Here's where I was hoping openly available models would
| shine. Some community gets together, starts sharing
| successful/failed runs with their own agent, start building a
| open dataset for their specific syntax and tooling. then
| finally finetune new variants with it for the community.
| bredren wrote:
| 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, queue-
| operation records for handling messages sent during tool
| execution, file-history-snapshots at every file modification,
| and subagent sidechains (agent-*.jsonl files) when the Task
| tool spawns parallel workers.
|
| So "200 lines" captures the concept but not the production
| reality of what is involved. It is particularly notable that
| Codex has yet to ship queuing, as that product is getting
| plenty of attention and still highly capable.
|
| I have been building Contextify (https://contextify.sh), a
| macOS app that monitors Claude Code and Codex CLI transcripts
| in real-time and provides a CLI and skill called Total Recall
| to query your entire conversational history across both
| providers.
|
| I'm about to release a Linux version and would love any
| feedback.
|
| [1] With the exception of Claude Code Web, which does expose
| "sessions" or shared transcripts between local and hosted
| execution environments.
| Johnny_Bonk wrote:
| This is very interesting, especially if you could then use an
| llm across that search to figure out what has and maybe has
| not been completed, and then reinject those findings into a
| new Claude code session
| handfuloflight wrote:
| For that you'd be better off having the LLM write TODO
| stubs in the codebase and search for that. In fact, most of
| the recent models just do this, even without prompting.
| bredren wrote:
| I haven't written the entry yet but it is pretty incredible
| what you can get when letting a frontier model RAG your
| complete CLI convo history.
|
| You can find out not just what you did and did not do but
| why. It is possible to identify unexpectedly incomplete
| work streams, build a histogram of the times of day you get
| most irritated with the AI, etc.
|
| I think it is very cool and I have a major release coming.
| I'd be very appreciative of any feedback.
| jake-coworker wrote:
| IMO these articles are akin to "Twitter in 200 lines of
| code!" and "Why does Uber need 1000 engineers?" type
| articles.
|
| They're cool demos/POCs of real-world things, (and indeed are
| informative to people who haven't built AI tools). The very
| first version of Claude Code probably even looked a lot like
| this 200 line loop, but things have evolved significantly
| from there
| rcarmo wrote:
| I think mine have a little more code, but they also have a lot
| more tools:
|
| - https://github.com/rcarmo/bun-steward
|
| - https://github.com/rcarmo/python-steward (created with the
| first one)
|
| And they're self-replicating!
| dana321 wrote:
| 200 lines of yuck, why do people program this shitty language?
| tomhow wrote:
| Please don't fulminate on HN. The guidelines make it clear
| we're trying for something better here.
| https://news.ycombinator.com/newsguidelines.html
| ofirpress wrote:
| We (the SWE-bench team) have a 100 line of code agent that is now
| pretty popular in both academic and industry labs:
| https://github.com/SWE-agent/mini-swe-agent
|
| I think it's a great way to dive into the agent world
| oli5679 wrote:
| https://github.com/mistralai/mistral-vibe
|
| This is a really nice open source coding agent implementation.
| The use of async is interesting.
| tptacek wrote:
| What's interesting to me about the question of whether you could
| realistically compete with Claude Code (not Claude, but the CLI
| agent) is that the questions boil down to things any proficient
| developer could do. No matter how much I'd want to try, I have no
| hope of building a competitive frontier model --- "frontier
| model" is a distinctively apt term. But there's no such thing as
| a "frontier agent", and the Charmbracelet people have as much of
| a shot at building something truly exception as Anthropic does.
| embedding-shape wrote:
| > No matter how much I'd want to try, I have no hope of
| building a competitive frontier model
|
| A single person, probably not. But a group of dedicated FOSS
| developers who together build a wide community contributing to
| one open model that could be continuously upgraded? Maybe.
| maurycy wrote:
| Maybe not necessarily and the Claude model is fine-tuned for
| `claude`, so no one can really replicate the experience without
| unlocking some secret mode in the model. The other comments
| about editing files hint at this.
| libraryofbabel wrote:
| This is a great point, although I would add that Anthropic has
| a possible _slight_ advantage, as they can RLVR the Claude LLMs
| themselves on Claude Code tool calls and Claude Code tasks.
| Having said that, it 's not clear how much that really matters
| at all for making the Claude Code CLI _specifically_ better-
| performing than other coding agents using the same LLM (the
| tool calls are fairly generic and the LLMs are good at plenty
| of tool calls they weren 't RLVRed on too).
|
| The other advantage Anthropic have is just that they can sell
| CC subscriptions at lower cost because they own the models. But
| that's a separate set of questions that don't really relate to
| technical capabilities.
|
| Anyhow, to follow up on your point, I do find it surprising
| that Claude Code is still (it seems?) definitively leading the
| pack in terms of coding agents. I've tried Gemini CLI and Codex
| and they feel distinctly less good, but I'm surprised we
| haven't seen too many alternatives from small startups or open
| source projects rise to the top as well. After all, they can
| build on all the lessons learned from previous agents (UX,
| context management, features people like such as Skills etc.).
| Maybe we will see more of this in 2026.
| NitpickLawyer wrote:
| > the Charmbracelet people have as much of a shot at building
| something truly exception as Anthropic does.
|
| Yes and no. OpenCode is a great example of yes. But at the same
| time Anthropic gets to develop both client and model together.
| THey get to use the signals from the client, and "bake in" some
| of the things into the model. So their model will work best
| with their client. And somewhat less competent with other
| clients (you can kinda sorta see that today with opus in cc vs.
| in cursor).
|
| For example, cc was (to my knowledge) the first client to add
| <system_reminder> tags from time to time. How often, how the
| model used them and so on? That's basically "signals", and they
| work together. And it works beautifully, as cc _seems_ to stay
| on task better than OpenCode while using the same model.
| tptacek wrote:
| Anthropic has obvious advantages and I'm not saying there's a
| level playing field (they also have the financial resources
| of a mid-sized industrialized nation). I'm saying that
| there's an absolute limit to how much work you could
| personally do on a frontier model, and that limit doesn't
| exist for agents; you could realistically clever your way out
| ahead of Claude Code --- who knows? We've only had these
| things working for real for a year.
| nxobject wrote:
| I'll admit that I'm tickled pink by the idea of a coding agent
| recreating itself. Are we at a point where agents can
| significantly and autonomously improve themselves?
| lmeyerov wrote:
| 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 -- most seem to focus on
| whether to use plan mode or not, but todo lists will still be
| active. I ran a fun experiment last month on how well claude code
| solves CTFs, and disabling the TodoList tool and planning is 1-2
| grade jumps: https://media.ccc.de/v/39c3-breaking-bots-cheating-
| at-blue-t... .
|
| Fwiw, I found it funny how the article stuffs "smarter context
| management" into a breeze-y TODO bullet point at the end for
| going production-grade. I've been noticing a lot of NIH/DIY types
| believing they can do a good job of this and then, when forced to
| have results/evals that don't suck in production, losing the rest
| of the year on that step. (And even worse when they decide to
| fine-tune too.)
| btown wrote:
| I'm unsure of its accuracy/provenance/outdatedness, but this
| purportedly extracted system prompt for Claude Code provides a
| lot more detail about TODO iteration and how powerful it can
| be:
|
| https://gist.github.com/wong2/e0f34aac66caf890a332f7b6f9e2ba...
|
| https://gist.github.com/wong2/e0f34aac66caf890a332f7b6f9e2ba...
|
| I find it fascinating that while in theory one could just
| append these as reasoning tokens to the context, and trust the
| attention algorithm to find the most recent TODO list and
| attend actively to it... in practice, creating explicit tools
| that essentially do a single-key storage are far more effective
| and predictable. It makes me wonder how much other low-hanging
| fruit there is with tool creation for storing language that
| requires emphasis and structure.
| lmeyerov wrote:
| I find in coding + investigating there's a lot of mileage to
| being fancier on the todo list. Eg, we make sure timestamps,
| branches, outcomes, etc are represented. It's impressive how
| far they get with so little!
|
| For coding, I actually fully take over the todo list in codex
| + claude: https://github.com/graphistry/pygraphistry/blob/mas
| ter/ai/pr...
|
| In Louie.ai, for investigations, we're experimenting with
| enabling more control of it, so you can go with the grain, vs
| that kind of wholecloth replacement
| bdangubic wrote:
| at the end of the year than you get "How to Code Claude Code in
| 200 Million Lines of Code" :)
| matchagaucho wrote:
| The TODO lists are also frequently re-inserted into the context
| HEAD to keep the LLM aware of past and next steps.
|
| And in the event of context compression, the TODO serves as a
| compact representation of the session.
| afarah1 wrote:
| Reminds me of this 2023 post "re-implementing LangChain in 100
| lines of code": https://blog.scottlogic.com/2023/05/04/langchain-
| mini.html
|
| We did just that back then and it worked great, we used it in
| many projects after that.
| prodigycorp wrote:
| How was this three years ago ;_;
| m-hodges wrote:
| Also relevant: You Should Write An Agent1 and, How To Build An
| Agent.2
|
| 1 https://fly.io/blog/everyone-write-an-agent/
|
| 2 https://ampcode.com/how-to-build-an-agent
| johnsmith1840 wrote:
| Here's the bigger question. Why would you?
|
| Claude code feels like the first commodity agent. In theory its
| simple but in practice you'll have to maintain a ton of random
| crap you get no value in maintaining.
|
| My guess is eventually all "agents" will be wipped out by claude
| code or something equivalent.
|
| Maybe not the companies will die but that all those startups will
| just be hooking up a generic agent wrapper and let it do its
| thing directly. My bet is that that the company that would win
| this is the one with the most training data to tune their agent
| to use their harness correctly.
| mudkipdev wrote:
| Is this not using constrained decoding? You should pass the tool
| schemas to the "tools" parameter to make sure all tool calls are
| valid
| floppyd wrote:
| > 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 "knows" how to call a tool, it's a program, but LLMs
| just produce text! Yes I see you are telling LLM about tools, but
| what's next? And then when I finally understood that there's no
| next, no need to do anything other than explaining -- it felt
| pretty magical, not gonna lie.
| duncancarroll wrote:
| > "But here's the thing"
|
| This phrase feels like the new em dash...
| OsrsNeedsf2P wrote:
| Yea.. our startup greatly overestimated how hard it is to make a
| good agent loop. Handling exit conditions, command timeouts,
| context management, UI, etc is surprisingly hard to do
| seamlessly.
| cadamsdotcom wrote:
| The devil is in the details, so actually, the Emperor in this
| analogy most definitely does have clothes.
|
| For example, post-training / finetuning the model specifically to
| use the tools it'll be given in the harness. Or endlessly
| tweaking the system prompt to fine-tune the model's behavior to a
| polish.
|
| Plus - both OpenAI and Qwen have models specifically intended for
| coding.
| joshmlewis wrote:
| This is cool but as someone that's built an enterprise grade
| agentic loop in-house that's processing a billion plus tokens a
| month, there are so many little things you have to account for
| that greatly magnify complexity in real world agentic use cases.
| For loops are an easy way to get your foot in the door and is
| indeed at the heart of it all, but there are a multitude of a
| little things that compound complexity rather quickly. What
| happens when a user sends a message after the first one and the
| agent has already started the tool loop? Seems simple, right? If
| you are receiving inputs via webhooks (like from a Slack bot),
| then what do you do? It's not rocket science but it's also not
| trivial to do right. What about hooks (guardrails) and approvals?
| Should you halt execution mid-loop and wait or implement it as an
| async Task feature like Claude Code and the MCP spec? If you do
| it async then how do you wake the agent back up? Where is the
| original tool call stored and how is the output stored for
| retrieval/insertion? This and many other little things add up and
| compound on each other.
|
| I should start a blog with my experience from all of this.
___________________________________________________________________
(page generated 2026-01-08 23:00 UTC)