For my compas ❤️✌️❤️

There's a lot of fervor right now in criticizing AI progress. I understand all the reasons floating around, some I agree with, others I don't. I'm concerned about the concentration of high-quality AI offerings in a few companies, all from the global north. I'm glad China is competing in an "open source" manner. I'm worried this won't always be the case. Because this matters to me, I collaborate as much as I can with the Fundación de Desarrollo Humano Integral, the best political decision I've ever made.

Now, the only truth is reality, and it's clear that programming and therefore everything programmable has changed forever. We can discuss the how, the details, but friends, there's no going back, and those who don't see it and adapt their mental models to this new reality won't have a good time.

That's why, just as one uses a cell phone to communicate despite knowing there's child exploitation in obtaining the rare materials inside, AI presents a web of moral dilemmas we'll have to solve as a society, but this doesn't take away from how fascinating this technology is and all the good it can do in the right hands.

Recap

My first programming environment was QuickBasic on DOS, in 1993. I went through everything in between since that year: copying code from magazines, 5 1/4 diskettes, 3 1/2 diskettes, Borland C++, BBSs, dial-up, Linux, open source, ICQ, burning CDs, Visual Basic, MSN, fiber optics, Ruby, Rails, Fotolog, the framework explosion, mobile and Objective-C, Rust, LSP, making games with C++, Unity, Unreal, the crypto lie, GitHub Copilot, etc. And now... this.

Code agent-assisted programming is, without a doubt, the most drastic and exciting change since I started programming at 8 years old. The fundamental change is that, with enough knowledge acquired over the years, I can finally focus on thinking about what I want, using fewer and fewer cognitive resources on code details. It's no longer "autocomplete help", it's something else. The mental model has completely changed, and with it, instincts as basic as cost-benefit evaluation for any project.

I'm an extremely restless person, every three days I have ideas for things I'd like to exist. I used to discard many ideas for small tools or projects I thought would be "cool" to have but could never justify having a healthy life if I wanted to implement all those ideas. For example, last week I needed a spaced repetitions app that uses LLMs to generate cards and evaluate my answers. That's easily a 3 or 4 month project. I did it in 4 hours while working on something else. These kinds of things weren't worth it before, now I can make MVPs and prototypes with specification documents that I also generate using the same agents. Crazy.

The Mental Shift

For years I had two layers of thinking that sometimes mixed: one user-oriented and one code-oriented. In my consulting work, it wasn't unusual to talk with people asking for specific things, like a recommendation system using a graph database. It was very common that while we were talking, I was already thinking about implementation details. Which database? Neo4j? How to model the relationships? This distracted me from the general discussion.

There was constant context switching between "requirements" and "implementation" that pulled me out of the present moment. Part of my brain was solving technical problems while the other part was trying to understand what the client really wanted.

Now I force myself not to think about implementation during those conversations, because I'm not going to do it anyway. And this changed everything. My ability to ask questions improved a lot because my brain is more present in the right mode. I listen better, ask better, understand better.

Do I lose anything by not thinking about implementation? No, because now there's a specific moment for that: when I discuss architecture with the agent. That's the right moment, not while I'm trying to understand what the user wants.

Why the Terminal

I started using Cursor but I was frustrated by how slow it was. VS Code is a crappy editor, inherited from Electron and all that unnecessarily heavy architecture. My favorite editors are Sublime Text and vim, always have been because they're super fast. But their agent integration is pretty bad.

Now I'm abandoning these editors too in my day-to-day work. The workflow has changed so much that the editor/IDE has taken a back seat.

I have my quirks: iterate fast, fast interfaces, keyboard first because the mouse is for the weak. The terminal has been my favorite environment forever. My friends were surprised when they saw I chatted with them through CenterICQ.

No surprise then that I ended up in love with Claude Code. The Unix philosophy of small tools integrated with the terminal to achieve complex behaviors integrates much better with Claude Code than with other environments. I think using CLI agents is natural given my previous mental model.

About This Series

This is my personal experience. There are other ways to work with agents: Conductor, Cursor, Windsurf, and many more. I'm not saying this is the best way, it's simply what works for me.

I put the year in the title on purpose. This is constantly changing and it's logical that everything I write here will become obsolete soon.

This is a snapshot of how I'm programming with Claude Code in January 2026.

In upcoming posts I'll talk about:

• GitHub Integration
• Specification Management
• Agents, Skills and Commands
• Code Review
• MCP & CLI
• Next Steps

Now, the least interesting but necessary part:

CLAUDE.md

The CLAUDE.md file is the first step to transform a generalist agent into one specific to your project. It's the low hanging fruit of configuration. Claude reads it automatically when starting each conversation.

I mainly put some important pillars: how to run tests, compile, and the typical project workflow. Each project is different, so this file always changes a bit.

Useful Tips

It's very important to keep CLAUDE.md concise. The content is prepended to each prompt and consumes tokens, better not to overdo it and use short bullets, without too much chatter. You're writing for Claude, not onboarding a junior. Specific context can be given manually.

While you work and notice recurring problems you can type #, and give Claude an instruction that it automatically incorporates into CLAUDE.md. Very useful for documenting on the fly while you work.

Something I learned recently is that not everything has to be in the CLAUDE.md at the repo root. You can use CLAUDE.local.md for local instructions (and add it to .gitignore), you can have CLAUDE.md in child directories (they load when you work on those files), and ~/.claude/CLAUDE.md in your home for global settings that apply to all your projects.

The obvious: use /init to generate an initial CLAUDE.md analyzing your project, but you need to refine it a lot.

The .claude/rules/ Directory

For larger projects, you can organize instructions into multiple files inside .claude/rules/. They all load automatically.

.claude/rules/
├── frontend/
│   ├── haml.md
│   └── css.md
├── backend/
│   ├── api.md
│   └── database.md
└── general.md

You can even make rules that apply only to certain files using YAML frontmatter with the paths field:

paths:
  - "app/controllers/api/**/*.rb"

// Rules that only apply to APIs
...

And if you have rules you want to share between projects, you can use symlinks:

ln -s ~/shared-claude-rules .claude/rules/shared

At any time you can use /memory to see which memory files are loaded in the current session.

What's Next

With CLAUDE.md you have an agent that understands your project. But code doesn't live in a vacuum: it lives in a repository, with issues, branches, pull requests. The real workflow needs the agent to be able to interact with all of that.

The Unix philosophy I mentioned before — small tools that integrate — applies perfectly here. The GitHub CLI (gh) gives Claude Code the ability to create PRs, read issues, check pipeline status. And combined with git worktrees, each task lives in its own isolated universe.

In the next post I'll explain how I set up that flow: from when I pick an issue from the sprint until the PR is merged.