Check out Tolaria 💧

What is Tolaria?

Tolaria is a desktop app for Mac for managing markdown knowledge bases. In a way, it’s my own version of Karpathy’s LLM wiki.

I have a close circle of friends who have been using it over the past few weeks, and they use it to operate:

• Second brains and personal knowledge

• Company docs as context for AI

• OpenClaw / assistants memory and procedures

Personally, I use it to run my life and work.

I have a massive workspace of 10,000+ notes, which are the result of 6 years of Refactoring work + a ton of personal journaling and second braining.

Earlier this year I decided to migrate everything from Notion to markdown files for a variety of reasons (speed, control, better AI work), but I missed an app that allowed me to operate these files with a UX that fit my brain — so I built it!

So, this newsletter will explain a few things:

• 📹 Walkthroughs — how I use Tolaria for various stuff.

• 🌀 Tolaria + Refactoring — how Tolaria fits the broader Refactoring picture, and my life.

• ⭐ Tolaria Principles — things I believe in, on top of which Tolaria is built.

• 🔧 How Tolaria works — the main parts.

• 🔬 What you will find in the repo — interesting stuff you may look at.

Also, as I wrote before, I commit to keeping you posted about my AI coding workflow, and I will use Tolaria and its repo as a living artifact of how I create software with AI, trying to staying on the frontier of what’s possible, trying new things, and so on.

Tolaria will stay free forever, but if you want to stay posted with these explorations and support my work, consider subscribing to the paid version of Refactoring 👇

Subscribe now

p.s. we’ve recently launched our AI Club and will run the first edition next month. I’d love to see you there!

📹 Walkthroughs

Before you move further, you can find some Loom walkthroughs below — they are short and to the point:

• How I Organize My Own Tolaria Workspace

• My Inbox Workflow

• How I Save Web Resources into Tolaria

I recorded them because I think it’s way easier to see things in action than to read long explainers. So if you like what you see, you can continue reading below 👇

🌀 Tolaria + Refactoring

In this time of rapid change, deciding how I spend my time feels like a big deal. Tolaria is taking a lot of it, so it needs to be worth it, and I think it is.

With Refactoring I write about how to create good software — that’s how I literally make a living. Over the last few years I have done that largely by 1) doing research and 2) talking with the smartest people I knew.

With everything that’s happening with AI, this is not enough anymore.

Everyone needs hands-on work to understand what’s really happening, and form opinions that are not mediated by other people’s experience.

Also, in order to make for good evidence, such work needs to be ambitious. Side projects are nice, but can we build real, complex software with AI, without writing a single line of code? What about without reading it? Does it scale? Or do we drift into chaos?

So far, it scales.

Tolaria is not massive, but at this point it is not small either. By the numbers:

• 100K lines of code, in Rust + React.

• 1900+ commits

• 3000+ tests

• 70 ADRs

I have written more about how I work on it in this recent piece.

So, my commitment with Tolaria is the following:

• I will keep it free & open source forever.

• I will run my life and business on it.

• I will work 2+ hours / day on it to develop new things, fix problems, and make it useful for people other than myself.

• I will do as much of the work as possible with AI, trying to live in the future.

• I will keep you posted on Refactoring about this process.

In a nutshell, the goal is to work on the frontier and report back to you.

⭐ Principles

So, what is Tolaria about? When I speak with friends, jokingly I say that it’s like Notion, but offline, and for actual files. This is not 100% correct, but it’s a good starting point.

Tolaria is based on a simple belief: AI delivers the biggest benefits to those who are able to capture and organize context — whether it’s about their lives or work.

We often talk about “knowledge” management but it’s not only about knowledge: it’s about projects, goals, thoughts, relationships, and everything that happens in your lives. The more you can capture (and organize properly), the more AI can be useful to you.

Such material is, potentially, our most precious asset. We’ll want to keep it tidy, up to date, and most of all, under our control.

Keeping it under our control means not being locked into a specific tool or AI platform. It means being able to switch to different AIs by snapping your fingers, or using multiple ones together on the same collaboration surface.

You may want your Claude Code to do some autonomous research and write its findings, while your OpenClaw fetches your latest meeting notes and turns them into a doc, all while you write manually in your journal, or capture a valuable idea into an evergreen note.

This should all be possible and be backed by the same knowledge base.

Based on this, here is how I think such a knowledge base should work:

• Files — because of 1) portability, 2) offline work, and 3) how AI is massively good at working with them, files are an obvious choice for a knowledge base.

• Markdown — md has surfaced as the de-facto standard for documents in the AI era. And you can easily extend it with a YAML frontmatter to store structured properties

• Git — by using files, version control is an obvious fit. This is useful for 1) history, for 2) cloud sync, and for 3) tracking authorship of changes, especially in a world where humans and AI collaborate.

• Open source — if the goal is full & long-term portability, the app you use to operate your knowledge should stay under your control.

While the above items are the *core *principles, there are a few others I strongly believe in:

• Rich UX — there are a lot of markdown editors out there who are simply… editors. This just doesn’t cut it when you have a lot of notes and need to operate years of content. You need relationships, visual cues, navigation, colors, icons, stuff that tells you at a glance what a note is, where it lives, and so on.

• Keyboard-first — I am a developer at heart, so the more I can do via the keyboard, the better. In Tolaria there are shortcuts and commands for everything, and tab navigation works well, so you never need the mouse.

• Opinions — capturing and organizing knowledge is hard, so I will bring my point of view about it. When you do something every day, you need UX that is optimized for that, and you can only achieve that if your tool has opinions. Tolaria has many!

🔧 How Tolaria works

Tolaria is organized into a few main components:

1. Sidebar — for filtering notes in various ways

2. Note list — for displaying the list of notes that match the current selection in the sidebar

3. Editor — for editing the current note.

4. Status bar — for changing vault, check Git status, AI status, and handy stuff

Let’s look at each of these 👇

1) Sidebar

One of the core things you want to do when you have a lot of notes, is looking at just a subset of them at a time, based on various criteria.

Tolaria allows you to do so in many ways:

📥 Inbox

Notes that haven’t been organized yet.

This is inspired by Tiago Forte‘s concept of separating capture from organize. An “organized” note is a note that you know what you will do with. It may belong to a project, to a responsibility, a topic, or any concept related to how you organize work.

Review your inbox (e.g.) weekly to keep it from growing too large. You can disable the Inbox in Settings cmd+,) if you don’t like this workflow.

You can flag a note as organized by clicking on the “check” icon in the breadcrumbs bar, or with cmd+e.

🗃️ All Notes

As the name suggests, that’s the entire vault — every single note.

📦 Archive

A permanent home for notes you don’t want to delete but don’t want to see regularly. Archive aggressively to keep your vault clean. Archived notes still appear in search results, but not in sidebar sections.

🧩 Types

The main organizational device in Tolaria. Each note has a type, which by default is Note.

