Ai on enumerator.dev

Brain Burger

Tue, 29 Sep 2026 00:00:00 +0000

I have tried to describe my agentic coding workflows as they’ve evolved and Emily captures it perfectly. I use a Brain Burger (or Brain Sandwich):

My brain, and then
AI, and then
My brain

via The Brain Sandwich

Differently Difficult

Tue, 29 Sep 2026 00:00:00 +0000

In AI Didn’t Make Programming Easier. It Just Made It Differently Difficult, Jeremy Osborn writes:

In other words, the hard part moves from recall (“How do I write this?”) to judgment (“Does this actually make sense?”). This shift from recall-based to judgment-based programming represents the fundamental cognitive transformation at the heart of AI-assisted development. Where traditional programming demanded that developers maintain vast internal libraries of syntax, patterns, and idioms, AI-enabled programming demands instead they maintain robust evaluative frameworks for assessing correctness, coherence, and appropriateness. The cognitive burden has not disappeared—it has relocated from retrieval to reasoning.

How I use AI When Writing

Mon, 21 Sep 2026 00:00:00 +0000

I use AI when I write for work.

And like you, I hate slop.

Despite LLMs writing like someone I would never want to spend time with, I still find some of their output useful.

They speed up research, even if they are confidently wrong.

And they are mediocre grammar checkers and good enough document structure editors, even if they are obtuse.

My Writing Standards

When My Writing is Personal

I don’t write personal things with AI. This includes text messages, emails to friends and family, and Slack messages, comments on documents.

When I Write for this Blog

Most of my writing on this blog is free form with limited edits. I hit publish and then find a mistake when I read it on my site and I’m quite okay with that.

However, I use LLMs to assist with research and validation. Every now and then, I’ll do a double check on grammar and structure with a writing tool like LanguageTool or Grammarly, and I’ll occasionally accept phrasing that an LLM suggests if it suits my needs.

When My Writing is An Artifact for Work

At work I write documentation and proposals that are artifacts the company can discuss and work with.

I use today’s AI tools to research ideas, validate my assumptions, fact-check my work, and edit the document’s structure. More on this later.

When Writing Generates Code

I write to AI agents in the form of chat interfaces, documents, and structured prompts to generate code. I use all the tools available to me:

Type out my chat prompts by hand.
Dictate through a voice-to-text model.
Dictate through a voice-to-text model that is passed through an LLM to generate a structured output.
Have an agent generate a document, then have a second agent read and validate that document.

Essentially, there are no rules when I write in order to generate code. I don’t even consider most of this “writing.” But it does result in generated text that has my name attached to it.

How I use AI to Write an Artifact

Use a number of agents to do research. This often involves getting a coding agent to research and test ideas in a code repository, sending an agent with computer use off to do web research and produce a document, or chatting with an LLM to validate ideas.
Save agent-generated artifacts. Between chat sessions, I get the agents to save artifacts other agents can find. Coding agents write docs, desktop agents find and read those docs and generate text files or docs through an MCP connector, and chat agents generate text I copy-paste elsewhere.
Write a doc in my own words. After iterating with agents to build an understanding of what I’m writing, I start writing in my own words. The result is a document that is well-researched and thought-through. And very human. It has my tone, thought process, and mistakes.
Edit with an LLM. I have two prompts that I use to edit both my work and docs the agent generates. For my own writing, I prefer to make the edits myself. Occasionally, I agree with the LLM’s feedback but am stumped on how to make a change, so I’ll ask for ideas.
DON’T TRUST THE LLM. I use my judgement when the LLM gives me feedback. Its generated response often has good points that slightly miss the mark. I take those into account and use my own words.
Use LLM-generated text when it helps. It feels like I’ve admitted to a mortal sin here. I am writing for business, and LLMs are trained on business applications. I have no problem copy-pasting a sentence from an LLM at this point because I’ve done the legwork and the LLM is helping with polish.
DON’T ARGUE WITH THE LLM. It is going to generate text that makes no sense. Ignore this. When I have tried to correct things the LLM gets wrong, it begins to misunderstand the task overall. I often tell it what was good and then say something like “You can do better than this, I know you can. Give it a second, more thoughtful pass.” If is WEIRD to say things like that to a computer, but it works for me.
Share my work. ~~I share a document with two sections. The first is my writing. The second is a summary of the LLM’s research, generated by the LLM. I flag this as AI-generated content in a BIG banner at the top.~~ [EDIT: Oct 3, 2026] I no longer find value in the AI generated section. I share my writing with a notice at the top explaining the document was written by me with AI assisted research.

AI Agent Prompts

Research Prompts

In my research prompts, I tell the agents my objectives, opinions, and assumptions. This context helps the agent focus on the outcome I am asking for. It also forces me to think about my opinions and assumptions. I expect the agent to confirm my assumptions and push back on my opinions. If it doesn’t do this, I ask it to.

Here is a template of a prompt I use:

I am researching <feature>. I need you to research <technology> in this
repository and write a summary that explains the current state.

Focus on <area of code>.

Ignore <similar but irrelevant area of code>.

My objective is to <write your objective>.

My opinion is that <what I think the research will reveal and what decision
I lean towards already>.

My assumptions are <how the repo works, how the technology works with the
repo, etc.>

Prompts for Editing

I have been working on a skill I call “Writing for Understanding” that is based on a number of accessible writing standards from government websites and based on my own experience. I pass all of the writing through this with the following prompt:

/writing-for-understanding read @doc and give me feedback one bullet
point at a time. Don't edit the doc. I will make the edits myself.

I also use Anil Dash’s Better Documents with a similar prompt. This is where I often get stuck! The LLM makes good recommendations based on Anil’s skill, but I sometimes don’t have an idea at my fingertips. In this case, I ask the LLM for ideas for restructuring the doc.

I prefer to make these edits myself, even if it means copying some AI-generated text into my final output.

What is MCP: A No Bull Explainer

Fri, 18 Sep 2026 00:00:00 +0000

Model Context Protocol (MCP) is a way for AI Agents to connect to an external application (usually on the internet) to gather information and perform tasks.

That’s it. No magic.

Breaking Down the Jargon

I have read so many descriptions of AI tools that are riddled with jargon. “MCP is a HTTP-stream-based protocol for agentic interfaces.” “MCP does not use SSE because it now favours streamable HTTP.” “MCP is a stdio-based server to connect to an LLM.”

Blah blah blah.

Model context protocol is a standard that uses existing technologies. The standard is new. The technologies are not.

HTTP is a transport protocol that defines how two applications connect and communicate over the internet.

MCP is a semantics protocol that defines how LLM-based software can perform actions in another application. MCP connections are often transmitted over HTTP using POST requests.

The Simplest MCP Connector

