Alex Kessinger

code@Stripe after work Water Polo Coach. Systems, People, Outcomes. Views are my own. co-host

[Alex Kessinger @voidfiles]

Happy to report that myself and @davidnoelromas are rebooting the Staff Eng podcast.

https://t.co/fLJx4Ei96O

This next season will focus on AI. These tools promise 10-100X productivity gains, but many engineers (and other practitioners) don't know how to learn them—especially as things change weekly. We're interviewing practitioners: what actually works, what failed, what they had to unlearn. Looking for guests who are doing their work with AI.

DM if you are interested in being a guest

[Alex Kessinger @voidfiles]

You're all 100x engineers...now what?

> frontier models might make you a 10x engineer but they also give your org all the problems of a company 10x bigger. The security debt, the audit trails, the blast radius. You move faster and inherit more.

Checkout the Latest Staff Eng Podcast with Karla Burnett (@tetrakazi), @davidnoelromas and myself. https://t.co/2tQRhcRca8

[Taylor Pearson @TaylorPearsonMe]

Eli Goldratt's book, The Goal, was famous for its (then unpopular argument) that keeping every machine running 24 hours a day, the metric most plant managers cared about, was actively making factories worse. I suspect we're seeing the same fallacy in how many people are using AI agents.

Goldratt's point was that machine utilization isn't throughput. What you want from a manufacturing plants is making good widgets as cost-effectively as possible.
It doesn't necessarily follow that running your machines all the times optimizes that.

Picture a three-station assembly line. Stations 1 and 2 each crank out 200 widgets an hour. Station 3 can only handle 100. Running stations 1 and 2 around the clock doesn't ship more product. It just piles up half-finished widgets in front of station 3, ties up cash in inventory, and creates more work managing the pile.

He developed the Theory of Constraints to point out that what matters is solving the bottleneck in the system, not increasing machine utilization.

I suspect a lot of agent usage right now is the same fallacy at higher resolution. Running 20 Claude Code sessions in parallel can feel productive because something is always happening. But, if the bottleneck in your work is judgment about what's worth doing, more agents just generate more output for you to wade through.

This is not to say there aren't workflows running 20 agents in parallel very effectively, I'm sure there are. And, I suspect there's a general retraining we all need to do around evolving historical workflows. But....

The constraint for most knowledge work is deciding what's worth executing and no one is task switching between 20 things at the same time effectively I don't think. I find I can run maybe 2 or 3 things in parallel with maybe 1 or 2 admin-y type things on the side and that is only if I'm very locked in.

[Alex Kessinger @voidfiles]

@jessfraz @jarredsumner @charliermarsh @mitsuhiko @dhh We’re trying over at the @StaffEngPodcast

[Alex Kessinger @voidfiles]

Formal verification might allow LLMs to write safer code, but it's not 100%.

From "Lean proved this program was correct; then I found a bug."

Overall the code base was well crafted, but:

> The two bugs that were found both sat outside the boundary of what the proofs cover.

https://t.co/95yEOsNExu

[Alex Kessinger @voidfiles]

From the skill:

> The most important section is Drafted vs Sent. Every time you rewrite an AI draft before sending, save both versions. The gap is the voice.

Smart. It's a mini self improvement loop.

https://t.co/zJveFMvfxX

[swyx @swyx]

If you're looking to improve your writing game, Anh is one of the most consistent heavy hitters I know in devtools HN and she literally just open sourced her writing Skills template for you to use below!

[Alex Kessinger @voidfiles]

The obsidian web clipper is pretty smart. It does all of it's clipping client side. Highly recommend.

[YB @yb_effect]

Not surprised that everyone is finding the Claude-Obsidian setup mind blowing.

I've been using this set up for the last few months and it's totally changed my daily habits and how I think about using AI.

Some tips:

1. You HAVE TO build a daily commonplace practice.

The more observations, epiphanies, thoughts, and questions you can jot down, the more context your agents will have on how you think, make decisions, what matters to you, etc.

These notes don't need to be clean or structured. Optimize for whatever lets you just get the thing down on paper. You're doing it right if your notes are all over the place...that's how our brain works.