Each type can have its own icon and color, which you can change by right-clicking on it in the sidebar, or manually changing it in the properties or frontmatter of the type file.

Types are simply stored as markdown files, like Topic, or Project.

Click any type on the sidebar to see all notes of that type in the note list.

⭐ Favorites

Notes you’ve manually pinned to keep them top-of-mind. Great for active projects, journal entries, or reference notes you access frequently.

You can reorder them by dragging them in the sidebar.

Toggle a favorite note from the ⭐ button in the breadcrumbs bar, or with cmd+d .

🔍 Views

You can create custom views that filter notes by complex, nested criteria. The view editor fetches all available properties, plus allows for some tricks (like regexes and natural language dates)

Views are simple yaml files that get stored in the views folder. They can be edited easily and even created by the AI 👇

name: Active Projects
icon: 🚀
filters:
  all:
  - field: type
    op: equals
    value: Project
  - field: Status
    op: equals
    value: Active
  - any:
    - field: status
      op: equals
      value: active
    - field: date
      op: after
      value: in 1 week

📂 Folders

Tolaria stores notes in the root of the vault by default, but also scans your vault’s folder structure, which you can navigate at the bottom of the sidebar.

Folders are listed last because they are a secondary organization method—not the primary one.

🗑️ Trash

There is no trash bin, when you delete a note, it’s gone — but your git history is your safety net. You can always recover deleted notes from git if needed.

2) Note list

The note list shows the subset of notes selected by the current sidebar section. For example, clicking “Types → Project” shows all your Project notes.

⬇️ Sorting

You can sort the note list by any note property (they get dynamically loaded from the notes), plus file properties like modified and creation time.

Your choice will be remembered for that specific section.

💅 Display Properties

You can customize which properties appear as columns in the note list. This lets you see important metadata at a glance without opening individual notes.

For properties that are URLs or other notes, you can open them directly from the note list with cmd+click.

3) Editor

The editor is where you write and edit your notes. Tolaria supports two modes:

• WYSIWYG Mode — similar to Notion. Type naturally, use slash commands, and see the output directly formatted in the editor.

• Raw mode — shows the actual file characters. Access it with Cmd+/ or the code button in the breadcrumb bar. Useful when you need precise control over markdown syntax.

The note’s filename is always visible at the top of the editor. This keeps you aware of how the note will be named and linked.

A very important feature of the editor is the support for wikilinks. Type [[ to trigger autocomplete from your entire vault. This creates links to other notes, enabling the knowledge graph. Wikilinks also auto-update if the filename changes.

4) Git

Tolaria vault have first-class Git support and by default you retain fine control over it.

You can look at current changes and Git history from the status bar, create new commits and push them directly without ever leaving the app.

But if you don’t want to manage this manually, and want to use Git as a simple automatic sync layer, Tolaria also has an opt-in AutoGit mode in which it automatically creates commits and pushes changes after some time. It does so when the app gets idle, when you shift which app is in focus, and based on various heuristics.

5) Commands

One of Tolaria’s principles is being keyboard-first. Almost everything has shortcuts.

You can discover shortcuts from the mac menu and from tooltips on buttons.

A lot of actions also have a fall back or a quick way to do them via the command palette, which you can open with cmd+K

You can really do almost everything with it, including navigating to sections, creating new notes of a certain type, or perform routine actions.

You don’t even need to find the exact keywords — the palette is smart enough to match a lot of commands semantically:

🔬 What you will find in the repo

I will use this repo as a living artifact of how I do AI coding, for you to inspect at any time.

I have written exactly zero lines of code, out of the ~100K, and read very few of them. I am neither proud nor ashamed by it: it is what it is, and I would have never been able to build it otherwise.

Some interesting things that I haven’t seen too much elsewhere:

• The Architecture, Abstractions, and Getting Started docs — they have some overlap, but overall I feel they do a good job at capturing what the tech is about.

• The collection of ADRs — this is super useful, both for human review, and for AI to pick up on past decisions and what exists.

• The Vision doc — this is not super updated, but it is still useful to guide AI when we brainstorm new features.

Overall, this is a lot of context for the AI to inspect when you want it to do some “creative” task, like creating specs for new features, or making non-trivial tech choices, and dramatically increases the chances for it to get things right.

As of today I still review the ADRs and the changes to the main docs, but I find that AI gets these right >90% of the time.

➡️ Next Steps

If you download and install Tolaria, you will get the option of cloning a getting started vault that has examples and instructions. There is also a Feedback button in the status bar (bottom right) that gets you to Github issues, if you want to report anything.

Also feel free to reply to this email if you have any questions or just to let me know your thoughts! Please do! It’s been a ton of work and I absolutely want to know what you think about it 😄

And that’s it for today! I wish you a great week

Sincerely 👋
Luca

These are going to be monthly online gatherings where people can share wins and learnings from using AI, ask questions, and stay up to date about what works.

Join our AI Club 🪄

So today’s post is to explain 1) why I am starting it, and 2) how it works.

🎯 Why I am starting an AI Club

By now AI has taken over most of the online conversation about software engineering.

As I wrote last week, I think this is… largely correct. AI coding is so big and meaningful that figuring it out feels like the #1 priority for us as an industry. I don’t think we are misguided on this.

However, we are also in this very confusing stage where everyone is just trying things for themselves:

• Most teams have little-to-no shared practices / artifacts / ceremonies about AI.

• Opinions online are all over the place, and it’s hard to know who to trust.

• Most of us have very little time to try things out, and zero dedicated time at work to do so.

All of this against a backdrop of anxiety, layoffs, FOMO, and doomsday predictions.

Yay!

AI is also changing how I think about my responsibilities with Refactoring. It is changing the topics I cover, how I spend my time (I am back to coding, a lot), and the type of conversations I have with people.

So, Refactoring should help you run better engineering teams, and a big part of that now is about using AI well — together, as humans.

So I want to host good conversations about it, where people share what they are learning: the exciting wins, the humbling failures, and everything in between.

Sharing things with others not only makes us grow faster together — it’s also great to fight back against anxiety, impostor syndrome, and all the pressure that comes with the push for AI adoption.

So let’s use the Refactoring community as your extended team, where we compare notes and learn things together.

ℹ️ How it works

Here is the gist:

• Monthy 1-hour chat, hosted in the Refactoring Community.

• As with all-things-community, it’s for paid Refactoring members. We gate this to keep people committed and ensure high quality.

• Like our monthly mastermind, it’s facilitated by real engineering coaches, Joel and Melinda.

• I always join the call personally and share the things I have learned throughout the month

• Everyone who joins can share their own “aha” moments — a win, or just something that genuinely surprised them — ask questions, and get to know other community members

• Takeaways from the conversation are shared afterwards in the community in written form, for those who are not able to join.

