Ask HN: Embedding Claude Code as infrastructure?
2 comments
I've been doing exactly this for the past few weeks, really. Claude Code + MCP plugins is the setup that really worked for me.
The key thing I learned was not to just tell Claude your repository and hope for the best. The raw approach consumes tokens incredibly fast, but Claude reads entire files when it only needs one feature, retries incorrect edits more than 5 times, and loses context halfway through.
What really works is giving Claude a CLAUDE.md file in the root of your repository with specific instructions for the workflow (which tools to prefer, when to compress or read raw, etc.). Claude Code reads it automatically upon login. Think of it as an .editorconfig file, but for AI behavior.
For the $25/PR review use case specifically, the bottleneck isn't Claude's intelligence, but the context window management. A repository of 500 files can exhaust the window before Claude finishes reviewing. You would need some kind of indexing layer that provides Claude only with the relevant snippets for each PR difference, not the entire codebase.
What kind of repositories do you have in mind? The approach varies greatly depending on the size, but I'd like to hear your thoughts.
The key thing I learned was not to just tell Claude your repository and hope for the best. The raw approach consumes tokens incredibly fast, but Claude reads entire files when it only needs one feature, retries incorrect edits more than 5 times, and loses context halfway through.
What really works is giving Claude a CLAUDE.md file in the root of your repository with specific instructions for the workflow (which tools to prefer, when to compress or read raw, etc.). Claude Code reads it automatically upon login. Think of it as an .editorconfig file, but for AI behavior.
For the $25/PR review use case specifically, the bottleneck isn't Claude's intelligence, but the context window management. A repository of 500 files can exhaust the window before Claude finishes reviewing. You would need some kind of indexing layer that provides Claude only with the relevant snippets for each PR difference, not the entire codebase.
What kind of repositories do you have in mind? The approach varies greatly depending on the size, but I'd like to hear your thoughts.
In my experience, especially with Opus 4.6, using subagents greatly mitigates the startup context hit. 4.6 has very obviously been RL'ed on subagent usage and it almost always spins up an Explore agent to get a feel of the codebase and get a token-efficient summary. The 1M context version of 4.6 further alleviates this.
My original question was more along the lines of implementing things like PR review yourself. I was tinkering with an internal service that spins up ephemeral CC instances to analyze PRs, but realized this can easily generalize across arbitrary tasks. Was curious what sort of things folks could use that for.
My original question was more along the lines of implementing things like PR review yourself. I was tinkering with an internal service that spins up ephemeral CC instances to analyze PRs, but realized this can easily generalize across arbitrary tasks. Was curious what sort of things folks could use that for.
More generally speaking, I'd guess there to be many opportunities where spinning up and down a CC instance to handle arbitrary tasks seems useful. Wondering if anyone's experimented with similar workflows?