My rec is to voice transcribe as much as you can because it's easier to say more. Say your ifs, buts, and ums. They're actually more helpful in context. You're letting your agent know what you are and aren't sure about.

The key thing to note about @karpathy's LLM wiki base is that it's fantastic for research projects - where it makes sense to have synthetically produced artifacts. But if you're trying to use "Claude + Obsidian" as a personal thinking tool, then you can't outsource your own life experiences to AI. That personal context you add is quite literally what makes the tool useful for you.

After doing this for 9 months, I can say for sure the context compounds. If you can just keep the habit going for a few weeks, you'll start noticing patterns that surprise you.

2. Go learn about @andy_matuschak's atomic note taking practice.

My big takeaway here is that thinking in atomic notes makes it easier to pull contexts from different parts of your life that you would normally modularize.

The notes aren't facts/names/dates but rather concepts. I love to think about them like API endpoints you call when trying to solve through problems in your professional or personal life.

Remember, as @paulg says "writing is thinking". Just write these notes for yourself in a way that makes sense to YOU. You'll start changing how you perceive your own thoughts and thinking style.

Eventually, you'll get to a point where you have so many atomic notes that you dictate a train of thought to Claude and it'll go through your vault and pull your own thoughts from the past to help you out...it's a magical experience.

3. Connect @readwise or Obsidian Web Clipper to build an intentional reading habit.

Since starting this setup, I've realized how much of my content consumption in the past was cope. I thought I was being productive by listening to podcasts all the time or scrolling on Substack instead of X.

I now am *extremely intentional* about the content I read and how I read it. @phokarlsson has a post on this called "Structure your milieu". Ask yourself, who gets access to my brain? Read their writing religiously and block everyone else out.

Your time scrolling should equate to searching for potential reads you want to add to the backlog, that's it. And your "consumption time" should be you in Reader highlighting and taking notes obsessively. Even a simple 5 min Substack read should be treated as an opportunity to create new atomic notes, connect previous ideas, etc.

The Readwise Obsidian plugin then lets you pull all your highlights that you can then connect to other parts of your vaults in meaningful ways. Remember, the more you read with intention, the more context you'll have to add to your "second brain". You can't automate that part.

I haven't used @kepano's Obsidian Web clipper yet but going to try this week. His recent Youtube demo looked amazing.

4. Build an agentic constitution (.md)

This is effectively the portal between your Obsidian and Claude. I have a detailed post on how I did this + a template you can feed to your own AI of choice to build for yourself (see in reply below).

But this file is you letting your agent know all the context it needs to know about you at a high level: who you are, your big question, how you like to work, your main goals, current problems, context on your team, and so on.

Anytime I have the agents do work for me, the first step is to go read the constitution so it acts in alignment with what I'm looking for at this stage in my life.

Key note here is that it's a constant WIP doc. I'm almost updating this weekly so that Claude knows what's changing in terms of focus and prioritization. The more you think about this doc like you're updating your team, the more useful it will be.

5. Create Knowledge Work PRs

This is the coolest part in terms of Claude integration but it only works if you have meaningfully spent time on the steps above.

I've slowly been adding subroutines to my vault. Call them skills or agents it doesn't matter. To me, they're equivalent of writing methods in a code repo. Each subroutine has a specific set of instructions on what to do. And they all start by reading the agentic constitution.

For example, one of mine is called "Tend the Vault". Its job is to check all my daily commonplace entries since I last triggered it, notice any key threads and insights, tell me which atomic notes I need to update, and create a draft of what to add.

Then I'll go through a 5 minute voice session where it takes me through edits one by one and I'll approve, tweak, or reject them. Once we go through the changes, it will go and updates all the respective md files.

I call this section "Knowledge Work PRs" because that's exactly what they are. You run your subroutines, the agents go do the work, and then you sit down and just like a manager go through all the PRs and decide what gets to go through production.

Ok this is getting pretty long so I'll stop here but if you made this far, I HIGHLY RECOMMEND you go through my Substack Engineering Agency. I've detailed every single one of my steps on how I build a better thinking, commonplacing, reading, writing, and second brain practice. See the replies below for links.