• Finally, for paid Refactoring subscribers, in the newsletter I will also publish monthly AI updates that combine my own experiments with things that surfaced in community calls.

All in all it’s very simple. We’ll host the first one on May 8th, and we’ll always have them on the first Friday of the month, at rotating times to allow everyone to participate.

🔒 About the Refactoring subscription

Allow me a quick paragraph about the Refactoring subscription, which you might be considering joining.

It’s $15/month, or $150/year, to access the Refactoring community, all of our archive (300+ articles) carefully organized by topic, plus our weekly original long-forms about the latest and greatest engineering practices.

The community has bi-weekly events, professionally run, that alone would cost >$100 to join — each!

So if Refactoring helps you make just one better decision, thanks to something you read, or learned from someone in the community, chances are the subscription repaid itself for the full year.

I would love to have you onboard! 1500+ engineers have joined this already 👇

Join our AI Club 🪄

And that’s it for today!

Sincerely 👋
Luca

I received a lot of private comments, most of which can be organized into two categories:

• People wanting to learn more about the coding workflow itself.

• People wanting to learn more about the note-taking app I am building.

Both types of comments motivated me a lot, to the point where I decided to make all of this an official part of my Refactoring work, as follows:

• I am going to build this app for real, make it free and open source for everyone, and keep working on it as an ongoing effort.

• I am going to report my learnings about AI coding as part of the regular writing schedule, let’s say once a month or so.

I am convinced this is the right thing to do because, frankly, getting AI coding right is the #1 problem in software engineering today, and it’s not even close.

The economics of software are changing so much that there is no part of the process that is safe. Code reviews, QA, planning, staffing, traditional management — everything feels up for grabs and downstream of what happens with coding.

Also, while I love doing research and talking with others (e.g. on the podcast), opinions are so scattered across the board that I feel the strong need to try things myself, and do so in a serious, ongoing way.

So here is today’s agenda:

• 💧 Building Tolaria — a personal knowledge management app for the age of AI.

• 🦞 OpenClaw vs Claude Code — how I use them, and to do what.

• 🔧 Coding workflow — what changed vs one month ago, and what stayed the same.

• 📑 ADRs — the best recent addition to my coding.

• 🎨 Product workflow — how I create specs.

• 💸 How much I am spending — because I know y’all want to know that.

• 🤖 CLAUDE.md — bonus: my current Claude file, attached in full.

Let’s dive in!

💧 Building Tolaria

In the last article I said that what I was building didn’t matter much, well now it kinda does, because you are going to hear a lot more about it in the future.

Tolaria is a personal knowledge management app, extremely opinionated and tailored for my own personal use, but I hope it can be useful to others too.

It’s worth noting that this is not a particularly original idea. There exist plenty of tools in this space — Notion, Obsidian, Craft, Roam, and more — and most of them are very well made. Still, I know plenty of smart people who lately have been experimenting with weird setups.

Just last week, Karpathy wrote a viral tweet exactly about that.

Why such a renewed excitement around knowledge management? Because everyone who tries to work seriously with AI agents eventually understands that this is a core problem to solve: continuously supplying agents with reliable, up-to-date information about your life and work, and creating a good collaboration surface on these.

I suspect this still feels a bit abstract, so I’ll make a few examples from my own work:

• An agent should periodically fetch meeting summaries from tools like Fathom or Fireflies, create a note for the meeting with the summary and action items, and link the note to individual attendees (each of whom should have a page for themselves). If there are attendees who are new, the agent should create individual notes for each of them, enriching my personal CRM.

• An agent should receive voice notes from me and turn them into long-term notes and tasks, and connect them to the relevant existing pages.

• An agent should take every new article I write and split it into atomic evergreen ideas, connect them to similar ideas I have already saved in the past, and better organize my knowledge base so that it’s easier to write new articles in the future.

• An agent should suggest new article topics and podcast guests based on my recent readings and how these connect to things I have written in the past and interviews I already did.

In terms of intelligence required, most of these tasks are trivial. But they need a good collaboration surface 1) for agents to fetch the relevant info and 2) for me to work well with them.

Tolaria is my attempt to build this for myself first, and hopefully for some others too.

It will be completely free and open source, so that it also works as a visible artifact of my understanding of how to create products with AI, for other people to inspect.

At any given time, if you want to know e.g. what I write in my CLAUDE.md, or how I write docs, or what types of tests I write and which I don’t — you shouldn’t just trust my articles, you should be able to go to the repo and see for yourself.

This way, the ideas you read on Refactoring become the result of three things:

• 📚 Research — I read and collect experiences from others.

• 💬 Conversations — I go deeper by running community events and 1:1 podcast interviews.

• 🔧 Personal work — I do coding and product development myself to stress-test these beliefs.

All of these elements are meant to be public: you can get weekly digests of what I read, listen to the podcast conversations, join the community to chat with me (and others), and inspect the Tolaria codebase (soon!) to see how I write code.

Tolaria is not ready yet but it will be in a couple of weeks!

So where are we today? Here is an exec summary. Since I started working on it around mid Feb, here is what I got:

• 1526 commits — that is ~30 commits/day on average

• ~70K LOCs — about 45 lines / commit

• ~3000 tests — about 85% coverage

• 9.5/10 code health — as measured by CodeScene

• 40+ ADRs — to track our core tech choices, plus three summary docs for Architecture, Abstractions, and Getting Started.

That’s 2.5x the amount of code we had last month (we were at 20K LOCs), with better code health (9.5 vs 9.3), and better docs. I am still not writing any code, and I am still reading very little of it.

The product also got way better to the point where, by now, I have fully replaced my Notion workspace. It still feels surreal to say that out loud, after 6+ years of really intensive Notion usage, but here we are.

So let’s get into how I work on it, starting with coding 👇

🦞 OpenClaw vs Claude Code

In last month’s post I said that basically I acted as CEO, OpenClaw worked as a PM, and Claude Code worked as a team of designers + engineers.

Has any of this changed? Yes, and no. Roles are still kinda the same, but I am not using Claude Code strictly together with OpenClaw anymore, in the sense that the latter directs the former, but more in an async way. This change has been driven by three reasons:

• 💸 Cost — the initial workflow in which OpenClaw steered CC all the time was wildly inefficient in terms of token spend.

• 🎓 Capabilities — CC has caught up with a lot of OpenClaw stuff. Most of all, it has loops now.

• 👮‍♂️ Legal — most recently, Anthropic has explicitly banned this type of usage, but to be fair I had stopped it already.

So by now my OpenClaw and Claude Code work on separate things, in a completely asynchronous way:

• OpenClaw turns my inputs into product specs, checks on the general status of things, brainstorms new ideas, and in general does the work that benefits from broad context.

• Claude Code does all the technical work, including coding, writing ADRs and docs, and, crucially, QA, that was done by OpenClaw before.