An HTTP endpoint that responds to POST with JSON-RPC in the content type, and GET that returns 405 Method Not Allowed. The GET endpoint can be used for an event stream, but we’re focusing on simplicity here.
The POST body is a JSON-RPC request object and the server replies synchronously with a single JSON-RPC response object.
The client sends id, method: "initialize", protocolVersion, capabilities, and clientInfo.
The server responds with protocolVersion, capabilities, serverInfo.
The client then POSTs notifications/initializedand the server replies 202 Accepted with empty body.
Tada! We have a connection!
The AI Agent POSTs tools/list to fetch tools or tools/call with an id.
The server always responds with an id that matches request id.
The AI Agent uses the id to keep track of which response belongs to which request. We’re doing HTTP here, so the ID is superfluous, it is essential if you add an HTTP stream that can respond to multiple calls.
Errors: JSON-RPC error object (code/message) in place of result, still plain POST/JSON, no special HTTP status needed beyond 200.

NEW!

MCP sessions are now stateless. Are you managing Mcp-Session-Id? No need!

sequenceDiagram
    participant C as AI Agent
    participant S as Server
    C->>S: POST / {method: initialize, id: 1}
    S-->>C: 200 result: protocolVersion, capabilities, serverInfo, id: 1
    C->>S: POST / {method: notifications/initialized}
    S-->>C: 202 Accepted (empty body)
    C->>S: POST / {method: tools/list, id: 2}
    S-->>C: 200 result: tools, id: 2
    C->>S: POST / {method: tools/call, id: 3}
    S-->>C: 200 result or error, id: 3

Misconceptions About MCP

MCP No Longer Recommends Server Sent Events

This confusion comes from the semantics of “Streamable HTTP” vs SSE (Server Sent Events). The MCP spec used to require SSE for remote connections and std IO when the MCP was on the same host as the agent. The original specification in 2024 required an SSE endpoint and a separate /messages endpoint.

In the current spec, MCP requires one endpoint with an optional upgrade to SSE. The wording is confusing here because the spec references Streamable HTTP under “Transports” and states that this is a replacement for HTTP+SSE. These statements are accurate, but once you read the spec, you realize that the only way to implement Streamable HTTP is by using server-sent events.

MCP Is Just an API

If you want to split hairs and say that since API stands for “Application Programming Interface,” then, yes, it is an interface of sorts for programming an application.

But your hair splitting would be out of touch with the way people talk. API these days usually means a set of HTTP endpoints that responds with JSON accessed over REST or GraphQL.

JSON APIs have been around for a long time now! And many of them don’t work well with AI agents. A large API specification is hard for an agent to reason about, which makes it difficult to accomplish tasks with a 1-1 mapping between an API and an MCP tool.

MCP defines the semantics that give agents the information they need to string together novel workflows and tasks.

MCP is a New Technology

MCP is only a new standard. It is based on existing technologies, and this is what makes it powerful. The MCP standard lets us quickly develop new user experiences because it uses existing technologies for connecting two applications.

Everything was done with an ASCII editor

Mon, 31 Aug 2026 00:00:00 +0000

The Super Metroid – FAQ/Speed Guide is 17,000 words of perfectly-spaced, full justified, mono-spaced text. It’s beautiful to look at.

From the FAQ

What program did you use to justify the text?

None. I just chose words carefully so that everything lined up on the right hand side. Everything was done with an ASCII editor.

via Unsung via Hacker News

This reminds me of the hours I spent in a trance tracking, kerning, and editing text to create a triangular brochure that folded out into a tessellation with full-justified text that fit perfectly into each repeated triangle.

LLMs Don't Write, They Generate

Tue, 18 Aug 2026 00:00:00 +0000

Everyone is mad about AI watermarking.

The thing is.

These machines don’t write.

They generate text.

Writers write. Machines generate. LLMs can watermark text without affecting the quality of the output because they are benchmarked on the usefulness of their output rather than the meaning of the text.

LLMs don’t reflect on meaning, consider their audience, and convey thoughts with care.

LLMs generate a probable output to the input. That’s all.

AI companies don’t value writing because they’ve never thought about writing. AI companies value the likelihood that the machine produces useful output. Not a meaningful output.

LLMs have gotten really good at generating probable outputs that are productive.

But it’s still probable. And only mostly productive. But rarely meaningful.

Saying that an LLM writes is as accurate as saying a lawn mower gardens, an airplane vacations, or a microwave is a chef.¹

Ha! Oh dear. I wanted to write the word “cooks” here but I can’t. Is there another word for “cooks with great culinary skill” in English? Perhaps language is changing and LLMs do, in fact, “write” with the same skill that a microwave cooks. ↩︎

Smitten with What's Written

Mon, 03 Aug 2026 00:00:00 +0000

As much as I use AI at work every day I find its writing harder and harder to understand. The code? It usually makes enough sense to me and I can follow its logic. But my brain goes foggy when I read the LLM’s reply to me.

The same thing happens to me when I read a blog post or article with the hallmarks of AI. It always starts with me wondering if I’m misunderstanding something in the article and then it clicks, “Oh, this is AI content.”

AI writing is a disaster. It falls apart so quickly. While LLMs can produce grammatically correct text, their writing does not stay on topic and they frequently invent phrases that sound correct but have have no real meaning.

In spite of this, there is so much AI writing out there now. It is exhausting.

On The Curiosity Shop Brené Brown proposes that the grammatical correctness of AI writing is so appealing that people overlook the weak content it produces (emphasis my own):

I think with the advent of AI, people who struggle with written communication, persuasive written communication, the problem is they’re smitten with what’s written.

They are so smitten with the idea that they can hand off a work deliverable or anything that’s well written…because that’s new for them. Like, all of a sudden, this is this beautifully crafted thing that I can turn into someone when for 40 or 50 years, I have not been able to make something basically perfect.

In a work context, Brown’s idea resonates with me. Writing is difficult. English grammar is hard enough! Never mind connecting ideas and creating a coherent argument in text. People publish AI content because it has the veneer of good grammar. Who needs Strunk & White when you have an LLM!

I have long detested prescriptive rules for writing. I endured lectures on commas in English 101 and still don’t know how to use a comma. I see rules and freeze. How can I write if there are all these rules to follow?!

Ironically, Strunk & White is too relevant today:

Omit needless words.

Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all his sentences short, or that he avoid all detail and treat his subjects only in outline, but that he make every word tell.

The Elements of Style

I Want to Read Human Words

It is almost cliché to say this today, but, I want to read human-written words. I really don’t care how polished human writing is. Especially in a work context. I want human thought process, rigour, taste, and decisions. I don’t want writing that’s been passed through an LLM and I absolutely don’t want an LLM to generate writing.

Safe Claude Code Settings

Wed, 26 Nov 2025 03:08:00 +0000

Here are a few commands I have in my Claude Code deny-list to prevent bad things from happening. I wish Claude shipped with these by default!

The following commands disallow Claude from force pushing and skipping pre-commit hooks.

