Thanks CodeRabbit for supporting today’s article!
When you ask an AI to review code it just wrote, you get the intellectual equivalent of a student grading their own exam. Shockingly, they always pass.
CodeRabbit CLI acts as an external reviewer for your AI-generated code. Different AI agent, different architecture, 40+ static analyzers, and zero emotional attachment to what it's reviewing. The agent writes, CodeRabbit catches what's wrong, the agent fixes.
One command, autonomous generate-review-iterate cycles. The AI still writes the code, it just doesn't get to decide if it’s good anymore.
In my 8 years as an engineering manager, I always felt my brain was enough. I never took notes or had a structured system, but I still easily remembered where every project stands, who's working on what, where I should focus next, who wants what from their career, who's struggling, and so on.
Recently, I started feeling my brain is running out of RAM (more on that analogy soon).
The average number of direct reports per manager has grown from 8 to 12 in the last decade, and continues to rise. On top of that, 97% of us also do IC work. We're expected to somehow manage more people while still shipping ourselves.
Today I’ll talk about:
How a greenfield project changed my approach
2 open source projects worth checking out (Cabinet and Tolaria)
How I’m trying to solve this problem (and what I suggest to start from)
2 months ago, in a meeting with my peers, I shared that I was feeling quite overwhelmed. While I manage ‘just’ 7 engineers, we are spread across multiple projects, and we also have the maintenance of the existing products.
I felt there is no way I could be involved in the work of all engineers enough to give good feedback, do some IC work myself, and also manage the team as a whole. The advice I got is “it’s actually possible, and you need to build a better system”.
Like when someone tells me to “be more AI oriented”, the “better system” advice made me want to puke a bit.
It’s not that I’m an AI skeptic, but I’m also not a huge believer. I’d place myself somewhere close to the middle when it comes to AI adoption. I see many benefits in some parts (like debugging and understanding codebases) but know it’s terrible in others (like writing and management advice).
I tried a couple of times to give it a try by asking ChatGPT about some tough situations (and yes, I gave lots of context). The problem of course is that LLMs are the average of the internet, and the average manager sucks (and doesn’t read newsletters to get better). "Have you considered having an open and honest conversation?" hmmm, haven’t thought of that, thanks!
Anyway, few weeks later, I joined a complex greenfield project with a cross-org team. About 10 people involved, split into 3 work streams, trying to come up with architecture decisions in 2 weeks.
Before we started, a principal engineer requested that ALL work be organized in a dedicated GitHub repo. Every meeting transcript, every Slack conversation, and every decision to be uploaded there.
To be honest, I thought it was ridiculous (and I told him so). Notion felt much more convenient, why would I gather feedback on a document using GitHub PR comments? But he convinced me to at least give it a try.
Man, I was so wrong.
An LLM ‘project-brain’
It took me a couple of days to adjust. I started slowly, opening a Claude Code session inside this cloned repo whenever I needed to work on something. I was already brainstorming with Claude anyway, so the additional context helped.
But pretty quickly, I found myself starting the morning with "what should be my top priority now?" and getting an answer that actually made sense. When a meeting ended, all the new decisions/thoughts were entered automatically in the right places, making it super easy for anyone to catch up. There was no need to watch meeting recordings. I could ask "What does John think about this problem?" and get an accurate answer without pinging John. I could see what the other 2 streams were working on and how it impacted mine. It even flagged conflicts I hadn't noticed, and suggested what topics I needed to discuss with the other stream leaders.
Every thought I had - "we need to remember to consider Y in this area" - I'd just mention it (either in a meeting or a Claude session), and it was captured in the right place.
All of it was done by dedicated skills the principal engineer had set up in the repo, that automatically synced everything - meetings from Fellow, Slack channels, Notion pages. Keeping it updated was barely any work.
I’ve read many people mentioning Andrej Karpathy’s famous ‘LLM knowledge base’ tweet, but until that project I didn’t fully understand how useful this concept can be. When a new engineer onboarded to this project, she did it 100% alone with Claude. All the dilemmas and final decisions were there to explore, there was no need for lengthy explanations.
The feeling of again being in control and on top of things was amazing. I knew EVERYTHING I needed about this 10-person, 3-stream project without holding most of it in my head.
My brain needs help
After 2 weeks I admitted to the principal engineer that I was wrong, and that it was super convenient. With the increasing scope and responsibility, I had to admit my brain needed help.
My best analogy is RAM and SSD.
I feel I have a powerful brain, like a 64GB machine. It can handle a lot of work purely in RAM, and it has been enough until now. With the increase of the complexity and scope of work, it’s becoming impossible to constantly hold everything there, so I need extra storage to load parts from when I need them. Using only my brain is like depending purely on RAM - it works great until you run out.
Taking notes is like adding an old HDD. You have the storage, but every read and write operation is very slow. You spend more time searching for what you wrote than actually using it.
Having an LLM connected to all your context is like upgrading to an SSD with a smart file system, which knows what to load into your RAM at every given moment.
But the critical part (that I feel many people miss) is that you don't let the SSD do the computation. You can't outsource the thinking and decision making to LLMs. They handle the storage and retrieval, but the processing should still happen in your brain.
A system that is built for YOU (and where to start)
I know, I know. Very close to the ‘better system’ advice. What can I say, it actually works…
What gave me an additional push to explore this is the My CTO daily driver article by James Stanier (author of ‘Become an Effective Software Engineering Manager‘, and one of my favorite newsletter writers). He calls it a daily driver, but the concept is the same:
…At its core, it’s the creation of a continually improving system tailored to you. Consider the opposite: when you use Claude Code for a one-off task, you open a session, do the thing, and close it, and all of that context disappears.
A daily driver is something different: it’s a personalised workspace that has memory, both internally via files and externally via other systems that act as sources of truth. It has your opinions baked in, and it’s less a tool you pick up than an environment you quite literally drive your whole day from, one that only gets better with time.
James Stanier
The core idea is very simple - a collection of constantly updated files managed via git. Here are 3 examples:
The project-brain system
For this, I recommend quickly building it yourself. It’s not that hard, and every company/project has a bit different needs. You can also check out Cabinet, an open source project that aims to solve this exact problem.
I’d bet that if you gave this article to Claude, and ask to build something that fits your team for the next project, you’ll get 80% there.
The critical skills to build first are:
How is information stored (what goes where)
How to sync from different systems (can be done at first by manually calling the sync skills)
How to retrieve the right context
The engineering management system
After wrapping up with the project, I decided to try something similar for the other aspects of my role - the people management, the day to day dilemmas, influencing the org, etc.
As I actually wanted useful answers and not bullshit, I started by combining all the knowledge I accumulated over the years. I (well, Claude) went over notes from ~40 engineering management/leadership books and 100+ articles I've saved.
I then turned all the knowledge into 26 specific skills:
My goal was to feel like I consult with my favorite authors, and to call me on my bullshit.
Then, I opened a local github repo on my computer, installed the skills, and started to work there. I synced context from Slack and Linear, and built some basic understanding about my team.
I ask questions like "Where do you think X is struggling in project Y?" or "What am I missing?". It’s very early days, but it recently helped me nail some quite tough feedback I’ve had to deliver.
One thing I'm still figuring out is where to store the sensitive stuff - career conversations, tough feedback, people dynamics. A private repo technically works, but company admins can see it. If anyone has solved this elegantly, I'd love to hear about it.
The personal system
I’ve been following Tolaria’s progress since it started to gain some serious traction (currently at 10k github stars).
It’s a simple desktop app that helps you organize all your notes as Markdown files, with native relationships, Git, local agents, and direct AI model providers.
I’ve just started the migration process from Evernote (I’ve been paying them $100 every year for a while!).
Final words
In the last 3 months, I have transitioned from a skeptic to a strong advocate of this ‘LLM-based-brain-and-personal-operating-system’. I’m sure the tools will change, but the concept itself, of having all info organized and accessible by LLMs is here to stay.
And it’s not that I feel like I solve it - I still struggle to build this habit, it’s much easier for me to fallback onto using my own brain (especiallyin the management part). But I’m getting there!
If this article was useful in any way, or you have your own tips to share - please reply with your thoughts! Writing a newsletter can be quite lonely, as I have no idea how my content is received.
discover weekly
Outcomes > Learning Opportunities. Why in some cases your team member’s learning is quite secondary. I also REALLY loved that Shreyas Doshi shared his full conversation with Claude (powerful way to deal with generic objections).
Great companies are built in hackathons. I really believe we should have more space for engineers (and other functions) to play around and explore new ideas. With the current speed of building (especially new things), the ROI will be crazy for the companies brave enough to do it.
Radical Honesty Isn’t a Policy. It’s a Habit. From the cofounder of Netflix, a great take about small lies.