OpenClaw doesn’t interact with Claude Code anymore, but it periodically checks that it doesn’t get stuck or crashes (which can happen for a variety of reasons). In that case, it restarts it.

🔧 Coding workflow

This article is largely meant to work as a delta vs my original AI coding article to highlight things that have changed, but it’s also worth noting the good stuff that has not changed.

The highest leverage parts of the AI coding workflow are still probably the CI gates on code health and test coverage. These gates exist in two places:

Read more

In that piece we argued that software engineering was undergoing a transformation from craftsmanship to factory work, with the gap between elite and average teams being more and mor…

Read more

In some cases, we even invented words we didn’t use before, like context, or, one of my favorite lately, intent. These words are abstractions—our bread and butter as engineers—and are born out of the necessity to discuss ideas, understand what’s going on, and improve how we work.

The intent concept is both important and, AFAIK, quite novel. These days you may hear it in sentences like “making sure PMs’ intent is captured into specs”, or “AI code should reflect the engineers’ intent”.

This angle frames software engineering as a translation act between something you want to achieve and what gets actually captured in artifacts like specs, UI design, up until code. If we continue this analogy, translation happens at every step, with different steps following different rules. Many engineering practices exist essentially to reduce the error rate of such translation.

So, seen through this lens, software development becomes an elaborated version of the telephone game. You win the game if the message is passed properly and ends up in… production.

That said, what the steps of the telephone game are (or should be), or what the best winning strategy is, frankly, it’s all up for discussion today. Should we write big specs beforehand? Should we keep human code reviews? Who should do this and that, and when, and how often?

Today I want to explore this, taking from what I have personally learned from my recent coding efforts, and ideas I bounced off with Amelia Wattenberger, who I interviewed last week on the podcast, and is joining me today on this piece.

So here is the agenda for today:

• 🔀 From intent to code — the journey of translating what you really want to do

• 🧱 Creating good platform — for each step of the journey, so AI doesn’t mess things up.

• 🛫 Staying at the right altitude — evolve your artifacts to match what you want to inspect

• 🔬 Using product to improve understanding — not just to implement it.

Let’s dive in!

Disclaimer: Amelia works at Augment Code and created Intent, a developer workspace with strong opinions about all of this. Augment is a long-time partner of Refactoring, I use it, I am a fan, and I am happy if you check it out.

Learn more about Intent

However, we are not here to promote Augment today, but rather compare notes about problems and try to predict where the puck is going. (The puck, Luca? In a telephone game? Yes)

🔀 From Intent to Code

Starting from something you want to achieve on the product you are building, then it’s a long way to encode that into, well, code.

Intermediate steps may vary based on your process, but you probably have some version of these:

1) Product intent

A high-level, one or two-sentence version of what you want to build. It may only live in your head.

Making an example from my own experiments (I am building an editor), let’s say I want to add split panes, like many editors have. In my head, that’s it. I don’t think about it a lot more.

2) Product specs

Product intent needs to be turned into a spec, like a PRD, which needs to stay faithful to my original intent, while deciding a lot more things.

How is this triggered? Is there a button? What does it look like? What about keyboard shortcuts? What happens if I drag a tab from one pane to the other? And more.

Some of these are just additional detail, but some might derail the feature in a direction I didn’t intend. For example, a legitimate interpretation might be to open up the tab in a new window, which is not what I want.

3) UI/UX design

Product specs are turned into design specs. What it looks like, how it behaves, where it lives.

4) System design

Product and design specs inform the strategy to implement this with code. Abstractions that should be reused or created, data structures (when relevant), migrations, instrumentation, testing, rollout and rollback, and more.

5) Code!

Finally, there’s code! All of this turns into a bunch of LOCs, to be pushed, reviewed, and released in prod.

Phew. That’s a lot of work.

Of course YMMV and you may skip creating actual artifacts for some of these steps, based on the complexity of the work at hand, and your team's workflows. But there are at least decisions to be made about all of these, even without the artifacts:

• Every step adds details that the previous kept implicit or simply did not consider.

• Every step can act as a lossy translation of the original intent. It can miss important details or interpret them incorrectly.

What is our goal with respect to this process? The ultimate goal is always to ship value to customers as fast as possible, so you can get feedback and iterate.

To ship fast you want to avoid rework: you want to reduce the misunderstandings between the various steps and the mistakes that would make work move backwards instead of forwards. You want code abstractions that match the PRD, a PRD that matches the product intent, and not getting to the point where a review fails and some of this gets back to the drawing board.

This angle is relevant with humans, and especially relevant with AI. AI models today are really good, and it feels most of their mistakes now come from not understanding what you wanted, rather than e.g. bad coding skills.

So how do you get good at this? The most convincing way, to me, is:

• Creating good platform for each step — which acts as guardrails and helps you minimize the amount of intent you need to encode into specs.

• Use specs as active collaboration surface — updating it with more details as the work progresses, so it stays at the right altitude all the time. Kudos to Amelia for making me think about this.

Let’s explore both 👇

🧱 Create good platform for each step

Read more

Last year we explored AI adoption, while …

Read more

If you run an engineering team, though, most of these opinions won’t feel useful to you. In fact, when I talk with people about e.g. some AI workflow, I usually get two types of objections:

1. Volatility — the advice may become obsolete in just a few months, or weeks.

2. Applicability — the advice doesn’t seem to apply to their team, because of X, Y, Z.

These problems often come together. I’ll give an example.

One of the recent trends about how to work with AI, on which there is more consensus, is Spec-Driven Development. There exist plenty of articles and frameworks to work with it, even created by prominent companies like Github. So it’s not a total consensus, mind you, but it’s about as much as you can get in these messy times.

Still, as a CTO, you may have legitimate worries:

• Is this worth investing in? Or may the AI tomorrow (i.e. next month) just figure out more of the specs by itself?

• Is this a good fit for our team? How do we harmonize it with how we have been creating PRDs and design docs up until now? Is there a way to work with AI that leverages how we already work, without the need to migrate to a different workflow?

These questions are 100% valid, and the result is often analysis paralysis: teams underinvest in AI because no approach feels durable or authoritative enough to graduate from individual experiment to team practice.

I believe the main problem is that most ideas are just tactical. They may work, but need to be placed within a bigger strategy — a wider map of how to think about our teams, AI, and how to work together.

So today I want to write about the ideas that feel the most durable to me, and on which I am confident we can create good foundations.

These ideas come from many places:

• My own experiments — as you saw last week.

• Talking with 100+ tech leaders — this year alone in 1:1s, masterminds, and community threads

• Our own industry report — where we surveyed 350+ teams and which we’ll release in March

• Our cohort program — where I work with a small group of ~10 CTOs and VPs to help their teams ship faster.

All in all it’s like a small think tank, and I am here to report findings!

These findings are actually quite simple (like all good models!), and are about three areas:

1. 🔧 Developer Experience

2. 🪄 AI