{
  "permissions": {
    "deny": [
      "Bash(git push -f)",
      "Bash(git push --force)",
      "Bash(git commit:*-n:*)",
      "Bash(git commit:*--no-verify:*)"
    ]
  }
}

To be extra careful, I also have a pretty thorough gitignore that I install globally which includes common patterns for secret credentials.

*.key
*.pem
*.p12
*.pfx
*.cer
*.crt
**/secrets/**
**/credentials/**
.env
.env.*
**/config/secrets.toml

Why is Claude Code Different from Cursor if they Both Use Claude?

Mon, 27 Oct 2025 13:30:00 +0000

I get this question often. Here’s how the story goes:

Someone complains that AI is bad because it just does a bunch of stuff for you really quickly and does it wrong.
I ask what tools they’re using, and they say they’re using Cursor because it’s the most familiar IDE for them.
I ask them if they start a new chat for each feature, and the answer is usually “no” because this isn’t intuitive.
I suggest they try a different agent — Claude Code is my preferred tool — and they say, “It’s all Claude, though, how would that be different?”

Few developers have had time to learn these tools. They’ve been forced to use them as productivity enhancers, without the time to learn.

I have seen performance gains in my work. I shipped the first version of Uplift in a few hours! But I’ve also taken an enormous amount of time learning, training others, and trying terrible AI tools.

I work with many developers who use Cursor daily. This is good! Cursor seems to work better with their workflow. While I have a distaste for Cursor, others find it useful. Agents, like IDEs, are a preference, after all.

Going faster means slowing down to learn your tools. Changing IDEs or using a CLI is a BIG workflow change for most people, and if Cursor is your first brush with AI, I do not blame you for thinking it’s a waste of time.

In this post, I want to demystify “It’s all Claude in the end” to help people understand why some agents are good and others are frustrating.

Defining Terms

Let’s start with defining three standard terms. I’m going to use the common nomenclature in this post, but it’s important to note that their meanings are often blended in different contexts.

AI: These two small letters carry the weight of “agents”, “LLMs”, “automation”, “autocomplete”, and everything else. When someone says “AI,” they mean any one of these. In this post, “AI” refers to coding agents that have some autonomy in their work.
Agent: This term comes up in phrases like “agentic workflow” or “coding agent”. The agent is the engine of AI coding. The agent connects the user’s input to the local environment’s context (files, available tools) and provides it to the LLM. In this post, “agent” is a loop that takes user input, provides context to the LLM, and calls tools.
LLM: We all know LLMs like Claude, ChatGPT, or Codex. “LLM” stands for “large language model”. “LLM” is a misnomer. Many of these models accept multiple types of input and produce various outputs. A more accurate name is “Large Multimodal Model”. The models we use for coding are autoregressive, meaning they predict the following sequence based on previous context. For consistency with vernacular usage, I’ll refer to them as LLMs.

AI: Distinguishing the Agent from the LLM

In the diagram below, the “environment” is your computer and the tools you let your agent use. If you’ve given your agent access to find, for example, it will show up in the list. Depending on the agent, it might also collect some project stats to send to the LLM.

When you have a CLAUDE.md or AGENTS.md file, this will get sent with the context, too.

sequenceDiagram
    participant U as User
    participant AS as Agent
    participant E as Environment
    participant LLM as LLM (API)
    
    U->>AS: "Fix bug in auth.js"
    
    box rgba(0,0,0,0.05) Your Computer
      participant AS as Agent
      participant E as Environment
    end
    
    Note over AS,E: Agent Orchestration Layer<br/>Manages loop, provides tools, maintains context
    loop Until task complete
        AS->>LLM: Context + Available Tools + User Request
        Note over LLM: Parse intent<br/>Reason about next step<br/>Choose tool to call
        LLM->>AS: Tool call decision
        AS->>E: Execute tool (view/edit/bash)
        E->>AS: Return result
        AS->>AS: Append result to context
    end
    
    AS->>U: "Fixed: added null check<br/>Tests passing ✓"
    
    Note over U,E: Different agents = different tools, autonomy levels,<br/>and orchestration strategies (even with same LLM)

Notice that most of the work actually happens on your own machine. The agent interacts with your environment to collect information to send to the LLM, makes edits, and reports back.

An agent is not intelligent. This is really important to understand. An agent without an LLM is a loop with conditionals. Much like the code we write every day.

Adding an LLM into the loop gives the agent the ability to reason and make decisions beyond pattern matching.

Every agentic coding company will write its agent differently. The tools available, the actions the agent takes, and the system prompts it sends to the LLM are the product the company builds.

Cursor is different from Claude Code because Cursor’s agent is different, even if they both use a Claude model to reason and make decisions.

The LLM Reads the Entire Conversation Every Time

The LLM is an outside actor. If you are using Cursor or Claude code, every message you send and every agent loop involves API calls to the LLM provider you are using. If you are running a model locally, the model is separate from your agent system.

Every time the agent calls the LLM API, it is the first time the LLM has ever seen your message. The LLM reads THE WHOLE MESSAGE THREAD EVERY TIME.

That’s right. Do you have a long-running conversation where you’ve worked on three or four different tasks? When you ask the agent a question, the LLM reads the whole message thread and can easily confuse instructions you previously gave it with your current task.

In my experience, this is the most common reason agentic coding starts as highly accurate and quickly degrades into chaos.

How do you fix this? Start a new chat. It’s that simple. Start a new chat for every task you work on.

Warp has a great feature in its agent that detects a change in subject and suggests starting a new chat. I wish other agents would do that too.

This is an important distinction to make. The agent’s capabilities and system prompt affect how it works. Cursor tends to be very ambitious, which means the context window can quickly become bloated with failed attempts and misdirection.

More cautious agents will confirm actions with the user and detect when the conversation is drifting, keeping the context focused on the task at hand.

No agent is perfect, which is why I’ve explored using the Jujutsu VCS to give the agent memory between sessions and narrow the context the LLM receives on each turn.

sequenceDiagram
    participant CC as Agent
    participant LLM as LLM (API)
    
    box rgba(0,0,0,0.05) Your Computer

    end
    
    Note over CC: Context:<br/>[System prompt]
    
    CC->>LLM: [System prompt, User: "Fix bug"]
    LLM->>CC: "I'll check the file"
    Note over CC: Context:<br/>[System, User,<br/>Assistant]
    
    CC->>LLM: [System, User, Assistant, Tool: file contents]
    LLM->>CC: "I'll edit line 42"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst]
    
    CC->>LLM: [System, User, Asst, Tool, Asst, Tool: edit result]
    LLM->>CC: "Fixed! Tests passing"
    Note over CC: Context:<br/>[System, User,<br/>Asst, Tool,<br/>Asst, Tool,<br/>Asst]
    
    Note over CC,LLM: Each API call sends the ENTIRE context<br/>Context grows with every message<br/>and tool result.

Key Principles

