I’m building out a full container isolation system, but before it’s done I found a way better approach to preventing Claude Code from clobbering other instances… it turns out classic ol `cp` has a -c flag you can use (on apfs formatted mac disks, ie 10.13 or later) which does “copy on write.”

That means it won’t actually copy any files until they’re written to… which saves the time (and storage) of copying actual data unless you actually write to it.

So seriously you can do

cp -c original.txt clone.txt

and if you never write to either file, they’ll stay the same. If you write to either, they’ll split into their own files.

Networking and other isolation concerns still exist, but this can solve basic collisions. Containers will solve this, more coming on this soon.

I've found the best way to understand how an AI works is to pretend you're working with a college student who is extremely capable, but inexperienced. Imagine you're giving an intern directions about how to complete a task. For them to do the baseline, you might want to start by giving them explicit instructions and examples. But in order to train them to do the right job, you need to help them understand the right mindset.

At Facebook, I worked with a lot of new grads and helped push them toward their potential. The thing I found always worked was asking them questions, not pushing them toward specific answers. I imagined, "how did i discover this topic?" and "how can I help Max discover this topic?"

The key was never giving a ton of context, it was giving the right context at the right time. It didn't matter how capable Max was at engineering, they wouldn't ever be able to do the thing they needed to do if I just overwhelmed them with everything possible.

So imagine you're talking to a friend, a new developer, or really anyone, and then try to give them the right amount of context to do the job. I've found the hourglass as a great framework to build context for LLMs (and people, to be frank) and try to get your LLM friend to do things one at a time.

Rather than create the biggest prompt, focus on making one task at a time work. Often times that's classification tasks, and then moving on from there to more complex tasks. You'll find a pipeline the best tool for the job generally, so getting familiar with job queues and distributed non-linear systems might also be great places to start.

But the first step, truly, is empathetic reasoning

.

But I think this is only half the equation.

Lets watch this cool video of a laser etched dog tag:

The laser engraver represents context engineering itself: a process of precision and focus. The engraver must follow an exact path to etch a design. This is similar to how you want to construct a prompt to guide the model’s attention.

The dog tag represents a different, more primitive technology. Millions of identical blank tags were pumped out of a factory, using the exact same process at thousands a minute. If context engineering is like a laser engraver, lets call the dog tags a scaffold.

What Is a Scaffold?

A scaffold is a computer program that writes boilerplate code. It’s code that generates code, but without an LLM. The key benefit here is it’s deterministic: It works the same way every time. Scaffolds help AI write better code, because now the AI can focus on the unique parts of an application, instead of the boilerplate.

Rails + React

I spend a lot of time in Ruby on Rails, and I prefer using React on the front end. This isn’t exactly a default combo, and there are a dozen ways to wire the two technologies together.

Here’s the problem: even with carefully crafted prompts and “rules,” language models just don’t set it up the same way every time. I wind up with three methods to send data to the front end and like five to send it to the back end. The LLM is just taking its best guess each step along the way.

So I built a scaffold1.

Now, when I spin up a page, it follows the layout I actually use and not some boilerplate hallucination. I still use LLMs, but only for the bespoke stuff: business logic that will change with every application. The LLMs can dance on top of the generated code from the scaffold. It’s faster, cleaner, and way less frustrating.

Scaffolds aren’t glamorous or demo-worthy, but they’re the invisible infrastructure we’ll increasingly rely on to make LLM-powered workflows truly reliable. The challenge isn’t generating output, it’s guiding it. The future won’t be written by LLMs alone; it’ll be shaped by the scaffolds that guide them.

How many times have you dived straight into building with an LLM only to get 80% of the way there and hit a wall? That maddening loop where Claude confidently says, “I see the issue!” only to fix nothing and start again.

Context Engineering has come to prominence in the last few weeks because actually directing a model’s attention is a real challenge that requires effort and skill. The science of giving an LLM just enough context to accomplish the task at hand is a critical aspect of reliability.

It’s tempting to cram everything into your first prompt and hope for a perfect one-shot response. And while you may one-shot it once in a while, generally your model is going to fail.

The better approach is to tell your LLM, “Here’s my objective, ask me questions about it one at a time until you have enough information to move forward.”

At Bolt Foundry we use Claude Code for development, which allows us to create custom commands. In our environment we created a custom command called /questions-one-at-a-time that prompts Claude to, well, ask questions one at a time before generating code or completing a task.

At Bolt Foundry, our cardinal rule is: Discovery before developing.

This is the human version of “questions-one-at-a-time”. It forces us to pause and really understand the problem before writing a line of code (or asking Claude to do it).

Breaking a problem down into discrete questions that follow a logical flow is better for me as the user and for Claude. It helps us both focus our attention to understand the problem and create better plans.

Reliability comes from structure, not luck.

We’ve found the Hourglass method to be the best way to provide context in a structured way that doesn’t overwhelm the model.

Model attention is a scarce resource. Guard it ruthlessly and do everything in your power to focus it only on what matters most….or you’re gonna have a bad time.

It turns out if you talk to LLMs like you talk to people, they actually perform better. I studied communication in college, and learned there’s a few techniques you can use to help people understand a topic better.