3. 🎨 Product Engineering

In my experience so far, these areas work like layers of a pyramid. Each layer creates value only if what’s beneath is taken care of. Think of it like Maslow’s pyramid of software engineering.

So let’s explore them one by one, recap what we know about them as of today, and how they work together for good.

🔧 Developer Experience

Read more

And it’s not random teams: it’s usually the best ones. If you don’t trust my anecdotal evidence, just look at recent reports. The very best teams, who had the best DX and code quality before AI, are the same who are getting the most out of AI today.

Still, it’s not 100% clear how these teams work with AI. The internet is full of opinion pieces and people sharing their CLAUDE.md files, but these feel tactical at best, and dubious/fake at worst.

I don’t want to add more of these. The proof is in the pudding, so I said to myself: if I want to write about AI coding, I need to build something.

So here we go.

For the last 17 days, I have been working on a personal project for a macOS app. Scope and complexity are daunting enough to force me to think architecture, buy vs build, performance, rich UI, and everything I would need to cover in a real—not toy—software project. And needless to say, I would never be able to pull this off without AI.

Before I give you more details, let’s start with what I got today so far:

• 772 commits in 17 days, for ~20,000 lines of code overall.

• 90% test coverage — via 500+ unit, integration, and E2E tests.

• 9.3/10 code health — as measured by CodeScene.

• A clear, hierarchical set of docs — to navigate architecture, abstractions, and codebase structure.

• A perfectly usable MVP — which I am, in fact, using every day.

I figured out and improved various parts of the workflow over time, so that now I am comfortable with:

• Not writing any code.

• Not reading almost any code. Say I read ~5% of it.

• Not providing UI design for ~90% of the features.

• Managing most interactions async via voice notes.

• Having AI work autonomously for long stretches of time, so I can do something else in the meantime.

So let’s dive into all of this, in detail. Here is what I am going to talk about:

• 🖥️ What I am building — because nothing else matters.

• 🎨 My product workflow — how I work as a PM.

• 🔬 How I keep tech quality — how I work as a CTO, without reading the code.

• 💰 How much I spent — the numbers nobody shows.

• 🔮 What’s next — my takeaways so far, and some obvious predictions.

🖥️ What I am building

Read more

We discussed how AI is changing software delivery, and the conversation continued well after we stopped recording.

A few weeks later, Rob shared an early copy of CircleCI’s State of Software Delivery 2026 report—which comes out today—and the data connected a lot of the dots from our conversations. So we decided to write this piece together: my take on the findings, with Rob’s perspective from the inside.

The report is based on 28+ million CI workflows across thousands of teams worldwide, and reveals something we have long suspected: the performance gap between top and average teams is widening. And it’s widening fast.

Elite teams (99th percentile) are reaching delivery speeds that would have been unimaginable two years ago, while the median team hasn’t moved much at all.

One story from my earlier interview with Rob captures this well. A team at CircleCI was debating whether to run user research for a new feature—the usual approach. Rob pushed back: just build a prototype overnight and test it with real users.

Even if the code was, worst case, 100% throwaway, the learning would be more accurate, and the cost would be just ~$100 in compute and a few hours of an engineer. The alternative would have been weeks for the research, more people involved, and possibly more shallow insights.

For someone like me, who has been involved in startups and lean teams for his whole career, it’s counterintuitive to think code-first. Much of what we know about building products is based on the implicit assumption that writing code is the most expensive part, by far.

So when such cost drops, the initial outcome is that engineers get faster. But when it keeps dropping, like in the last year, we get to a point where a lot of hypotheses don’t hold anymore, and we need to rethink the process as a whole: how we make decisions, how we structure teams, how we think about quality, and so on.

You stop optimizing individual developers, and start designing a new production system. Rob and I started calling this the software factory, and it became the lens through which the rest of this piece came together.

Here is what we’ll cover:

• 🏭 From craftsman to factory — why this is bigger than “AI makes coding faster”

• 📊 The widening gap — data from the 2026 State of Software Delivery

• 🎛️ Control systems thinking — a mental model for running your factory

• ⚡ What elite teams do differently — practices, not tools

• 🛠️ How to start — without rebuilding everything

Let’s dive in!

I am grateful to Rob and the CircleCI team for partnering on this piece and giving me preview access to their report. You can check it out below.

Check out the State of Software Delivery

Disclaimer: even though CircleCI is a partner for this piece, I will only provide my unbiased opinion on all practices and tools we cover, CircleCI included

🏭 From Craftsman to Factory

Let’s lead with an interesting bit from the State of Software Delivery. Actually, three bits:

1. Activity on feature branches (where most coding happens) is up 59% YoY — the largest increase ever observed.

2. Activity on the main branch, though, which is closely correlated with production deployments, is down by 7%.

3. Build success rates are down to 70.8%, the lowest in five years.

The way I see it is that engineers by now are comfortable with AI-assisted coding, and, as a result, teams are generally writing more code than ever. But it also feels that, when it comes to shipping, this confidence drops. Code fails more often, which makes engineers less eager to merge and deploy.

So while AI makes the generation of code faster, everything that comes after (or before) that — testing, reviewing, integrating, deploying — largely stays the same (or gets worse!), unless you do something about it.

I’ll also throw in my own experience into the mix. For the last two months, I have been running a small-group coaching program for CTOs where, among other things, I help them identify the bottleneck in their dev process — the step that limits the throughput of the overall system.

In theory, that bottleneck can be anywhere. In practice, it’s never coding.

For some, it’s manual QA. For others, it’s creating good requirements. For many, it’s code reviews. For one of them, it’s collecting good feedback from customers, so they can act on it.

As coding gets cheaper and faster, it’s changing the cost structure of the whole process, and bottlenecks now live in ‌the parts that AI hasn’t attacked yet. In other words, the whole system is up for discussion, and chances are it’s going to look way more like a factory than today’s craftman’s workshop.

Steve Yegge’s Gas Town is an obvious example that comes to mind. If you forgive the chaos, the waste of tokens, and the Mad Max theme, it looks directionally correct to me: a system of agents coding in parallel, orchestrated by higher-level agents that create and execute plans, and report back to their human overlords.

But as much as Gas Town can look at times like a 360° self-sustaining orchestration system, it’s still only focused on coding! Love this quote from Dan Lorenc:

Gastown is a preview of agent programming, but the future isn’t “code gets written faster.” The future is: change gets shipped faster. And those are not the same thing.

Teams are trapped because CI takes forever, tests are flaky or missing, review cycles are slow, merge conflicts pile up, confidence is low, production is fragile, and there are “oh god please don’t touch that” zones nobody wants to own.

If this plays out the way I think it will, software engineering turns into CI engineering.

Code is cheap. Green CI is priceless.

So how do we build what’s missing? Let’s go back to the data 👇

📊 The Widening Gap

We were saying: more code, more breakage, less delivery.

