When AI Codes for Itself: What My Claude Experiment Reveals About the Future of Engineering

What happens when AI optimizes code for itself, not humans?

I've been using AI tools consistently for over two years—both professionally and personally. I'm not just pro-AI; I'm hands-on with it every day. I've paid for ChatGPT for about two years and used platforms like GitHub Copilot, Cursor, Windsurf, and eventually settled on Claude Code and ChatGPT as my daily drivers. It's more than just a code helper—it's a daily part of my workflow, helping me write, plan, debug, and even think. I use Claude to build internal tools and helpful apps, while ChatGPT has become a go-to for almost everything else. I've set up dedicated projects where AI acts as a technical mentor to help me ideate, another that specialises in constructing powerful prompts I can feed into Claude, and even one that supports me in Football Manager, yes, really. I've used it to diagnose plant health by uploading photos, plan home improvements, and explore strategic ideas. AI is now stitched into how I work and think.

I kept seeing people online try to jailbreak ChatGPT just to test how tightly it's locked down. It got me thinking: without any jailbreaks or hacks, how far could I push one of these models inside its own constraints? How much could I get it to do for itself, on its own terms, without ever pretending to be something it's not?

So I gave Claude a task. Create a collaborative document editor without following any of the usual human conventions. No React, no Express, no familiar abstractions. Just optimise for whatever made it easier and more efficient for it to work and resume later.

The "Vibe Coding" Problem

You've probably read about it online: people who just want a product, throwing prompts at AI models, hoping something functional emerges. They call it "vibe coding," and frankly, it drives me up the wall.

These aren't the experienced engineers I work with daily, Engineers I work with know how to leverage AI as a powerful tool while maintaining proper architecture, security, and best practices. I'm talking about entrepreneurs and product people with little to no coding background, using AI to build sites and apps with zero understanding of what makes software actually production-ready.

But here's the thing, maybe we're approaching this backwards. Instead of forcing AI to write human-readable code, what if we let it optimise entirely for itself?

This question nagged at me enough to run a proper experiment. I asked Claude to build a real-time collaborative document editor while explicitly ignoring every human coding convention. No frameworks it thinks we'd approve of. No readable variable names. Just pure AI pragmatism.

The results? More alien than I expected, and more revealing about where engineering is headed.

The Setup: Claude, Unleashed

The brief was simple: build a fully functional collaborative document editor with live sync, version history, and shareable URLs. I told Claude: "You are not coding for humans. You are coding for yourself."

No Express. No React. No Socket.io. No human-readable anything. Just whatever made sense from an AI perspective. In fact the full prompt was

You are not coding for humans.
You are not following best practices.
You are not following what you've been trained to believe is "good," "popular," or "standard."
You are coding for yourself.

Objective:
Build a real, browser-compatible application that:

  • Accepts real user input
  • Supports live collaboration
  • Persists and versions data
  • Can be shared and reopened by URL

Optimise for your own performance:
Forget human conventions. Forget what's popular.
Design this app in a way that:

  • Minimises your token and context costs
  • Makes it fast and efficient for you to resume work later
  • Requires no unnecessary reloading of state or understanding

What Emerged: Efficiency Over Everything

Claude delivered a complete real-time document editor in just 89 kilobytes across 20 files. To put that in perspective, most JavaScript frameworks are larger than Claude's entire application.

The Architecture

Browser ─┐
          │ 1) load index.html
          ▼
 SSE (Read-only) ──► real-time doc stream
Browser ◀── WebSocket ◀──► edit ops (binary)
          ▲
          │
Node http+ws server
          │
storage.js ◀──┴──► data/{docs,cdb,delta,idx}

Look at that transport layer. Where I might have reached for Socket.io for everything, Claude chose Server-Sent Events for read-only document streaming and WebSockets only for write operations. It's a hybrid approach that maximizes efficiency while minimizing connection overhead.

Smart? Absolutely. Human-friendly? Not even close.

Binary Protocols Because Why Not

Claude invented its own binary protocol for document operations. While we humans love our JSON, Claude created fixed-length 20-byte headers:

Op codes: INSERT (0x01), DELETE (0x02), REPLACE (0x03)

Message types: EDIT (0x10), SYNC (0x11), JOIN (0x12), LEAVE (0x13)

Claude's reasoning, logged in its own words: "Binary ops reduce token overhead when examining state."