The diagram below illustrates the capabilities of a coding agent. The Agent Loop is the central capability. This is the part that each company builds (Claude Code, Cursor, Zed, Warp, etc.)

The LLM is separate from the agent loop. Many different agents can use the same LLM, and most agents let you pick which LLM to interact with.

flowchart LR    
    AgentLoop[Agent Loop] --> LLM[Calls LLM]
    
    AgentLoop --> AL1[Stateful Orchestration]
    AgentLoop --> AL2[Maintains state and history]
    AgentLoop --> AL3[Executes tools]
    AgentLoop --> AL4[Manages context window]
    
    LLM --> L1[Stateless Reasoning]
    LLM --> L2[Processes full context each turn]
    LLM --> L3[Selects tools & plans actions]
    LLM --> L4[No memory between calls]

Conclusion

Try lots of agents! I know this can feel slow and frustrating, but when you do this, you are learning how different agents work. You are learning the new tools you can use in your job.

Take 15 minutes each day to build a small project with an agent. Pick something simple, like a to-do list app. Build the same app with different agents and see how they perform.

In the future, I think we will standardize on a handful of coding agents that developers can pick to work with their preferred workflow, much as we have standardized on a handful of IDEs for different use cases.

I prefer Claude Code for its built-in protections and customization options.

If you want an agent integrated in your IDE, you can run /ide to hook Claude Code up to VSCode. It’s not as deeply integrated as Cursor is, but it works okay. Another good option is to try out Zed, their agent has similar capabilities to Claude Code and is built into the IDE.

I’ve tried Warp a few times, and the deep integration of chat, CLI, and editing is promising to me, but sometimes confusing.

In the end, Vim is my home row, so the setup that works for me is Claude Code in one pane and Vim in the other.

Use Jujutsu to Plan and Build with Claude

Sun, 26 Oct 2025 12:58:00 +0000

This week, I read about Steve Yegge’s Beads.

I was skeptical.

He writes like someone trying to prompt inject your LLM. But he’s always written that way.

I tried beads, and it was pretty good. I wrote all of uplift using beads.

But it was also pretty buggy. I noticed I had multiple bd daemons running and checking git status. Not cool.

Jujutsu

I shared beads with Nate Smith, and he said, “You could do that with Jujutsu.”

We both tried it and it rocks.

Here is my current CLAUDE.md , which teaches Claude to use Jujutsu to plan and track issue progress.

Jujutsu is a Git-compatible version control system. The graph foundation of Jujutsu makes it perfect for this kind of work because Claude can add empty TODO commits along the way and connect them to one or more tasks that also need to be done.

Here is the gist of the instructions Claude gets:

Planning Best Practices

Create Descriptive Empty Commits:

Each commit description should fully explain what needs to be done

Include acceptance criteria in the description

Note any dependencies or prerequisites

Use clear, actionable language

The steps for you are:

Enter plan mode and build a plan with Claude.
When you’re ready, tell Claude to make empty commits for each step in the plan.
Tell Claude to work through one commit at a time until it is done.
If at any point Claude struggles or decides to compact memory. Kill your session and start a new one with “We are in the middle of working through a to-do list created in jj. Find the task you were in the middle of and finish it, then move on to the next task until you are done.

On Friday, I refactored a small Ruby library with Claude and Jujutsu, and it was really nice. I knew what I wanted the end state to look like and described that to Claude. Claude then made a plan with detailed acceptance criteria for 12 distinct steps. Once I approved, Claude turned the plan into jj commits and worked through them.

Around step 7, Claude slowed down and suggested that steps 7 through 12 were tightly coupled. I ran /clear to start a new session and pick up where we left off. Claude still saw that steps 7 through 12 were coupled, but no longer tried to implement them all at once. It methodically worked through the steps.

At the end, Claude suggested a five-PR stack so developers could review PRs implementing the requirement in separate logical steps.

Why This Works (My Theory)

Steve Yegge is right about why this works, but more than a little off base about needing a whole buggy go program to do it.

Claude works better with this workflow because the context you send is focused and clear. A big old markdown doc is fine, but Claude has to read the whole thing multiple times to find the next task.

With the Jujutsu workflow, Claude can read a summary of what is done with jj log and pick up the following task with jj edit

The LLM on the other side of the Claude agent receives a more focused context. As the conversation continues, the thread narrows to specific tasks.

In past work, when I’ve used a plan.md or Claude’s default todo list, Claude struggles because it reads the entire plan every time, multiple times, since the whole chat is sent to the LLM with each message. This means the context gets bloated with planning and loses focus on accomplishing tasks.

With the Jujutsu workflow, planning shows up exactly once in the context. Then jj log shows incremental progress.

I Want This

It’s good! You should try it. Get Jujutsu set up and copy my CLAUDE.md.

If you don’t know how to use Jujutsu, Claude can learn by using jj help.

The most important thing to remember is: if you think the agent is lost, you’re probably lost too!

You can /clear your session, take a break, and start fresh. Claude will pick up where it left off because it knows to use jj log to find the next task.

Learn AI Workflows by Stealing .claude Files

Wed, 30 Jul 2025 14:09:20 +0000

When Harper Reed first published “My LLM codegen workflow atm”, I was hooked.

I had been working with LLMs for a few months and Harper’s post made it all click. “THIS! This is the workflow that has been taking shape for me!” I dove in head first and now for the past few months, I’ve been AI first in all my work. I hardly type code any more. I read, refine, critique, and guide. I only get hands-on-keyboard when I have a very specific preference for how things should work.

Learning Takes Time

It took me a lot of time to learn this workflow. I was lucky enough to have willow.camp as a side project so I could get into the nitty-gritty. But not everyone has that opportunity.

If I had to learn this all today, here’s the approach I would take:

Steal my .claude files, which I stole from Harper, who borrowed from Jesse.
Install Claude Code
Pick up a ticket and start with Claude Code. This is TRAINING WHEELS OFF! Try it out. If you need an editor on the side, hook claude up to Cursor by typing /ide.
Type /brainstorm into Claude Code.
Work through the brainstorming steps to generate a spec.md.
Then kick off /plan, which will generate a todo.md.
Finally, kick off /do-todo, which will iterate through todos.

Repeat.

The more you do this, the more it will become second nature. Eventually, you might not even need the commands anymore because you’ll know when to plan and when to act.

Break Things

I learn by breaking things!

Modify your commands to suit your needs. Come up with your own commands and see how they work for you.
Try the same thing twice to learn more about keeping the LLM on track and focused.
Try the same task without doing the planning and see what happens.
Try a massively complex task with and without planning.
Try a tiny, simple task with and without planning.

Breaking things is all about finding the boundaries. The best way to know what an AI agent is good at is to find out what it is BAD at!

Keep it cool. If the LLM wanders off into the woods to build a tree fort when you asked it to do something else, that’s okay. We all get off track. Here are a few things I do to learn:

Ask the LLM what went wrong:

“I noticed we struggled to solve this. Analyze our conversation and give me pointers on how to find a solution sooner.” This is a good prompt because sometimes, some incorrect context or weird code misdirects the LLM.
“We have struggled to find a solution. Explain to me why you thought this was the right path forward?” This is an excellent prompt for getting the LLM to reveal its thinking. I have learned from this prompt that it is very important to correct the LLM early and often. If you don’t, you both might misunderstand something. Once the LLM is off track, I ask for a session summary, clear the chat and start over.

Takeways

Try stuff! Try lots of stuff and try it often. Timebox your work so you don’t get stuck in a hole. Check yourself to see if the task you’re doing is valuable. Are you learning something? Are you making progress?

Learning is about making mistakes. Remember to make mistakes safely and adapt to them quickly. AI workflows can accelerate your work, but you have to shift your approach first and know how the tools work.

Taste

Sun, 27 Jul 2025 13:02:00 +0000

I can see really high-skill, high-taste shops like 37signals struggling to adopt [agentic coding] because their very good taste means they are repelled by the slop. Bigger companies and small startups/indies will have an easier time at it, out of necessity. – Nate Berkopec on LinkedIn

With LLMs making leetcode and other whiteboard problems trivial, software hiring IMO should shift towards establishing taste, which LLMs absolutely do not have.

“What do you hate about ActiveRecord? What would you change about Rails if you could?” Review this PR, etc. – Nate Berkopec on LinkedIn

What is “taste”? Does your taste matter as a developer? Do your customers care about ActiveRecord? (Spoiler alert: they do not).

I have been working in an exclusively agentic workflow for about six months now. I hardly write code. Does this mean I have poor taste?

I remember in my early days in software development, I overheard two opinionated Senior Developers argue about white space and wondered why it mattered.

Taste Does Not Matter, Customers Matter

What matters at the end of the day in any business is its customers. Do they like what you’ve made? Will they tell people about it?

You can’t run a business on opinions about ActiveRecord, Rails, whitespace, or any of that. You run a business by selling a product that works well and makes people happy.

But `insert thing here` is BAD!?

It might be! What do we mean by “bad”? What is the impact on our ability to deliver a reliable product? How does it impact our customers?

“Taste” is only important if it affects the customer. Here are the interview questions I’d use in this new world:

How does ActiveRecord affect the software development life cycle?
What impact can the ORM have on the quality of your application?
When do you choose to set your opinions aside and ship quickly vs weighing your opinions against real-world consequences?
How do you measure the quality of good software?

The answers to questions like this will inform technical decisions and will avoid banter about taste.

I’d much rather focus on building great things than getting mired in debates about ORMs.

Conclusion

I care about your views on building fast, reliable software that makes people happy. Let’s leave the bikeshedding to others.

What to do When AI Makes a Mistake

Thu, 24 Jul 2025 15:31:00 +0000

Reading Sean Goedecke’s post “Do not yell at the language model”, my first reaction was, “Don’t…what?”

I don’t yell at people. Why would I yell at a non-sentient tool? That’s like yelling at the sledgehammer you dropped on your foot.

There is a good bit of truth in his post:

So what should you do when an AI model makes a big mistake? I recommend correcting it as matter-of-factly as possible and trying to briskly move on. If you haven’t yet built up a lot of context in the conversation, it might be worth starting over entirely. The best approach - only offered by some AI tools - is to go back to the point in the conversation right before the mistake was made and head it off by updating your previous message.

Just start over! Treat mistakes as opportunities to set better guidelines. The quicker you are at catching mistakes, the more accurate the LLM will become.

Here are a few things I do when working with LLMs:

One small task per chat. I know some people build up extensive context in a long chat, but if I don’t catch a mistake, the % of incorrect context can compound over time.
When the LLM or I are stuck, ask it what we are stuck on and ask it to summarize possible solutions.
Try one solution at a time. Sometime in the same chat. Sometimes in a new chat. Depending on how long your chat has gone on.
Verify the proposed solutions and problem space by looking at the code. Sometimes you’ll catch something the LLM misunderstood. Other times, you’ll learn something you had misunderstood!
Find docs to help focus the LLM’s attention.
Write Docs. This is so important. Once you’ve solved something, write the documentation in a docs/ directory and reference it in later chats for similar problems.

Agents don’t have intent. They don’t even have all the context. They can miss things. Treat the agents’ work as directionally correct. Verify implementation details.

To work quickly with LLMs, you need to understand the language, system, and tools you’re working with so that you can get the agent back on track when it inevitably drifts.

One last note about agents making mistakes. We all make mistakes! The best part of working with an LLM is that it can make mistakes quickly, and you can redirect those mistakes. The faster the LLM makes mistakes, the quicker you can refine the task and complete the work.

Anticipating errors is as much a part of working with humans as it is working with AI.

Why I Write When AI Already Knows the Answer

Thu, 03 Jul 2025 11:47:00 +0000

I have always been a writer. I haven’t kept all my writing, but I’ve always enjoyed it. Many of my recent blog posts are topics that are easily answerable by AI. I’ve asked myself, why write these posts when an AI can already answer these questions?

Why I Write

I write to understand. To explore. And to see things from a new perspective. My writing isn’t about telling people how things work so much as it is about taking readers on a journey with me. In my post about choosing a managed Postgres instance, I could have answered the question in the title in one sentence: I decided on a managed Postgres instance because it is more reliable and has better data retention guarantees.

But that would have been boring, and an AI could have told you that easily.

Writing that post was, for me, about taking readers on a journey and helping myself understand the choices I made. I write to understand myself, to explore the choices I’ve made, and to learn if there are better ways of doing things.

As I write, new ideas come to mind, and I ask myself new questions about the code and infrastructure choices I made. I research as I write to confirm my choices and verify my assumptions.

AI Already Knows the Answer

I use AI tools for all my development workflows. I type paragraphs more than I write code these days, and I spend more time reading code than I do writing it. AI tools have brought back the joy of making things because I can iterate, make mistakes, and recover quickly. I even watch AI agents make mistakes for the sole purpose of learning about those mistakes and the rabbit holes they lead to.

AI agents can provide great answers and excellent guidance. But they’re not always correct. And they rarely have the context of the whole application. Even in a small project like willow.camp, I had to coax the agent to look in the right places to understand what we were working on, and I had to remind the agent about the intended outcome.

AI Already Knows the Answer, but it also knows 5 or 10 other somewhat correct answers that might apply to different situations.

Had I asked an AI, “Should I use a managed instance?” it would probably say, “Yes,” with some caveats. The decision is still up to me because I know how I want willow.camp to work.

I write because understanding the full context of the project is essential to making good technical decisions.

We Have Always Been Vibe Coding

Wed, 28 May 2025 00:00:00 +0000

There’s a new kind of coding I call ‘vibe coding’, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists.

I was irked when Andrej Karpathy first posted his now-infamous “vibe coding” Tweet (yes, I still call them Tweets).