Read more

Learn how to run a better tech team 🔨

By now, chances are you have heard about the open-source AI assistant OpenClaw / Moltbot / Clawdbot. I have been using it extensively for two weeks now, and I want to share some thoughts about my experience with it.

I feel the need to do it for three reasons:

1) Signal — while there is a lot of information and stories online about OpenClaw, I have found most to be either shallow or inaccurate. Inaccurate is also an understatement: many takes are so comically bad/wrong/false that it is obvious that the author didn’t even bother to install OpenClaw, and is just remixing and regurgitating other (equally bad) content.

2) Impact — my experience with OpenClaw has been absolutely transformative and only comparable, AI-wise, to the launch of ChatGPT. YMMV and I don’t expect my experience to apply verbatim to everyone, but I suspect many people don’t understand what makes OpenClaw special, because it’s hard to see it from a distance.

3) Future — finally, this spectacular success gave me a lot to think about when it comes to the future of software and work in general, on which now I have thoughts that I want to share.

So here is the agenda for today:

• 🦞 What is OpenClaw — very briefly, for those who don’t know.

• 🔨 What I do with it — on a daily basis.

• 🔒 Security — keeping it real but also debunking some misconceptions.

And three theses:

• 🪨 Slaves vs software — AI enables a new (but also old) way to solve problems.

• 🔌 MCPs are dead — AI has clearly outgrown MCPs at this point, and not just them.

• 🪴 Personal leverage — learning from the story of Peter Steinberger, creator of OpenClaw.

Let’s dive in! You are in for a ride.

🦞 What is OpenClaw

OpenClaw is an open-source AI assistant you can install on a computer, plug into a number of tools, and make it do stuff. At its core, that’s it!

It is similar to Claude Code, but it comes with more features that work (kinda) out of the box, including, most notably:

• 🧠 Memory — it has a memory system to store things it wants to remember into files.

• ⏱️ Heartbeats / cron jobs — it can do recurring things when instructed to do so (e.g. every 4 hours send me a recap of my inbox and items that need my attention)

• 💬 Chat tools — it plugs into Telegram, WhatsApp and a few other tools for easy comms outside of the terminal.

It has a number of other features, including the ability to spawn subagents for long tasks, a big gallery of community plugins, and much more, but I believe the three above are what makes it stand out vs other assistants out there.

And the reason is all about UX.

There is nothing in OpenClaw you couldn’t already do with e.g. Claude Code plus a bunch of plugins / duct-taping, but the value here is convenience: the core parts are all pre-packaged, plus you’ll find a long tail of quality of life improvements that stem from the tool being intentionally designed as an assistant, as opposed to a coding agent.

So, it’s similar (on a small scale!) to when Steve Jobs introduced the iPhone as the combination of three things: a 1) widescreen iPod, a 2) mobile phone, and 3) an internet communicator. None of these were mindblowing in isolation, but put together they crossed some invisible line that turned the device into something else.

What is this something else, for OpenClaw? Well, let’s see.

🔨 What I do with it

The best analogy I have for OpenClaw is that of a person you have hired and you manage as your direct report. Yes, I know comparing AI to people is bad and out of touch in many ways, but I still find it the best model to build an intuition of how to relate with it and get the best out of it.

Like you would do with a person, you can tell OpenClaw to do things, do them on a recurring basis, have it report to you at some cadence, improve based on feedback, and it will happily do all of that. You will meet hiccups every now and then and stuff you’ll need to tweak, but for the most part, everything just works.

So, what to do with it is really up to you and what you need the most help with.

For me, as a content creator and owner of a small company, my highest leverage usage right now is that of an executive assistant, or a VA, that can lift some ops / admin work from my shoulders.

For example, right now OpenClaw:

• Sends me morning briefs about what I need to do during my day.

• Sends me prep for my upcoming meetings based on previous meetings and email threads with the same people.

• Stores and organizes meeting notes automatically.

• Does occasional coding work — e.g. it migrated all my Notion workspace to files, linking everything correctly.

• Plus does a lot of glue work that would otherwise require n8n-style automations.

And it’s great at one-off tasks too:

• I told it to draft an agreement with a partner company without adding any further context, because it could fetch it from email, Slack, meeting transcripts, and internal notes.

• I asked it to give me the copy for the next sponsorship placement. It did that by looking at our sponsorship calendar on Airtable to figure out what company was next up, plus fetching the actual copy from the right email thread.

It did both without the need for complex instructions — just explaining the work in a sentence or two like I would with a human.

To enable all of this, we have connected it to basically all the tools we use for work, including:

Read more

Pat’s article touches on a complex subject: the CTO role. He explores how such a role differs based on several factors, defines common sets of responsibilities, and provides insights you can use to improve alignment during hiring, company growth, and career conversations.

If you’d like to connect with Pat, please find him on Linkedin!

Here is the agenda for today:

• 👑 What’s a CTO — why the title carries seniority but rarely comes with documented scope.

• 🧩 Why I use archetypes — tools for sensing misalignment and converging on shared expectations.

• 🎭 CTO archetypes — eight recurring shapes that appear across different organizational contexts.

• 🛠️ How to use these archetypes — practical applications for hiring, growth, and career planning.

Let’s dive in! 👇

👑 What’s a CTO?

I’ve found that many people struggle to describe the scope of the CTO role.

Two people with the same “CTO” title can have radically different responsibilities, spend their days on entirely different problems and be measured by very different outcomes. These differences matter because misaligned and unclear expectations around the CTO role lead to frustration, inappropriate hires, organizational friction or burnout.

Many management and leadership roles often ask: “What is expected of me?”

I hear this frequently from Engineering Managers (EMs) and Tech Leads (TLs) in my training courses. While all roles have some slight differences, answering this for EMs/TLs is relatively straightforward, as I’ve previously written about in “The Definition of a Tech Lead” and “5 Engineering Manager Archetypes.”

Answering this question as a CTO, however, is much harder.

The title carries seniority and authority, but rarely comes with a documented understanding of scope, priorities, or success. After all, if you’re a CTO, you’re supposed to “work it out.”

Over my 25-year career in tech, I’ve worked with and observed many different types of CTOs. As a Principal Consultant at ThoughtWorks, I partnered with CTOs to help them transform and modernize products, platforms, processes, and organizational structures. As the CTO of the German digital bank N26, I met many CTO peers facing both similar and very different challenges. Since then, I’ve advised and coached CTOs across a wide range of organizations and situations.

What this experience has reinforced is that while CTO roles can vary dramatically, they are not always arbitrary. There are recurring shapes to the role that emerge in response to specific organizational contexts and constraints.

In the rest of this article, I describe these recurring shapes as CTO archetypes, which you can use to make sense of what different CTO roles cater for, why mismatches occur, and how the role might evolve over time.

🧩 Why I use archetypes

In software development, we often draw on design patterns such as the Observer, Singleton, or Decorator.