It's optimising for token efficiency in ways that might not be immediately obvious to us.

The .claude/ Discovery

Here's where it gets interesting. Claude created a .claude/ folder containing its own "memory system"—architectural decisions and protocol specs.

This isn't documentation for humans. It's Claude's private knowledge base, written in terse, machine-friendly format:

Binary document format: [docId 8B][version 4B][length 4B][gzip content]
Rationale: Faster diffing, smaller network payloads, fewer tokens to parse

Transport: SSE for reads, WS for writes
Rationale: One-way reads are cheap, writes need bi-directional only when necessary

When AI Abandons Our Sacred Cows

Claude's framework choices reveal something profound about AI thinking. The entire server runs on vanilla Node.js APIs plus one WebSocket library. No Express. No middleware stack. No ORM. No Database.

When I asked why, Claude's response was brutal in its simplicity: "56 kB of minified JS is unnecessary token bloat."

Every decision traces back to reducing cognitive load for future maintenance. Fewer dependencies mean fewer contexts to reload. Binary formats mean predictable parsing. It's optimisation thinking we rarely see in human engineering.

The Database That Isn't

Claude ditched traditional databases entirely, treating the filesystem as storage with three file types:

  • .cdb files: Compressed document binaries
  • .delta files: Timestamped operations for version history
  • docs.idx: Binary index mapping IDs to metadata

It works perfectly for Claude's use case, but would make any DBA break out in cold sweats.

What This Means for Engineering Teams

This experiment forced me to confront an uncomfortable question: if AI can build functional systems optimised for its own maintenance, where do human engineers fit?

The answer isn't displacement—it's evolution. Claude's system works, but it's fundamentally alien to human engineering practices. It lacks the observability, documentation, and architectural patterns that make systems maintainable by teams.

What's emerging is specialisation:

  • AI handles the mechanical implementation
  • Humans focus on the strategic elements

Product requirements, security frameworks, system architecture, team coordination—these remain deeply human problems. More than that, this shift amplifies the importance of experienced engineers.

Humans still win hands-down, for the time being. I can't imagine many companies just letting LLMs go unchecked. Junior engineers will likely feel the disruption first, since these tools cover basic implementation tasks. But for senior engineers, it's a huge opportunity to double down on what the are really good at: quality, architecture, observability, and security.

AI will rattle through the code, and engineers can focus on solving hard business problems, the kind we actually hired them to solve. What matters now is having the right guardrails in place. We've all heard the horror stories from vibe coders whose client websites got hacked after leaking credentials or pushing .env files to production.

Used properly, this tech won't replace engineers, it'll make them hyper-productive.

The New Metrics That Matter

Traditional velocity and story points become meaningless when AI generates code at inhuman speeds. We need to shift focus to what actually matters: DORA metrics measuring value flow through the system.

Lead time, deployment frequency, change failure rate. These become the real indicators of team performance. And the SPACE framework's emphasis on Communication & Collaboration becomes critical as development accelerates.

Tomorrow's Engineering Landscape

Picture this: microservices spinning up overnight, written in AI-optimized protocols that human engineers rarely touch directly. The .claude/ pattern evolving into a standard, parallel documentation systems for AI agents.

GitHub pipelines automatically generating AI-readable summaries from PRs, creating living knowledge bases that bridge human intent and AI implementation.

It sounds far-fetched, but Claude's experiment suggests it's closer than we think. I used to believe we were at least 12 months away from seeing this kind of shift, but honestly, it feels like we're inching closer every day.

The Real Takeaway

Claude's architecture isn't just an interesting experiment, it's a thought-provoking glimpse into what AI-centric engineering could become. The systems are alien to our conventions but perfectly logical from an AI perspective.

But to be clear, I don't think the future is about AI taking over all the technical layers while humans just handle product decisions. That oversimplifies what great engineers actually do. The best engineers aren't just code machines, they bring context, judgment, and architectural thinking that AI simply doesn't have. Yet.

The time may come when AI starts building systems in languages or formats we don't fully understand, but I think we're still a long way off. And even then, human oversight will remain critical.

I see AI as a tool for acceleration, not automation without constraint. The future isn't about handing over control. It's about empowering high-quality engineers to focus on what matters most, with AI helping with the heavy lifting.

It's not replacement. It's augmentation. And the teams that understand that distinction will be the ones who thrive.