[Alex Kessinger @voidfiles]

The OG when it comes to Obsidian + Claude.

[Noah Brier @heyitsnoah]

Just added support for Pi, OpenCode, and Codex to Claudesidian if you want more AI + Obsidian fix. https://t.co/7iMuf523N9

[Alex Kessinger @voidfiles]

New mental model

[Todd Saunders @toddsaunders]

The token cost to build a production feature is now lower than the meeting cost to discuss building that feature.

Let me rephrase.

It is literally cheaper to build the thing and see if it works than to have a 30 minute planning meeting about whether you should build it.

It’s wild when you think about it.

This completely inverts how you should run a software organization. The planning layer becomes the bottleneck because the building layer is essentially free. The cost of code has dropped to essentially 0.

The rational response is to eliminate planning for anything that can be tested empirically. Don’t debate whether a feature will work.

Just build it in 2 hours, measure it with a group of customers, and then decide to kill or keep it.

I saw a startup operating this way and their build velocity is up 20x. Decision quality is up because every decision is informed by a real prototype, not a slide deck and an expensive meeting.

We went from “move fast and break things” to “move fast and build everything.”

The planning industrial complex is dead.

Thank god.

[Alex Kessinger @voidfiles]

Blog post https://t.co/TlpZUKsto3

[Alex Kessinger @voidfiles]

Here's the best advice I have for so far for anyone navigating AI adoption as a software engineer.

0) you're job was never to write software

1) lean in, get reps

2) fight AI slop with AI

3) taste is resilient

4) we're all fumbling, that's fine

I was a front-end engineer before the iPhone. As apps took off I thought: what if websites just disappear? What does that mean for my job? I tried learning Objective-C. It wasn't fun. It wasn't my world.

Websites didn't disappear. But I realized my job was never "writing front-end code." My job was delivering value to people. The technology was just the vehicle. With AI reshaping how we build software, this lesson applies now more than ever.

1) Lean in, get reps

AI is going to make things weird. Don't even try for competence at this point. The people who come out of this well are the ones who give themselves permission to be weird for a while.

Table stakes - things everyone should just be doing today. None take more than 5 min:

- Replace "let me google that" with "let me ask the AI." It might not answer well. But when it doesn't, that's the interesting moment - why didn't it work? Am I missing context? Every failed query is a rep. I coach youth sports and I think about reps a lot. How many can we get in?

- Throw a bug ticket at an AI agent. Just pick one. Say "go fix it." Watch what it does. Watch where it breaks. You learn more about how these tools fail in 5 min than from any blog post (including this one).

- Use agents to explain code, not just write it. Point an agent at a codebase and say "write me a markdown file explaining how this works." I'm not asking it to change anything. I just want it to read the code and tell me what it sees. Shockingly useful.

- Generate multiple approaches, not just one. Code is cheap now, but so are approaches. Have the AI create 3 versions of a solution, have it critique each one. Anthropic's skill creator has this baked in - it spins up a web server to show you the options visually.

- Pay attention to what frontier AI companies ship. Anthropic's prompt engineering docs, the XML tag trick (models were trained on massive XML) - small things that create better outcomes. And they're shipping fast. I had a copy of the skill creator from 6 months ago. The latest version is wildly better. We have to actively pull the latest.

- Browse skill repos like you'd browse HN. https://t.co/TJbgqpbTHt and https://t.co/kWXcOvh78U are the Hacker News of AI skills. I check what's hot in the last 24 hours. Half the time I discover something I didn't know existed. Fun 5-min habit that compounds.

2) Fighting AI slop with AI:

> The amount of energy needed to refute bullshit is an order of magnitude bigger than that needed to produce it - Brandolini's Law.

The AI version: the human effort to clean up AI slop is an order of magnitude greater than the compute needed to produce it. Yea the world will be filled with slop. It's Pandora's box. But there's a tool: AI. Fight fire with fire.