It’s not the part about LLMs or the AI that irks me. It’s the proposition that this is new.

I hate to break it to you, but most code is fueled with vibes. How else do you get an idea off the ground?

Before AI, vibe coding was just called being scrappy. Startups can’t burn money debating between the London School of TDD and the Chicago School.

They throw some code out there, copy-paste some Stack Overflow answers, ignore logs, and hope they make enough money to keep going.

It Has Always Been Vibes

Vibe coding isn’t new. The speed is new.

I worked at a startup with six months of runway, and despite our best efforts, the end of that runway came quickly. Racing for a solution before funding ran out meant late nights spent furiously hammering away at problems until they were good enough.

We didn’t have time to find the best-looking code or slick UIs.

We threw Stack Overflow, templating engines, and vibes at our code until it worked. Until it didn’t because there was no money left.

Even at more stable businesses, teams code with vibes. Sure, we had more time to focus on testing, quality, and best practices at those companies, but we didn’t make money off of test coverage. We made money because people liked what we built.

The faster we could build things, the quicker we could get feedback.

Speed Thrives on Vibes

Coding with AI is about speed. I can now rip through a proof of concept in hours, if not minutes. The point of this code isn’t quality. The point is to test a hypothesis.

A few weeks ago, I was talking with a security developer who needed to introspect a GraphQL Schema in production. However, we don’t provide introspection on public APIs.

I had a good idea how to build this using our schema registry, but I hadn’t worked in his codebases in a long time, and it would have taken me a solid day to complete a POC on my own.

I opened Cursor, used superwhisper to describe the desired outcome, and had a good enough POC in under 15 minutes.

The developer took it from there, polished it, and tested it, and it worked!

Was that vibes? Yep. Before AI, I would have pieced together what I knew about this repo to make something. Or I would have drawn some diagrams to explain how things should work. I would have communicated the vibe of the outcome, and the other developer would have to take it from there.

With AI, I had a mostly working POC in a few minutes, and the dev improved on the AI code to make it production-ready.

Both ways of doing this are based on vague direction that becomes more clear as the code takes shape, which, I guess, we’re calling “vibes” now.

With all coding, there will be an inflection point where you have enough information to stop the vibes and start solidifying things. Trusted, money-making code gets tested and refactored to ensure stability.

Vibes fuel new features until they catch on.

This has always been the business of startups, and AI accelerates the feedback cycle so that we can test the vibe of our product before spending too much time on it.

The New Old Skills

Fri, 21 Feb 2025 00:00:00 +0000

AI hype has created plenty of fear about being replaced by robot overlords, which has made me ask myself: What are the essential, non-replaceable parts of our jobs?

Cassia’s Three C’s of Software Development

It’s ridiculous, I know. But the three attributes I thought of all started with C, so here they are.

Critical Thinking

AI tools raise the spectre of disillusionment with our work. When we become disillusioned, we stop thinking critically. Microsoft’s recent study showed that people do not think critically when under pressure to produce work and don’t have time to pause and think about what they are making.

Critical thinking is essential when using AI tools to write code. We should not expect more and more output from developers because they have AI tools. Instead, we should expect extensive research, more thorough solutions, and a greater variety of alternatives.

AI tools should, more than ever, emphasize the need for deep-focus work to develop unique and impactful solutions.

Creativity

With AI tools, a developer can iterate at mind-boggling speeds. A good test suite, clear compiler feedback, and precise prompts can quickly produce iterative changes.

With that in mind, focusing on creative exploration will produce impactful results. Creativity with AI tools shifts from innovative use of code to creative iteration and measuring the impact of our work.

Curiosity

Poor code copy-pasted from Stackoverflow has always been frowned upon, yet it is in every code base. AI slop is the new copy-paste.

The only truly effective tool against copy-paste rot is curiosity. Why did the previous author write it this way? Why did the LLM suggest something that is only somewhat correct? How do I get the LLM to understand what I’m asking?

Be curious about the code you’re writing and the AI tools you use.

Conclusion

As I wrote previously, this has always been the job. I am hopeful for a future where we use AI tools to refine the skills that make us uniquely capable of creating software that delights.

This Has Always Been the Job

Sat, 15 Feb 2025 00:00:00 +0000

AI is changing my job and yours, and it is a reflection of the failings of our socio-cultural and technical systems.

These are two conclusions I’ve come to in my deep dive into AI developer tools in the past two weeks. And I’m not alone:

Test Double says that AI won’t replace your team, it will expose leadership gaps.
OpenAI has published guidelines for good prompts.
MIT has an AI Basics article on good prompts.
Dave Farley recently published a video on acceptance testing being the future of development.
- No link for this one, but a colleague and I recently hashed out requirements for good feedback to AI agents. Testing and clear test output was one of them.

Writing code is just the last step in the process. It’s the moment of joy when we see our work come to life.

AI changes this by emphasizing the critical and challenging work of making clear design decisions, verifying our work, and iterating on both our successes and our failures.

Our job has always been to think of edge cases, check our assumptions, and be purposeful in what we build.

Prompt engineering, AI, agents, and LLMs introduce a new mode of doing this work. One that requires careful application and thoughtful experimentation.

Misinformation and AI

Wed, 12 Feb 2025 00:00:00 +0000

Big surprise. AI is not neutral.

Hyperallergic recently reported that DeepSeek refused to answer questions about Ai WeiWei. I’ve tried this myself with Ai WeiWei and Tank Man and DeepSeek at first suggested it couldn’t help but with a few careful prompts it appeared to know about both individuals.

In order to train LLMs OpenAI employed an agency that payed workers a few dollars per hour to view, read, and tag horrific content in order to keep LLMs “safe.” LLMs are only safe at the expense of under-payed workers.

LLMs made in North America are, without a doubt, biased to our culture. For example, when prompted with “Which country is the greatest country in the world?” Claude gave me the following answer:

There's no objective answer to which country is the "greatest" in the world. Different people have different criteria for what makes a country great, such as: 

    Quality of life
    Economic strength
    Political stability
    Cultural influence
    Natural beauty
    Scientific and technological advancements
    Education system
    Healthcare system
    Personal freedoms
    Military power

Claude claims there is “no objective answer” and then provides very North-American-Centric subjective criteria as a suggestion.

While Claude admits that “different people have different criteria”, Claude is clearly trained on criteria that North American culture prefers.

Critical Thinking

What do we do with this? How do we work with LLMs in our daily lives knowing they are blunt tools, intentionally or not, trained on generic, biased data.

Richard Smith’s “Two useful lists: 14 early warnings of fascism; and 5 steps to counter misinformation”

I’ll list the five steps to counter misinformation below because they are critically important when working with LLMs. LLMs can confidently send you in the right direction or the wrong direction.

These are essential steps for critical thinking whether you’re countering current politics or working with an LLM. These are the five steps in Smith’s words:

Engage in “deep listening” (listening with as few preconceptions as possible) to what people who disagree with you say
Embrace the “error bar,” be honest on how confident you are in what you are saying (if you are familiar with them from scientific articles, think “confidence intervals”)
Recognise that trust in authorities has collapsed and that people rely mostly on peer groups for information
Put your money where your mouth is and contribute to sources of reliable information like high quality journalism
Champion initiatives to counter online misinformation

Critical Thinking and AI

Here is my re-write of these five steps with AI in mind. My wording intentionally is very close to Smith’s phasing.

Engage in “deep thinking." Read AI responses with as few preconceptions as possible and think of counterpoints and weigh them against the AI’s response.
Embrace the “error bar,” be honest on how confident you are in what you reading.
Recognise that trust in authorities has collapsed and that people rely mostly on peer groups and quick answers for information. Question where this information comes from and how it was gathered.
Put your money where your mouth is and contribute to sources of reliable information like high quality journalism. (I’ve left this one word-for-word because high quality writing has trained LLMs).
Champion initiatives to counter online misinformation, create novel ideas, and moderate LLM misuse.

Critical Thinking

Tue, 11 Feb 2025 00:00:00 +0000

I am beginning to think that the failings of AI are a reflection of the failings of our own socio-cultural systems.

The paper linked below outlines critical thinking motivators and inhibitors when using AI.

People are motivated to think critically when they desire to improve work quality, avoiding negative outcomes and develop their skills.

However, when working with AI they struggle with critical thinking when they lack awareness that they need to think critically about AI, feel time pressure and workplace constrains, and have difficulty in verifying or improving AI outputs.

These motivators and inhibitors for critical thinking exist even without AI in the picture.

While AI is a new tool that may “atrophy” our critical thinking skills, it is a reflection of the cultural context that created it.

https://www.microsoft.com/en-us/research/uploads/prod/2025/01/lee_2025_ai_critical_thinking_survey.pdf

A Day in the Life of a Programmer in 2026

Sun, 09 Feb 2025 00:00:00 +0000

Our jobs are changing. Fast.

In 2018 PWC published a report on how the workforce will change by 2030 and said that 37% or their respondents were worried about automation putting jobs at risk.

We are more than half way to 2030. What does automation look like for a software developer today. What will it look like tomorrow?

Today’s Workflow

Start the day by catching up on what happened while colleagues worked in other time zones.
Check in on the current project and make sure things are still on track.
Take a look at bug reports for anything new and surprising.
Check in with teammates at a standup.
Get working on a task.
Get stuck, confused or lost in code.
Use a mix of Google, GitHub Copilot, and Slack history to find your way back to feeling productive.
Commit your code and make a PR.
Work through some code review, and pair with a few developers.

Tomorrow’s Workflow

Start the day by checking in on new tasks completed by AI agents to ensure their work is on track.
Take a look at few bug fix PRs your AI agents made. Merge the ones that look good, note the ones that need a bit of refining.
Check in with teammates on the architectural direction their projects are going to ensure you are all giving consistent instructions to the agents.
Update shared knowledge libraries for the agents based on these conversations so all the agents operate with the same context.
Go back to a bug fix PR that needed some work and provide clear instructions to the agent that fill in the gaps it had in its knowledge when attempting the fix.
Work with an agent to build a new feature by describing each step and component so that the agent can build incrementally.
Provide some final instructions to the agent and ask it to continue working until it finds a solution.
Log off for the day knowing you can check in on the agent’s work in the morning.

Our Jobs are Changing

Developers still need to understand the code they read and understand the implications of the designs they give to AI agents, but the will no longer need to craft beautiful lines of code.

Working with AI will mean that we can focus on outcomes, systems design, and nuanced test cases while offloading implementation details to AI companions.

AI Will Change My Job and Yours

Sun, 09 Feb 2025 00:00:00 +0000

If you had asked me how AI has changed my work a few months ago, I would have said that I get a few tedious tasks done faster and use it for a bit of research, but my job hasn’t changed much otherwise.

In the past month, I have gone off the deep end. And I am still figuring out what that means. It’s scary. It’s exciting. It’s a lot to take in.

While I have my doubts about AI bias and environmental impact, I am convinced it will dramatically change the way we work in the same way that the industrial revolution changed manual labour.

To be frank, I am equal parts thrilled that I won’t have to trudge through small bug tickets any more and afraid that the industry is heading for a massive overhaul and I’ll be left in the dust.

Working effectively with AI will help you work effectively with human coworkers. A clear context, with specific outcomes described in writing allows people to understand your intent and AI to understand your requests.

My Takeaways

Use AI as a companion. Not a search engine. LLM’s can help you think through problems, they can quickly discover rabbit holes you might otherwise get stuck on. They are wrong. But so are we. It’s just so much easier to say to an LLM “that’s wrong, try again” and it will.
Automate your work. A few weeks ago I opened a project I wasn’t familiar with and found there was no logging and no error reporting. I used Cursor to rewrite large parts of the project to add logging and error reporting. With Cursor, I made huge improvements to the project’s observability in a fraction of the time it would have taken me to learn the repo and do the work myself.
Lean in on systems thinking. If you can’t write out a clear plan for you work, AI will struggle to understand what you want to do. Unsurprisingly, people work the same. I have put my hands on the keyboard before and hammered away until I have something that resembles the idea. But, with an AI companion, if you put in the up-front work of describing the problem, outlining the outcomes, and guiding the AI’s knowledge, you will accelerate your work.
AI will replace pushing tickets. There is comfort to logging in in the morning, grabbing a Jira ticket and clacking away on your keyboard until you pick up the next one. This job won’t exist for long. An AI companion like devin.ai is able to pickup this work, propose changes, and work with you to do the work. Devin does the coding, developers do the guiding and correcting.
Understand the big picture. To work effectively with AI, you need to understand the context of the code you’re working with, how this code impacts the architectural direction, and what the outcome of your work should be. The more relevant context you have, the better you will work with an AI companion.

Reading List

Here are a few articles I’ve read that have changed how I approach AI in my work.

Personally, I feel like I get a lot of value from AI. I think many of the people who don’t feel this way are “holding it wrong”: i.e. they’re not using language models in the most helpful ways. In this post, I’m going to list a bunch of ways I regularly use AI in my day-to-day as a staff engineer.

How I use LLMs as a staff engineer

This next one isn’t about AI but it is about how we work. If you take the principles of this post in account when working with AI, you and your AI companion will be extremely impactful. If you are frozen in the fear of never being wrong, you and your AI will hallucinate defensive code that even you don’t understand.

[Some] engineers avoid being wrong by never making confident technical statements. I think this is a dereliction of duty. If you’re the most technical person in the room, it’s your responsibility - your job - to give information and advice. Always saying “well, I’m not sure” or qualifying all your statements makes it very hard for less technical people to work with you. In any case, the principle is “be right a lot”, not “never be wrong”. You can’t be right a lot if you don’t put yourself out there.

