What weeks of intensive Claude Code usage taught me

After several weeks using Claude Code as my primary development tool, here’s what I’ve learned — and this is just the tip of the iceberg:

An agent without a system is an intern who starts from scratch every morning.

Just a few months ago, I was convinced the key was prompting. I was wrong. The key is the infrastructure you build around the models.

Here are the 7 levers that changed everything for me:

Memory is the essential foundation. Not conversation memory — the AI handles that. I’m talking about structured memory: who I am, how I work, past decisions, mistakes not to repeat. An agent that remembers your preferences, your patterns, your business context — that’s an agent that accelerates instead of asking the same questions over and over.
The “onion layer” architecture. An agent’s instructions should stack in layers: e.g. global instructions → project instructions → specialized skills → conversation context. Each layer adds precision without rigidity. This is what allows the same agent to work on an Angular technical migration in the morning and run a market study in the afternoon — with the right level of specialization each time.
Continuous self-improvement. The real power: the agent improves its own skills. A workflow fails? The agent fixes the skill. An output isn’t up to standard? You adjust the instructions. Cross-model assessment, feedback loops, prompt iterations — the agent gets better with each interaction, not just within a conversation, but from one session to the next.
Connecting tools together. This is where it gets powerful — dizzying, even. Imagine a dozen of your favorite tools — connected together. The agent doesn’t “know how to code.” It knows how to orchestrate a system, add its value at every stage of the rocket, and leave room for yours at the critical decision points.
Two types of memory, two purposes. This was one of my best discoveries: after several exchanges and iterations, I established a convention system with my agents to better structure memory management: there’s the AI’s memory (technical context, code patterns, conventions, agent character, etc.) and my memory (decisions, research, insights, goals, etc.). Separating the two was a game-changer. The dance between Claude/Gemini and Obsidian plays the role of hippocampus in this ecosystem.
AI guidelines in every project. Every repo has its AI instruction file. Conventions, patterns to follow, mistakes to avoid, business context — everything is versioned both within the relevant projects and as an independent repository shared across all projects.
E2E tests as an indispensable safety net. The more autonomy you give the agent, the more critical end-to-end tests become. AI codes fast, refactors fast, touches many files in a single pass. Without a solid E2E suite, you move fast… into a wall. With one, a team of agents can iterate aggressively — break, fix, re-test — in a loop. E2E testing isn’t a nice-to-have; it’s what makes agentic autonomy viable. Bonus: the interactions between specs ↔ E2E tests are also a superb opportunity to create a virtuous cycle.

Bonus — Dare to try counter-intuitive “hacks”

The AI ecosystem evolves so fast that the “standard” method isn’t always the right one.

A concrete example: to capture web pages and interact with a browser, the obvious approach is to use an MCP Chrome DevTools server. In practice? Unstable connections, limitations, timeouts. The solution that works better: code a small Playwright script from scratch — lighter, more reliable, cheaper in tokens.

The takeaway?

An AI agent is nice, but without a system it’s worthless. The value doesn’t come from the model — it comes from the ecosystem you build around it.