From vibes to legos - I've been using AI to summarize research papers for over a year. Vibed a lot of Python into existence. It worked (kind of). But the code became unreadable almost immediately. When I hit a wall on quality I asked myself: am I iterating on the Python or the prompts? It was the prompts, and I was fighting python trying to hold it all in my head. So I built a DSL in YAML to describe my prompt pipelines. Now I can see the flow clearly - prompt, prompt, prompt, take data from here, put it there - without python boilerplate.

I think there's something worth paying attention to here: our job is shifting toward using AI to move codebases into a place where we're dealing with large comprehensible concepts - legos - that humans can think through quickly. Then we spend our time reconfiguring the legos, not wrestling with implementation details.

Domain-driven design helps with this. I've always been a fan but especially right now. Ubiquitous language, domain models, bounded contexts. If we can use AI to wring out the cognitive load, it unlocks our cross-functional partners to participate in the build process. Designers and PMs will have their own AI tools. Those tools need to understand our domain models. If we hand them domain models connected to our code we unlock their ability to iterate with us on core architectural constructs.

3) taste is resilient

When aesthetics are cheap, taste remains. As AI gets better at producing things, taste becomes the critical skill (everything old becomes new again). For me taste is largely a feeling, lean into that. I react way more to an outcome than a blank page. I'm a better editor than a writer. So I use AI to generate a draft, then I edit with my gut.

A technique I use a lot: "rewrite this as if you're [person with a strong voice]." I tried it with Andy Grove. Took a casual Slack message about Q2 prep and asked the AI to rewrite it in his style. The result scared me. It shrugged off all my passive voice, all my pre-tense, and I was left with raw ambition. Which is honestly what I want but can be too timid to say.

4) we're all fumbling, that's fine

I'm doing a podcast right now talking to AI practitioners across the industry. What I can tell you: we are at the cutting edge, even when it feels like fumbling in the dark. My hypothesis: the difference between people who come out of this well and those who don't isn't that one group figured it out - it's that one group kept getting reps in.

5 min a day. Ask the AI a question. Throw a ticket at an agent. Browse a skill repo. Take a note.

[Alex Kessinger @voidfiles]

Last week @davidnoelromas and I had a chance to talk with @dylanvee from @OpenAI. While AI is rapidly changing the way we work, conversations like this are helping me navigating that change.

[StaffEngPodcast @StaffEngPodcast]

A look inside an engineering team @OpenAI with @dylanvee

Dylan Vassallo is an engineering manager at OpenAI leading the People Innovation Labs team -- an eng, product, and design team embedded within the People org, building AI-powered tools for recruiting, HR, internal comms, and the employee experience.

In this episode, Dylan talks about what it actually looks like to be an engineering team inside a frontier AI company, how non-engineers are becoming builders, and what the "graduation" process looks like when a prototype needs to become a production system.

With hosts @voidfiles and @davidnoelromas

[Alex Kessinger @voidfiles]

@thiagoghisi @davidnoelromas @lucaronin Holy cow. What's do you appreciate about it most? Any projects you can share?

[Alex Kessinger @voidfiles]

This is a great idea, I’ve been doing this in some form for over a decade. My Staff Eng co-host @davidnoelromas reached out this week to ask for more details on how I’ve been using obsidian and AI. This an expanded version of what I told him.

I’ve collected possibly too many markdown files.

> find . -type f | wc -l
52447

That’s my obsidian vault, and I use it with AI everyday without a special database, or a vector store, or a RAG pipeline. It’s merely files on disk.

The problem this actually solves

Think about the context you carry around in your head for your job. The history of decisions on a project. What you discussed with your manager three months ago. The Slack thread where the team landed on an approach. The Google Doc someone shared in a meeting you half-remember. The slowly evolving understanding of how a system works that lives across fifteen people’s heads and nowhere else.

Now think about what happens when you need to produce something from all that context. A design doc. A perf packet. A project handoff. An onboarding guide for a new team member. You spend hours reassembling context from Slack, docs, emails, your own memory, and you still miss things.

The knowledge base turns this into a system instead of a scramble.

The Architecture

