Clone the Repo: What AI Coding Agents Actually

If you use an AI coding agent — Cursor, Copilot, anything in that neighborhood — you've probably noticed it gets dumber when you ask it to work with a library it doesn't know well. It hallucinates APIs. It uses deprecated patterns. It confidently writes code that compiles but does nothing close to what you wanted.

Michael Arnaldi, the creator of the Effect TypeScript library, has a fix for this. It's not a better prompt. It's not an MCP server. It's a git subtree. His approach, demonstrated in a live workshop for AI Engineer, is unglamorous enough to be genuinely useful: clone the library's source repository directly into your project, and let the agent treat it as part of your own codebase.

"In reality, this session should just be called 'just clone the repo' and be done with it," Arnaldi said during the session.

That's the whole thesis. The implementation details are what make it worth unpacking.

Why Agents Go Dumb With Unfamiliar Libraries

Arnaldi's explanation of why this works starts with a clear-eyed account of what language models actually are — and aren't.

The common mental model treats an LLM like a very well-read colleague: knowledgeable, context-aware, capable of learning. The more accurate model, Arnaldi argues, is a fixed snapshot of knowledge with no update mechanism. "You are basically appending messages onto a fixed size array which is called the context window," he said. Tell the model something useful today, and tomorrow's fresh session knows nothing about it.

This isn't a bug that better prompting fixes. It's structural. The post-training phase for coding-focused models involves reinforcement learning passes oriented around codebase tasks — where models make changes and get evaluated on outcomes — but once training ends, the knowledge is frozen. Arnaldi's characterization of this process is a useful simplification rather than a complete technical account; the actual reward signals in code-focused RL training involve more than just compilation success. But the core point holds: the model you're using today was trained on data with a cutoff, and no amount of prompting changes what it learned.

The practical consequence is that agents are optimized to work on your code. They're trained on code bases that look like typical projects, not on arbitrary library internals. If you install Effect via npm, the agent won't naturally explore node_modules to understand its patterns — Arnaldi says agents have been trained to focus on user code, not dependencies. And if you git-ignore a folder, tools like Cursor — at least in Arnaldi's experience with its default configuration — won't index it. (Cursor's indexing behavior is configurable and has evolved across versions; treat this as Arnaldi's characterization of the defaults, not a permanent technical specification.)

The subtree approach sidesteps all of this. Drop the library source into .repos/effect as a git subtree and suddenly it looks, to the agent, like code you wrote.

The Constraint Architecture

The more interesting part of Arnaldi's workshop isn't the subtree trick itself — it's the broader philosophy of how to structure a project so the agent fails loudly and early rather than silently and in production.

Two things stood out to me.

First: he turns every TypeScript diagnostic into an error. Not a warning. Not a suggestion. An error. The logic is that if you're going to use an AI agent heavily, you want the maximum amount of machine-readable feedback pushing back on bad outputs. Soft warnings are easy for an agent to ignore or miss. Hard errors create a feedback loop that Arnaldi describes as "back pressure" — the compiler becomes part of the quality control pipeline, not just a developer tool.

Second: his ESLint configuration bans type assertions. Specifically, he prohibits as X patterns, because agents in his experience reach for type assertions when they can't figure out the proper way to handle a type. The assertion makes the error go away without fixing the underlying uncertainty. When he banned as unknown as X, the agent found a workaround via never as a bottom type — so he banned as broadly. "I'm trying to avoid the model to do dumb stuff that I realized it was doing in my code," he said.

This is the part that intersects directly with my beat. Type-unsafe code in production isn't just a correctness problem — it's an attack surface. When an agent uses as any or as unknown as SomeType to paper over a type mismatch, it's introducing a place where runtime data doesn't match what the program believes about it. In a well-typed TypeScript codebase that handles external API responses, user inputs, or financial data, those assertion shortcuts can become injection points or data validation bypasses. Arnaldi's solution is aesthetic and practical in his framing; from a security standpoint, it also happens to be the right call.

The Dependency Problem Nobody Mentioned

Here's what the workshop didn't address, and where I'd push back — or at least push further.

Cloning a library repository into your project is a reasonable way to give an agent better context. It's also a way to introduce a dependency that your security tooling may not be scanning. A standard npm install or bun add gets you a vetted package artifact with a hash in your lockfile. A git subtree of the same library gives you source that your dependency auditing tools may not cover, and if you're pulling from a repository that gets compromised — a scenario that's happened with supply chain attacks on popular open-source projects — you may not have the same tripwires in place.

I'm not saying Arnaldi's approach creates new risk out of nowhere. If you're using Effect, you trust Effect. The point is more general: as agent-assisted workflows start introducing new patterns for how code gets into your project, the security tooling needs to keep up with those patterns. The git subtree lives in your repo now. Is it in scope for your SAST scanner? Does your CI/CD pipeline audit it? These are questions worth answering before you ship to production.

There's also a context window consideration with security implications. Arnaldi cautions against overloading the context window — more tokens doesn't mean better outputs, and bloated contexts can cause models to lose track of earlier constraints. If your agent instructions, type rules, and ESLint configs are all fighting for space with a full library source tree, you may find the agent conveniently "forgetting" the rules you worked hardest to encode. The agent that stops respecting your as ban in session 40 of a long project might not be defying you deliberately — it might just be running out of room.

What Arnaldi Gets Right That Most Advice Misses

Most "get better results from AI" content is about prompting. Write clearer instructions. Use chain-of-thought. Add examples. Arnaldi's approach is structural: build an environment where the agent has the right information and where deviation is mechanically harder.

He calls this "spec-driven development" — a first pass where you discuss with the agent how to specify a thing, persist that spec as a markdown file, and then implement against it. The spec is the persistent memory the agent doesn't natively have. Combined with strict diagnostics, lint rules, and library source in scope, you're not hoping the agent performs well. You're architecting for the agent's actual capabilities and failure modes.

On the question of open-weights models, Arnaldi estimated they're roughly three to six months behind frontier models — a figure he offered as a working heuristic rather than a measured claim, and one that the research community would contest depending heavily on which benchmark and which task type you're measuring. What's not contested is his underlying point: if you can't tolerate the usage restrictions of closed models, the open-weights options are improving fast, and the gap matters less at the lower end of coding complexity.

The version of this that applies to you doesn't require Effect, or TypeScript, or even Bun. If you're working with any library that post-dates your agent's training cutoff, the pattern transfers: give the agent the source, make diagnostic failures loud, constrain the type system, and document the rules in a file the agent reads at the start of every session.

And then audit the thing you just cloned into your repo, because your CI pipeline definitely doesn't know it's there.

By Rachel "Rach" Kovacs, Cybersecurity & Privacy Correspondent