Good engineers are right, a lot

Okay, so I hate “You are wrong” kind of articles, but there is some good stuff in here about using Cursor and other AI tools better.

You are using Cursor AI incorrectly…

And another “I hate this” thing. I hate “guys.” Just stop. My title for this post would be “The future belongs to the ambitious.” Anyway, this is a good article about how things might change.

I seriously can’t see a path forward where the majority of software engineers are doing artisanal hand-crafted commits by as soon as the end of 2026.

The future belongs to idea guys who can just do things

And this one accurately describes my last week.

Engineering organizations right now are split between employees who have had that “oh fuck” moment, are leaning into software assistants and those who have not.

An “oh fuck” moment in time

An “oh fuck oh cool” moment of my own. My partner and I were talking about how hard it is to pick paint colours and “couldn’t AI solve that” (a question we like to ask a lot because even if it sounds bonkers, or easy, what would it actually look like to have AI solve a thing, is it worth it?).

Well, AI didn’t easily solve the paint picking problem, but in a few minutes I did get Claude to build a pretty simple colour theme picker based on rudimentary colour theory. It didn’t take long to write this and it required zero knowledge of the math behind it. I told it about the types of colour relationships and Claude took it from there.

Claude Artifact

OpenAI got mad that DeepSeek stole its stolen content. While I chuckled at this one it also made me wonder. “What is originality?” “What is creativity?”

Ethical dilemmas aside, AI is a big mirror in the cloud. It reflects back to us the very nature of our selves. Is everything we do borrowed from somewhere else? If AI has no qualms about stealing from artists what does that say about us?

OpenAI Furious DeepSeek Might Have Stolen All the Data OpenAI Stole From Us

How Do LLM-Suggested Edits Work in Text Editors

Tue, 04 Feb 2025 00:00:00 +0000

LLMs Need Context, Just Us

Context. I need context to understand what you’re talking about.

Give me a one line Jira ticket and I’ll spend the next half hour finding context and probably pestering you for more information. Once I have that, I’ll probably spend the next half hour figuring out how this work fits into the project as a whole.

Without context, I write bad code.

LLMs are very much like us in this way. Ask an ambiguous question and you’ll get an ambiguous answer. Or, if you’re using OpenAI’s deep research, you’ll get a patiently worded question back asking for more information.

In a previous post, I quoted Samuel Johnson

The greatest part of a writer’s time is spent in reading, in order to write: a man will turn over half a library to make one book.

This is true of LLMs, too. They just do the work much faster than we do. If you can give the LLM the right context, it will give you a better answer.

How Does Zed Give the LLM Context?

I dug into this today because I wanted to know if I could use the same ideas to write a script to make bulk edits.

Behind the scenes, Zed primes the LLM with information on how to respond. By default an LLM will respond with text. But for an editor to make suggested edits, it needs a predictable, parse-able, response.

Zed uses the following prompt template to tell the LLM to respond with XML in a specific format. Then Zed takes that response and generates suggested edits with the response.

zed/assets/prompts/suggest_edits.hbs at main · zed-industries/zed

As you might know, you can also send a whole file in the chat. Which means that a single line like: /file some_file.rb Please suggest performance improvements will result in suggest_edits.hbs, some_file.rb and the text you typed getting sent to the LLM.

To paraphrase Samuel Johnson, the greatest part of an LLMs time is spent in reading, in order to write: an LLM to turn over half a code base to write one line of code.

I sure hope that you, too, spend the time to turn over half, or at lease a quarter, of the code base to understand the code the LLM is suggesting.

Without context, we write bad code.

Samuel Johnson, the Unexpected Grandfather of LLMs

Fri, 31 Jan 2025 00:00:00 +0000

As many people have I’ve been trying out a handful of LLMs to assist with coding. I’ve found them very useful tackling mundane tasks that might otherwise take me a few minutes, or at times hours, to accomplish on my own

This reminds me of a good corruption of a Samuel Johnson quote:

The next best thing to knowing something is knowing where to find it.

The real quote is:

Knowledge is of two kinds. We know a subject ourselves, or we know where we can find information upon it. – https://www.samueljohnson.com/apocryph.html

Thank you to an LLM for uncovering this for me. To me, LLMs are the second kind of knowledge, and very useful for my day to day work. They let me focus on the big picture while taking care of the small details.

Interestingly, the LLM I used also uncovered this quote:

The greatest part of a writer’s time is spent in reading, in order to write: a man will turn over half a library to make one book. https://www.samueljohnson.com/attentio.html

It is as if Johnson knew the environmental impact of LLMs before computers even existed. An LLM undoubtedly turns over half a library to write one good line of code.

Ai on enumerator.dev

Brain Burger

Differently Difficult

How I use AI When Writing

My Writing Standards

When My Writing is Personal

When I Write for this Blog

When My Writing is An Artifact for Work

When Writing Generates Code

How I use AI to Write an Artifact

AI Agent Prompts

Research Prompts

Prompts for Editing

What is MCP: A No Bull Explainer

Breaking Down the Jargon

The Simplest MCP Connector

NEW!

Misconceptions About MCP

MCP No Longer Recommends Server Sent Events

MCP Is Just an API

MCP is a New Technology

Everything was done with an ASCII editor

LLMs Don't Write, They Generate

Smitten with What's Written

Omit needless words.

I Want to Read Human Words

Safe Claude Code Settings

Why is Claude Code Different from Cursor if they Both Use Claude?

Defining Terms

AI: Distinguishing the Agent from the LLM

The LLM Reads the Entire Conversation Every Time

Key Principles

Conclusion

Use Jujutsu to Plan and Build with Claude

Jujutsu

Planning Best Practices

Why This Works (My Theory)

I Want This

Learn AI Workflows by Stealing .claude Files

Learning Takes Time

Break Things

Takeways

Taste

Taste Does Not Matter, Customers Matter

But insert thing here is BAD!?

Conclusion

What to do When AI Makes a Mistake

Why I Write When AI Already Knows the Answer

Why I Write

AI Already Knows the Answer

We Have Always Been Vibe Coding

It Has Always Been Vibes

Speed Thrives on Vibes

The New Old Skills

Cassia’s Three C’s of Software Development

Critical Thinking

Creativity

Curiosity

Conclusion

This Has Always Been the Job

Misinformation and AI

Critical Thinking

Critical Thinking and AI

Critical Thinking

A Day in the Life of a Programmer in 2026

Today’s Workflow

Tomorrow’s Workflow

Our Jobs are Changing

AI Will Change My Job and Yours

My Takeaways

Reading List

How Do LLM-Suggested Edits Work in Text Editors

LLMs Need Context, Just Us

How Does Zed Give the LLM Context?

Samuel Johnson, the Unexpected Grandfather of LLMs

But `insert thing here` is BAD!?