A pattern is a reusable solution to a specific problem in a defined context. Archetypes serve a different purpose. Rather than prescribing how to solve a problem, they describe recurring shapes that appear across many systems. When applied to leadership roles, I feel the term “archetype” fits better with the commonly understood meaning of “a typical example of something.”

Archetypes are not meant to be boxes people fit neatly into. Reality is always messier. Instead, they are tools for sensing misalignment and to converge on shared expectations.

Archetypes can help us turn implicit assumptions into explicit ones and provide a shared language to discuss expectations, trade-offs, and mismatches among an organization’s needs, a role’s scope, and an individual’s skills, experience, and growth opportunities.

No catalog of archetypes will ever be comprehensive or perfect, which is why my favorite quote from George E. P. Box applies so well here:

“All models are wrong, some are useful.”

When I wrote about the Engineering Manager archetypes, many people told me it helped them start productive conversations about which EM role their organization needed or which EM role someone was applying for. Others used it as a vehicle for growth, seeking new opportunities to build experience that allowed them to play other archetypes.

It’s also important to emphasize what these archetypes are not.

They are neither a hierarchy nor a maturity model. Most real-world CTO roles are hybrids, and an organization’s needs will change over time. Just as effective leaders practice adaptive leadership, a CTO’s shape must evolve as the company grows, shrinks, or changes direction. Used well, archetypes act as lenses rather than labels and support reflection and dialogue rather than categorization.

Although these archetypes are not meant to be exhaustive, I hope they’re still useful in practice. Whether you are an existing or aspiring CTO, a CEO or board member, an executive recruiter, or simply curious about what CTOs actually do all day, the goal is not to find the “right” archetype, but to have clearer, more grounded conversations about fit, focus, and context.

🎭 CTO Archetypes

The shape of a CTO role is mainly driven by organizational context and constraints, and because there are common situations, we can loosely group the following archetypes into one of the following categories:

• 🟣 Early-Stage or Small — Founder, Startup and Fractional.

• 🟠 Growth and Rapid Change — Scale-Up, M&A and Turnaround.

• 🔵 Complexity and Coordination — Group and CTPO.

Let’s look at all of them:

1) Founder CTO

The Founder CTO optimizes for turning a personal vision into a successful company, while carrying responsibility for both the business and its technology.

Imagine you want to start a tech company tomorrow, and you’re the most technically skilled person involved. Congratulations! You’re now a Founder CTO, and you wear the distinct hats of both Founder and CTO.

Founder CTOs typically have a much stronger attachment to the business than non-founder employees. While early-stage employees may have strong financial incentives, founders’ attachment is much deeper and more personal. For many Founder CTOs, the company’s success and eventual financial outcome are the positive side effects of seeing a personal mission come to life.

Founder CTOs often begin as the most experienced technical person in the organization. As the company grows, however, this may no longer hold true. Successful Founder CTOs frequently hire people who are more specialized or more experienced in particular technical domains. Some, such as Jack Dorsey (Twitter) and Patrick Collison (Stripe), eventually transitioned into CEO roles. Others, like David Heinemeier Hansson (Basecamp / 37signals) and Mitchell Hashimoto (HashiCorp), remained deeply technical as the company scaled.

The primary tension of the Founder CTO role is balancing the competing demands of the two hats, and in practice, the Founder hat often wins. During fundraising rounds, for example, the Founder CTO may spend significant time with investors rather than on technology leadership. In other situations, the Founder CTO becomes the public face of the business, requiring more time with customers or on marketing than leading the technology organization.

2) Startup CTO

Read more

It’s an 8-week program that blends live teaching and group coaching, and it’s for small groups: only 10 seats. You can reply to this email if you are interested in the next cohort in Q2!

Why am I saying this now? Because today’s topic is inspired by the last session of the program, which was about developer experience.

For some, this will be surprising. Most of the content you can find online these days is about AI, and it seems like learning to use AI well is the most promising route to shipping faster and more often.

But I am going to spill a secret here. AI is not that hard to use 🤷‍♂️

Yeah that’s right. Some people will convince you there is a whole new world to learn about agents, skills, tools, and while it is true that you need to get yourself somewhat comfortable with these, we are engineers, dammit! It’s all kinda easy to wrap our heads around.

So if you look at real teams — not solo engineers, I mean real engineering teams — that are getting the most out of AI, it’s most often not because they are using AI better or differently than the rest of us. It’s because they use AI on top of a platform that is already good. Folks were already productive and efficient before AI, and they got even more so now.

AI benefits teams who have their house in order, which largely means: good developer experience.

So, today we explore a simple but powerful technique to diagnose your devex: the Listening Tour. It’s a structured way to surface friction by talking to your engineers and mapping what you learn to your dev process.

Here is the agenda:

• 🧱 What is developer experience — and why friction is the enemy.

• 🔍 Interview your engineers — run a listening tour to collect stories of friction.

• 🗺️ Map friction to your process — group problems by dev pipeline step.

• 🧮 Score by reach and impact — prioritize without overthinking.

• 🔬 Find the one bottleneck — and why improving the wrong step makes things worse.

Let’s dive in!

Read more

The more the excitement, the wider the gap.

With AI, it feels this has been the case for at least the last couple of years, to the point that it even earned its own name: the gen AI paradox.

In June, McKinsey reported that:

Read more

If you like this piece, consider subscribing to the full version of Refactoring to get one every week. It matters a lot to me and it supports our work 🙏

Learn how to run a better tech team 🔨

Read more

Think of this as the Refactoring Awards — yes, I am giving awards to myself!

Here is the agenda:

• 🔮 Best trends — what dominated the conversation this year.

• 🪄 Best of AI — the best AI stuff we wrote about.

• 🎙️ Best podca…

Read more

Now, if I am honest, I am not a big fan of the word brand identity — it feels so corporate and impersonal. But I can’t say “our new logo” either, because there’s so much more here.

The way I feel about this…

Read more

Supercharge your tech career 🚀

Read more

Umberto has had an incredible 25-year career in tech, and recently wrote a series of reflections about it on his blog. I loved them and asked him to consolidate them into a long-form version for Refactoring, so here we are!

Find yourself a comfy place, get a hot beverage if you fancy so, sit down and I hope you enjoy the reading!

When we read stories of successful people, they always seem to be going in a straight line, where each decision gets our hero one step closer to their goals, all part of a flawless execution which appears to be planned from the very beginning.

This story will no doubt look the same, but that’s far from being the truth.

I will omit the sleepless nights, the long working days, the spite, the anger and sometimes the regret that have peppered what might otherwise look like a fairy tale.

When we tell stories, hardship is easy and sometimes convenient to forget, but it’s as much a part of who we end up being as the successes are. So while you read this, cut yourself some slack. If you are currently struggling, or have been, do know that it’s ok — we all struggle, and no, we haven’t figured it all out either.