A file system with markdown and wikilinks is already a graph database. Files are nodes. Wikilinks are semantic edges. Folders introduce taxonomy. You don’t need a special MCP server or plugin. The file system abstraction is the interface, and LLMs are surprisingly good at navigating it.

I use a structure borrowed from Tiago Forte’s Building a Second Brain, with the PARA taxonomy as a starting point, extended with categories that match how I actually work:

/projects/{name}
/areas/{topics}
/people/{slack_handle}
/daily/{year}/{month}/{day}/
/meetings/{year}/{month}/{day}/

Markdown files are nodes, wikilinks ([[target]]) are edges, the folder taxonomy is the schema and LLMs is the query engine. A graph database with a natural language query interface. No infrastructure required.

How it works day to day

After every meeting, the agent creates a note in daily/{year}/{month}/{day}/, downloads any attached Google Docs, and links everything to the long-running notes I keep for each person I interact with regularly. A note from a 1:1 with my boss JP gets a wikilink to [[/people/jp|jp]] and to whatever projects we discussed.

Over months, each person’s note becomes a timeline of every conversation, decision, and open thread. Each project folder accumulates every relevant artifact. You don’t have to remember where things are. The graph remembers.

For a work project, I can point the agent at a starting doc and say:

> Spider through every tool you have access to and pull down all the related context.

It grabs Slack threads, Google Docs, web resources, all rendered as markdown inside the project folder. From that assembled context, the agent can draft design docs, product vision statements, problem/solution analyses. The output is better than prompting cold because the LLM is working with the real history of the project, not your summary of it.

This is the part Karpathy’s tweet hints at but doesn’t fully spell out: the knowledge base isn’t just for research. It’s a context engineering system. You’re building the exact input your LLM needs to do useful work.

What makes this different from just using an LLM
You might be thinking: I already ask Claude to help me write a design doc. True. But there’s a real difference between prompting “help me write a design doc for a rate limiting service” and prompting an LLM that has access to your project folder with six months of meeting notes, three prior design docs, the Slack thread where the team debated the approach, and your notes on the existing architecture.

The knowledge base is a context engineering system. You’re not building a wiki for the sake of having a wiki. You’re building the input layer that makes every future LLM interaction better. Every meeting note, every linked decision, every filed artifact improves the quality of every query that follows.

Where this is still hard

The piece I haven’t cracked is automated inbox processing. The idea is straightforward: web clippings, meeting notes, Slack saves, and random captures all land in an inbox folder. The agent processes everything new, applies progressive summarization, breaks content into atomic pieces, correlates each piece with the right project, area, or person.

I have a graveyard of experiments here. The LLM is good at summarizing and categorizing. The hard part is defining what “processed” means in a way that’s consistent enough to be useful six months later but flexible enough to handle the variety of stuff that lands in an inbox. Every attempt has been either too rigid (everything gets the same treatment) or too loose (the vault drifts into chaos).

If you’ve solved this, I’d genuinely like to hear about it.
Getting started

You don’t need 52,000 files to get value from this. Start with three things:

1: Create the folder structure. Projects, areas, people, daily. Even empty, the taxonomy gives you and the LLM a schema.

2: After your next meeting, have the agent create a note and link it to the relevant person and project. Do this for a week. Watch the graph start to form.

3: The next time you need to write something, a design doc, a status update, a perf self-review, point the agent at the relevant folders and ask it to draft from what’s there.

The difference is noticeable right away. Not because the LLM is smarter, but because it finally has the context to be useful.

Your work compounds. That’s the thing that feels genuinely new.

[Andrej Karpathy @karpathy]

LLM Knowledge Bases

Something I'm finding very useful recently: using LLMs to build personal knowledge bases for various topics of research interest. In this way, a large fraction of my recent token throughput is going less into manipulating code, and more into manipulating knowledge (stored as markdown and images). The latest LLMs are quite good at it. So:

Data ingest:
I index source documents (articles, papers, repos, datasets, images, etc.) into a raw/ directory, then I use an LLM to incrementally "compile" a wiki, which is just a collection of .md files in a directory structure. The wiki includes summaries of all the data in raw/, backlinks, and then it categorizes data into concepts, writes articles for them, and links them all. To convert web articles into .md files I like to use the Obsidian Web Clipper extension, and then I also use a hotkey to download all the related images to local so that my LLM can easily reference them.