The simplest one? Inverted Pyramid. In a nutshell, if you start with the most crucial information at the top, and work your way down to background info, the flow helps people get the most important information as quickly as possible. If they need to know more they keep reading.

Inverted pyramid system prompts

At Bolt Foundry, we’re building out a system for this, but the concepts are pretty universal. Essentially, you want to describe to the assistant the “Who / Why” before the “What”, and then lastly the “How”.

We’ll post more about this, but guiding an LLM into its role, instead of telling it precisely what to do and what not to do, means the LLM will be able to perform better than if you give it a list of do’s and don’ts. The Waluigi effect is less likely to happen if you “soften” the params, and make it less like a recipe and more like a dossier.

NEVER INCLUDE VARIABLES IN SYSTEM PROMPTS

It’s in caps for a specific reason: System prompts are the most valuable tool in guiding an LLM. They’re the first information the assistant sees, and LLM developers are building chain of command into everything they do. System prompts should contain developer specific messages which cannot be overridden.

Additionally, prompt caching means that providers are more likely to start inference in the middle (cached) than at the beginning, and if you change your system prompt all the time you lose out on this opportunity.

(There’s a bunch more I’ll explain later, but trust me: DO NOT MAKE SYSTEM PROMPTS DYNAMIC.)

Add context to user turns

Okay, so if you’re not allowed to put variables in the system prompt (SERIOUSLY DON’T) then how do you include them?

User turns, of course.

But then what if you don’t want to make a bunch of calls over and over just to get the assistant up to speed?

Then don’t do that. Just make synthetic user turns.

Context is the bottom of the hourglass

Did you know you can just send the OpenAI (compatible) completion endpoint an array of messages? Like, they don’t have to be generated by the LLM before… you can just pretend the LLM said them and the LLM will complete them.

So just create synthetic user turns, and provide all of your context in the synthetic user turns. Importantly, make it so the user turns are ordered from least important to most important. My recommendation is “user info” i.e. user supplied content, then any context you want to provide, and finally the output format you want.

You need to provide assistant turns just like you would if it was real, but just make the assistant ask for the precise information you need.

OK, but seriously how do I know this works?

I’ll have data for you soon, but aibff (the Bolt Foundry tool for doing evals / decks / cards / contexts / samples) will let you build this stuff just using markdown.

It’s really the earliest days for us, so the best way to find out what’s going on is this newsletter, or boltfoundry.com if you care. Also, reach out to me, x.com/randallb.

Universal laws are for lackeys.

Context is for kings.

— Gabriel Lorca

If / then. 0s and 1s. True or false?

For as long as I can remember, I’ve always heard about how computers were driven by binary, and how everything could be distilled into two distinct states: On or off.

Then, I used GPT-3 for the first time. It was very un-binary.

Depending on the text I wrote before I ran the completion, I could get wildly different results. And that’s cool, and can make great new experiences, but it’s hard to build a business on wildly different results.

LLMs are more like construction contractors than software.

Have you ever worked with a handyman to do construction around your home? Ask them when they’re going to come fix that hole in the window. Or when they’re going to finish painting that room.

Tomorrow will be a liberal term for “in the future when all things line up the way I expect and I remember to be there.”

For a homeowner, waiting to get something done is fine, because as long as the promise of a less-expensive fix, regardless of when it happens, is appealing because paying less for something that eventually gets delivered at an acceptable quality is a tradeoff most people can make.

But not for businesses.

Imagine your employee shows up every day exactly when you ask, but 20-80% of the time they can’t complete the task without extreme oversight. Maybe they’re having a bad day, maybe they’re drunk, but either way, it’s going to be hard to make it work.

At best you’d build a system of redundancy, but at worst, you’ll destroy your business’s credibility, or spend so much time managing this employee, you won’t end up better off than you started. Either way, quality control and performance reviews are a must.

Good employees do what they’re told. Great employees do the work without being asked.

So this is the trick, right? How do you make sure your employee shows up every time reliably without micromanaging them?

Context, it turns out, isn’t just for LLMs, it’s for people too.

I’ve only had two managers (Blaine Mucklow and Randolph Faust) who have ever understood how i work, and how to put me in positions to succeed.

The difference between them and every other manager I’ve ever had? They gathered organizational context on my behalf, and then helped me focus exclusively on what needed to be done next.

For me, they are context engineers: People who skillfully understand the problem space, and gave me the right information at exact the right time.

I got the highest performance rating available at facebook… a feat that is extremely rare.

Empower and communicate, don’t command and control.

Bad companies and managers treat their employees the way we treat LLMs. They just give vague ideas, in whatever order seems pertinent, and hope things work.

Great companies treat their employees like partners. They give them freedom and autonomy to make choices, and concentrate more on outputs than process.

So then how do we treat our LLMs more like partners?

Empathy, it turns out, is the key trait of both. Figuring out what your coworker needs to understand, without burdening them with detail, is the difference between a high performer and a person or LLM you want to fire.

Communication is the new code

We’ll be talking at length about how communication now matters more than code. 10x engineers have always needed to be effective communicators, but now everyone needs to be.

I’m the product of computer science and communication. I can’t wait to show you how to how communication changes everything.