By the time I am writing this I have been employed professionally in ICT for ~25 years, starting on a peculiar date: April 1st 2000.

I had started using computers semi-seriously a few years earlier, in 1996. And in 1995, three things had happened around me:

1. Microsoft launched Windows 95 — which got the whole world excited about personal computers at an unprecedented level of popularity.

2. The Internet became a thing — it was mentioned on TV and you might get it at home, for free, with dialup.

3. I was about to start university — and was looking around at what field to pursue.

For me, the decision couldn’t have been easier: it had to be Computer Science! Deep down I knew that the Internet and the World Wide Web would end up changing the world (if anything, I underestimated how much) and I wanted to be a part of that.

Also, and that helped although it was not the main reason, it appeared to be offering a promising career because demand was exponentially outgrowing supply.

Only 30 years later I would discover that this intersection of events is what the Japanese call ikigai.

Ikigai1 is used to refer to a passion that gives value and joy to life, by sitting at the intersection of four pillars:

1. 🌎 What the world needs

2. ❤️ What I love doing

3. 💪 What I am good at

4. 💰 What I can get paid for

My sustained enjoyment of this work, 30 years on, is a direct result of the inherent purpose at the convergence of these four pillars 👇

Let’s explore how, by organizing this journey into three stages:

1. 🎓 University & Open Source — the messy beginnings!

2. 🔌 Power Adapters and DevOps — how a lucky encounter set off my career

3. 💂‍♂️ Head of R&D — growing by playing the long game, coaching, and communities.

Let’s dive in!

🎓 University & Open Source

While at university I did something that, when I look back at it, I would say it was pretty reckless (at least for the time, or my family): I joined the Erasmus program2 as an exchange student. That gave me a chance to refine my English to a level that would have been otherwise unattainable. This was the end of the ‘90s when very few people spoke English and translators were still a booming business.

This hardly gained English fluency would prove supremely useful in the following years.

My first job out of university was glamorous (for the time) and came with a lot of wiggle room: I worked for a small tech company that dealt with large customers (mostly healthcare) and, when everybody was still writing desktop applications, was betting big on web ones. The job required sacrifices because it had a long commute, but I accepted because I intuitively grasped that it would allow me to gain experience not possible otherwise.

Having the company started out as an internet POP (point of presence), they also offered email and web presence services, which allowed me to tinker with mail servers, systems and network administration, web applications, databases, pre-sales, and even IT helpdesk.

This varied experience shaped me into an extremely versatile resource, and I still think is my greatest asset today.

They were also deeply committed to Open Source Software, which meant that I would get to play (and sometimes contribute back) to some projects we used. Spoiler: it was through one of these projects that I eventually got to know the person that would hire me at my current job.

I stayed at this job for a (relatively) long time because I liked it and it was my ikigai. But I was growing anxious to prove my worth outside a circle that I started finding boring.

As I said, I’ve been an avid Open Source user who contributed back as often as I could. Last time I checked—a decade ago—I had a level 2 fosser and Kudos rank of 8/10 on Blackduck (formerly Ohloh) which, quoted from their own page of the time was “relatively uncommon, with about only 6% of the population receiving this rank”.

This reinforced my desire to look for a new challenge 👇

A takeaway and a provoking thought 💭

Pursuing a passion or doing a job you love is great, but there’s a better option: do a job that you love and that you can also make a good living out of.

When we’re aligned with the universe, everything is easier, but true innovators are those that are willing to go against the universe.

🔌 Power Adapters & DevOps

It was at an Open Source conference in Germany that a fortuitous and definitely funny situation set in motion a series of events that eventually led to my new career.

Read more

The jury is still out on AI’s true impact on productivity, but at least it feels like it gave everyone permission to question old practices and try new things.

Nothing is sacred anymore, and everyday someone is figuring out something new: inventing workflows, debating how engineers should spend their time, and more.

The result is an incredible diversity.

Some teams are going all-in on AI, others are doubling down on fundamentals. Some are rethinking things entirely, others are skeptical that much has changed at all.

This is all fascinating… and overwhelming.

A lot of the thought leadership out there is necessarily short-lived, and I don’t want to be guilty of that myself, so I want to experiment with doing more of one simple thing: just sit down with leaders of elite engineering teams, and ask them how they work.

Not theory. Just: what do you do, and why?

The goal is to learn from teams that ship great products, fast — and understand how they’re adapting to this moment. What practices are they doubling down on? What are they throwing out the window?

For this first chat, I sat down with Greg Foster, co-founder and CTO of Graphite, a beloved tool that helps engineers ship faster through stacked changes and AI-powered code reviews.

What makes Graphite especially interesting is that they’re an AI dev tool built by devs, for devs. Their engineers use the tool every day. This creates an incredibly tight feedback loop and forces them to be intentional about how they work.

During our chat, Greg shared several practices that stood out — some controversial, some deceptively simple, but all battle-tested:

• 🚀 High-agency engineers — why Graphite runs with just ~2 PMs for 30 engineers, and how they make it work.

• 🎲 Onboarding roulette — randomly deleting employee accounts to dogfood their own product.

• 🏗️ Boring tech == fast shipping — monorepo, single language, Postgres for everything: simple beats clever.

• 👁️ Code review in the AI era — the vision for AI deciding what needs human review, and how stacking fits in.

• 🔥 Hard work as a lagging indicator — why the 996 debate misses the point entirely.

Let’s dive in!

Read more

Supercharge your tech career 🚀

Last week I finally caught up with the latest DORA Research about AI. It is a massive, 140 pages doc, exploring the state of AI assisted development — and it gave me a lot to think about.

By now, there are a lot of reports out there that try to figure out how engineering teams are doing with respect to AI. Broadly speaking, there are three main areas that are important to measure:

1. 🌱 Adoption — how much engineers are using AI tools.

2. 🪴 Productivity — how much AI is making individuals and teams work faster.

3. 🌳 Impact — how much all of this turns into business outcomes.

These work as increasing levels of maturity, and increasingly better proxies for true value: adoption by itself is not very useful, productivity is somewhat better, and impact is what we truly care about.

The problem is: these topics are also in ascending order of how hard they are to measure. A lot of the available data is either fuzzy, or self-reported, or both, which makes it hard to trust.

So today I want to cover some of the ideas that keep surfacing in these types of research, common pitfalls to avoid, and mental models I have seen the best teams use to trend in the right direction — the one that goes from “adoption is high”, to “impact is high”.

Here is the agenda:

• 💊 Productivity placebo — are you more productive, for real?

• ⛔ Bottlenecks — is the whole pipeline more productive?

• 🔍 Quality traps — are you more productive at the expense of something else?

• ⚔️ Collaboration sucks — an unpleasant but useful mental model.

• 🪄 Making things simpler — how do you trend in the right direction?

Let’s dive in!

Read more