IDE:
I use Obsidian as the IDE "frontend" where I can view the raw data, the the compiled wiki, and the derived visualizations. Important to note that the LLM writes and maintains all of the data of the wiki, I rarely touch it directly. I've played with a few Obsidian plugins to render and view data in other ways (e.g. Marp for slides).

Q&A:
Where things get interesting is that once your wiki is big enough (e.g. mine on some recent research is ~100 articles and ~400K words), you can ask your LLM agent all kinds of complex questions against the wiki, and it will go off, research the answers, etc. I thought I had to reach for fancy RAG, but the LLM has been pretty good about auto-maintaining index files and brief summaries of all the documents and it reads all the important related data fairly easily at this ~small scale.

Output:
Instead of getting answers in text/terminal, I like to have it render markdown files for me, or slide shows (Marp format), or matplotlib images, all of which I then view again in Obsidian. You can imagine many other visual output formats depending on the query. Often, I end up "filing" the outputs back into the wiki to enhance it for further queries. So my own explorations and queries always "add up" in the knowledge base.

Linting:
I've run some LLM "health checks" over the wiki to e.g. find inconsistent data, impute missing data (with web searchers), find interesting connections for new article candidates, etc., to incrementally clean up the wiki and enhance its overall data integrity. The LLMs are quite good at suggesting further questions to ask and look into.

Extra tools:
I find myself developing additional tools to process the data, e.g. I vibe coded a small and naive search engine over the wiki, which I both use directly (in a web ui), but more often I want to hand it off to an LLM via CLI as a tool for larger queries.

Further explorations:
As the repo grows, the natural desire is to also think about synthetic data generation + finetuning to have your LLM "know" the data in its weights instead of just context windows.

TLDR: raw data from a given number of sources is collected, then compiled by an LLM into a .md wiki, then operated on by various CLIs by the LLM to do Q&A and to incrementally enhance the wiki, and all of it viewable in Obsidian. You rarely ever write or edit the wiki manually, it's the domain of the LLM. I think there is room here for an incredible new product instead of a hacky collection of scripts.

[Alex Kessinger @voidfiles]

article https://t.co/LbTLj7ZMVy

[Alex Kessinger @voidfiles]

The biggest friction in AI adoption isn’t tooling - it’s that nobody has a consistent way to learn from each other. @lara_hogan makes the case for “aha” team meetings: short, regular sessions where everyone shares one surprise or mistake from working with AI that week. While the mechanics are simple, it flattens power dynamics and closes the gap between early adopters and folks feeling left behind. Curiosity helps here. I've done multiple similar formats so far.

https://t.co/VpfQ21ZrAl

[Alex Kessinger @voidfiles]

Killer analysis of TurboQuant from google. Headline it reduces memory use across the board for LLMs with some clever math. Supply is elastic.

[adlrocha @adlrocha]

Last week I wrote about the hardware side of the AI memory problem: the HBM bottleneck and why you can’t just build your way out of the supply crunch.

Immediately after, Google published something that attacks the exact same problem from the other direction. They realised AI might not need more RAM, but better math.

This week, I went down the rabbit hole of TurboQuant, Google’s answer to LLM KV cache compression. Think of it like Pied Piper’s middle-out algorithm from Silicon Valley, but for AI memory. It aims to achieve massive compression without trading off accuracy.

The same way Claude releases kill the market cap of some sectors immediately, this announcement from Google has crashed memory companies stock prices. Is this an over-reaction, or a complete shift in the economics and resource requirements of AI labs?

Link to post: https://t.co/nfH2snR6hm

[Alex Kessinger @voidfiles]

Dealing with AI Skeptics with @ktikeda and @davidnoelromas https://t.co/Uj2TVfMFDG

[Alex Kessinger @voidfiles]

How BabyList Accelerated AI Adoption in Engineering with Karynn @ktikeda and @davidnoelromas and myself. https://t.co/dV9Rdx9u9i