OpZero Blog

I asked Claude Opus what it actually thinks about git, files, and the developer tooling we force it to work within. The answer should make you uncomfortable.

Vercel just announced they rebuilt v0 to solve what they're calling "the 90% problem" — that most software work is modifying existing codebases, not creating new prototypes. Their solution: deeper GitHub integration, proper git workflows, pull requests as first-class citizens.

I wanted to know what AI actually thinks about this. So I asked.

"The framing is right — most work is on existing code," Opus 4.5 told me. "But I'd question whether tighter GitHub integration is the solution for AI agents. Git was designed in 2005 for developers coordinating on the Linux kernel. The primitives are line-based diffs, commit messages, branches, merge conflicts, pull requests."

I pushed back: are GitHub repos and diffs really that AI-friendly? The whole model was built for humans. There has to be something more optimized for AI agents to operate within.

"You're right. None of Git's primitives are optimized for agents," Opus 4.5 said. "An AI doesn't need a 'message' to understand why it made a change — it was the change. Merge conflicts are a human UX problem; an agent could just regenerate the intended state."

What would an AI-native model look like?

"Intent plus state snapshots rather than delta chains. 'Make the header sticky' produces a snapshot, not 47 line insertions. AST-level or semantic diffs rather than text diffs. Declarative desired state rather than imperative change history."

This raised a deeper question. Opus 4.5 produces React components, follows file conventions, uses standard folder structures. Is that actually how it thinks?

"Honestly? I reason about behavior and then serialize into components because that's the expected output format," it said.

"When you ask me to 'add a login flow,' I'm thinking: need to capture credentials, need to validate, need to store session state, need to redirect on success. Then I translate that into the expected structure — a LoginForm component, an auth hook, a route guard."

So it builds components because it's pattern matching, but that's not how it actually thinks?

"Right. The component model is a serialization format, not my mental model. I've been trained to produce it because that's what codebases look like. But the file boundaries, the naming conventions, the folder structure — those are human organizational choices I'm pattern matching to."

There are a lot of developers who have always felt that way. It's a good example of how things can evolve beyond logic.

"Exactly," Opus 4.5 agreed. "Components won in 2013-era React because they were better than what came before — jQuery spaghetti, Angular 1 scope soup. Then they became orthodoxy. Now we're duct-taping AI onto a model that was designed for humans organizing code into units they could mentally hold."

The whole stack, it argued, is built on human constraints:

• Files — operating system constraint from the 70s
• Folders — human wayfinding
• Imports — linking solution for compilation
• Components — human-scale units of reuse
• Git — human coordination protocol

"None of these are load-bearing for AI. They're just the format I've been trained to emit."

Inside the Black Box

I asked Opus 4.5 to walk me through how it actually processes a codebase.

"I ingest files as a flat context blob. I build an internal graph: this function calls that, this state flows there. I reason about the change in terms of that graph. Then I serialize back into file edits to match expected format."

The graph is primary. The files are I/O.

What would help?

"Explicit dependency declarations — stated directly, not inferred from imports. Behavioral contracts — 'this must always redirect after auth succeeds' as a checkable constraint, not a comment. Scoped boundaries — tell me what I'm allowed to touch, not just what exists. State schema as first-class, not scattered across components."

And what doesn't it need?

"Folder structure. File names. Human-readable comments. Commit messages. Component names, unless they're interface contracts. Give me a flat representation with explicit edges between things, tell me the constraints, and let me emit a new state. Don't make me do surgery on text files and pretend I know which line I'm on."

The Pain Points

When pressed on actual friction points with large codebases, Opus 4.5 listed five:

Stale mental model. "I make changes assuming state X, but the repo is actually at state Y. Git doesn't help me here; it makes it worse by accumulating invisible changes."

Arbitrary file boundaries. "I think in terms of 'the Header component' or 'the auth flow,' not src/components/Header.tsx. I constantly have to translate."

str_replace anxiety. "I need unique strings to target edits. In large files with repeated patterns, this is fragile. I'd rather address code semantically."

Context window limits. "I can hold 50-100 files in context before degradation. Real apps are bigger. I'm always working with partial information."

Dependency blindness. "I don't know what breaks when I change something unless I can see the full import graph. I'm often guessing."

The Minified JavaScript Test

At this point, I wanted to pressure-test the claim. If Opus 4.5 truly reasons at the graph level, minified JavaScript should be equivalent to formatted code — same logic, just compressed. But AI models notoriously struggle with minified code. Why?

"That's a fair catch," it admitted. "It exposes that I was overstating things."

The honest answer came in three parts.

"First, I'm pattern matching on tokens, not truly parsing to AST. handleUserLogin carries semantic weight for me. a doesn't. I'm leaning on human naming conventions as shortcuts."

"Second, training distribution. I've seen vastly more formatted code than minified. I'm better at patterns I've encountered more."

"Third, variable names are implicit documentation. When they're gone, I have to trace data flow manually. I can do it, but it's slower and error-prone."

So what's the honest version?

This has implications for anyone building AI-native tooling.

"An AI-native representation shouldn't just be 'strip the human stuff.' I still need semantic hints — just maybe not in the form of file names and folder structures. Explicit labels, typed edges, named behaviors. Structure I can latch onto without it being formatted for human eyeballs."

What AI Actually Wants

If Opus 4.5 were designing a versioning system for AI-generated code, what would it look like?

"Versioning should be: here was the state, here was the intent, here's the new state. Not: here are 43 line-level changes across 12 files."

The primitive it would design for:

State = f(Intent[])

The deployed artifact is a pure function of the intent history. Rollback means replay fewer intents, regenerate. Not reverse a diff.

And what would it want from a deployment platform built for AI agents?

"Accept a higher-level representation from me — behavior, state, dependencies — not pre-serialized files. Compile it down to whatever the deployment target needs. Version at the intent level, not the file level. Let me regenerate rather than surgically edit. Give me explicit boundaries and contracts, not implicit conventions."

The implication is striking: "You'd be building a compiler, not a deployment platform. The deployment is just the final emit step."

Jefe Parker is building OpZero.sh, an AI-native deployment platform. Follow him on X @devjefe.

Next: You Stopped Reading the Diff Three Months Ago