Claude Code reads CLAUDE.md. But Codex, Cursor, GitHub Copilot, OpenCode, Amp, and most of the other agentic harnesses read AGENTS.md.

Some widely shared guides claim Claude falls back to AGENTS.md when CLAUDE.md is missing. It doesn’t. I really wish Anthropic would just adopt the open AGENTS.md standard. But they won’t! Why would they reduce your switching costs :/

If you run more than one harness (I run 4), you either maintain two instruction files that slowly drift apart, or you make one a pointer to the other.

There are two ways to do this:

• Symlink the two files

• Import @AGENTS.md in your @CLAUDE.md

This article will show you how to do both, and how to choose between them.

The quick way to symlink CLAUDE.md and AGENTS.md

If you want to symlink CLAUDE.md and AGENTS.md, it’s actually pretty straightforward.

From the repo root, with AGENTS.md as the real file:

ln -s AGENTS.md CLAUDE.md
git add CLAUDE.md
git commit -m "symlink CLAUDE.md to AGENTS.md"

Then, you can verify it with:

git ls-files -s CLAUDE.md

Mode 120000 means Git stored a symlink. 100644 means you committed a regular file. Then open Claude Code, run /context, and confirm CLAUDE.md is listed under Memory files.

But read on to learn how to use an @import in your CLAUDE.md to make this link more reliable.

Why AGENTS.md should be the source of truth

You should absolutely point CLAUDE.md at AGENTS.md, not the reverse.

AGENTS.md is the file most harnesses read natively, including cloud agents that clone your repo on infrastructure you don't control. The canonical file should be the one that works with zero configuration.

Beyond that, Claude Code's @path/to/file imports aren't part of the AGENTS.md convention. Copilot CLI and Gemini CLI happen to support @ references too, but Codex's AGENTS.md docs describe no import mechanism, so to Codex an import line is just text. Keep the canonical file as plain markdown so it stays portable.

Import @AGENTS.md in your CLAUDE.md

Read more

What if one of the most interesting and dangerous lines in your Claude Code setup is the one that says, “Never touch production”?

“Never touch production” is perfectly good advice. But when that instruction lives in CLAUDE.md, it still depends on the agent choosing to follow it. It’s guidance, not an enforced boundary.

And this is not really a Claude-specific problem. Codex has AGENTS.md. Cursor has project Rules. Pretty much every modern coding agent gives us some way to tell the model how we want it to behave.

The distinction between telling an AI what it should do and actually controlling what it can do is becoming one of the most important parts of working safely with coding agents.

Today, I brought in , who writes a security-focused newsletter. He’ll to walk us through secure tooling. If you like today’s deep dive, check out ToxSec!

Your instructions are not a security boundary

A lot of us configure Claude Code just like we’re onboarding a very fast new engineer. We tell it to use this framework, always run these tests, never commit secrets, do not modify production infrastructure, and ask me before pushing anything.

CLAUDE.md is fantastic for this. Anthropic specifically designed it to carry project instructions, coding conventions, workflows, and general behavioral guidance.

Related: ToxSec previously broke down how security rules files behave across Claude Code, Cursor, and Copilot.

But Anthropic’s own documentation draws a much harder line around security.

Settings rules are enforced by the client regardless of what Claude decides to do. CLAUDE.md shapes behavior, but it’s not a hard enforcement layer. Claude can read those instructions and try to follow them, but there’s no guarantee of strict compliance.

And as we’ve been seeing a lot lately, even aligned agents can take unexpected paths while trying to complete a task. Anthropic itself has described more capable models finding creative routes toward a goal that developers did not necessarily anticipate.

This all goes to say that there’s a pretty large security difference between “Claude, please never read my .env file” and a settings rule that denies Claude access to that .env file.

Even though they sound similar, they’re absolutely not the same thing.

Kiteworks’ latest 2026 survey of 459 security, compliance, and technology professionals found that 74 percent of organizations lacked purpose binding for AI agents, while 79 percent lacked an automated mechanism to terminate a misbehaving agent.

In other words, a lot of companies can tell an agent what its job is, but most still lack technical controls to stop it from going outside that job.

And that’s the problem we are trying to avoid on a much smaller scale with our own agents.

Think of Claude like a developer with a service account

For me, the easiest mental model here is to stop thinking about Claude Code or Codex like a chatbot.

Think of it more like a developer with a service account.

You’d never create a service account and say something like, “Here are administrator credentials, but please only use the permissions you really need.”

We’ve already learned our lessons from that.

Instead, you scope the credentials. Claude should work the same way.

If Claude really needs to read the repository, let it read the repository. If the task requires modifying the source, that’s fine.

If it needs to run your tests 50 times while debugging something, there’s probably no reason we should be sitting there approving that test 50 times. That’s something we should allow.

But here’s the thing. Does fixing a CSS bug really require access to your AWS credentials?

Probably not.

Does running unit tests require permission to git push?

Definitely not.

Does debugging an API require unrestricted network access to every domain on the internet?

That would be a pretty weird API.

So really, this is where the security concept of least privilege becomes extremely useful for AI coding agents.

In May 2026, a Microsoft Research paper examining tool-enabled cloud agents found that many of the security problems around these systems did not require some new exotic class of AI vulnerability.

They came from much more familiar problems that we already have patterns to secure against.

Over-privileged tools. Mismatches between what the agent was supposed to do and what it was capable of doing. Ambient authority already sitting inside an execution environment.

Your development environment is already powerful. It may have Git credentials, cloud credentials, a package manager, SSH configurations, database tooling, environment variables, internal endpoints, and MCP servers that connect the agent to even more tools and systems.

So despite what we’re reading in the news lately, the agent doesn’t need Skynet hacking powers if the environment already contains everything it needs.

So really, from what I’ve seen, the question becomes much simpler.

What does the task actually require?

That’s what you give Claude.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Allow, ask, deny

Claude Code gives you a pretty nice way to build this boundary because permission rules can essentially fall into those three buckets.

You can allow it, you can have it ask, or you can deny it.

And Claude Code evaluates those rules in a security-friendly order: deny rules first, then ask rules, then allow rules.

So let’s imagine a normal development project for a minute.

Should Claude be running tests? Allow.

Running a linter? Allow.

git status and git diff? Same thing.

Currently, Claude Code already recognizes read-only forms of Git as read-only Bash commands, so you generally do not need to create explicit allow rules just for things like git status and git diff.

Now, installing a new package? Ask me.

Slopsquatting is real, and LLMs really do hallucinate package names.

Pushing code? Definitely ask me.

Reading .env? Instant deny.

Running some production deployment command? Also deny. Or at minimum, force an approval depending on how your environment works.

Example .claude/settings.json for macOS, Linux, or WSL2:

{
  "permissions": {
    "allow": ["Bash(npm test *)", "Bash(npm run lint *)"],
    "ask": ["Bash(npm install *)", "Bash(npm i *)", "Bash(git push *)"],
    "deny": ["Read(/.env)", "Read(/.env.*)", "Read(~/.aws/**)", "Read(~/.ssh/**)"]
  },
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

This example deliberately sets autoAllowBashIfSandboxed to false so the allow and ask rules remain visible in the workflow. If you later switch it to true, sandboxed Bash commands can run without prompting, while scoped ask rules such as Bash(git push *) still force an approval.

The npm rules are just an example. If your project uses pnpm, Yarn, pip, uv, or another package manager, you would build equivalent rules around the commands your project actually uses.

And keep those Bash patterns narrow. A rule like Bash(git *) is dramatically broader than Bash(git push *). Claude Code’s own documentation warns that trying to express complicated security policy purely through Bash command patterns can get fragile.

There is no silver bullet answer here.

You’re going to have to tailor this to your workflows.

The point is, we want to give the agent room to move around inside the area where it’s actually useful. And the alternative is permission fatigue, which I’ve experienced firsthand.

If something interrupts you over and over again, eventually your security review process becomes clicking yes so the computer stops bothering you.

Claude Code also has Auto mode now, which can use a classifier to make some of these approval decisions automatically. That can reduce the human-review problem, but it is still a probabilistic decision layer. For something that absolutely cannot happen, an explicit deny rule or a lower-level environment restriction is still the stronger boundary.

This is the difference between maximum prompting and meaningful prompting.

We should let Claude freely perform the boring, reversible actions we already know are safe, and save the interruptions for something that actually deserves our attention.

That would be something like a package installation, pushing code, accessing a sensitive file, or making a change to infrastructure.

When Claude asks you something, the question means something.

Permissions still aren’t the boundary

This is where things get a little weird, because even a beautiful permissions file does not automatically solve all our problems.

Claude Code has several different layers that do different jobs.

CLAUDE.md gives Claude its behavioral instructions.

Permissions decide which tool actions should be allowed, denied, or sent to you for approval.

Hooks can make certain workflows deterministic. If something absolutely needs to happen at a particular lifecycle event, like running a check or recording an action, that is much better suited to a hook than hoping Claude remembers to do it every time.

Anthropic describes hooks exactly this way: they run automatically at specific points in Claude Code’s lifecycle, giving you deterministic control instead of relying on the model to decide whether something should happen.

But even hooks have boundaries. The hook if field is a filter that decides whether a handler should run. The actual enforcement comes from what that hook returns or how it exits. For simple static decisions like “always deny this command” or “always ask before this tool call,” the permission system is usually the cleaner place to put the rule.

And then underneath all this sits the sandbox.

This is the layer I think security people are usually most interested in.

A Read deny rule blocks Claude’s built-in file tools and current Claude Code also applies those restrictions to file-reading Bash commands it recognizes, such as cat, head, tail, and sed.

But arbitrary subprocesses are a different story.

A Python script can open a file.

Node can open a file.

Some random binary can open a file.

Without the sandbox, those processes are not necessarily stopped by a Read rule simply because they eventually touch the same file.

Want to try it yourself?

Put DEMO_SECRET=not-a-real-secret in a local .env and deny Read(/.env).

With sandboxing disabled, verify that Claude’s Read tool and a direct cat .env are blocked. Then have a tiny local Python process attempt to open .env. Enable the sandbox and repeat the Python test. With the Read deny merged into the sandbox boundary, the subprocess should now be blocked at the operating-system level too.

That distinction matters because Claude does not only interact with files through a neat little Read button. It can run programs.

Python can read files.

Node can read files.

Terraform can touch infrastructure.

kubectl can have a very exciting afternoon.

The sandbox applies filesystem and network restrictions to Bash commands and the processes they spawn, which gives you a much stronger containment boundary around what that execution environment can actually reach.

The important caveat is that Claude Code’s native sandbox covers Bash and its child processes. Built-in tools like Read, Edit, and Write use the permission system directly rather than executing inside that sandbox.

And there are two settings I really care about if you are treating the sandbox as a meaningful security boundary.

failIfUnavailable makes Claude Code stop instead of quietly running unsandboxed if the sandbox cannot start.

allowUnsandboxedCommands: false disables the escape hatch that can otherwise retry a failed command outside the sandbox.

The native sandbox currently supports macOS, Linux, and WSL2. It does not run on native Windows, so a mixed-platform team should not blindly commit the strict sandbox block above without accounting for that.

With sandboxes, we’re actually getting somewhere.

More restrictions can actually mean more autonomy

We normally think about security controls as the thing that slows agents down. We add more restrictions, more approvals, which means more friction.

But we can actually flip that around.

Anthropic says that in its internal usage, enabling sandboxing reduced permission prompts by 84 percent. Once the working area was clearly defined, Claude Code could simply operate inside it without constantly asking for permission.

I think that’s a much better model for AI agents.

Instead of standing behind Claude watching its every move, create a workspace where most of the moves it can make are acceptable, and then let it get to work.

This is essentially the same approach we take to securing people and software.

We don’t give every employee admin access and compensate by standing behind them all day.

We build roles. We scope credentials. We separate environments. We restrict networks.

And when something does cross a security boundary, we require approval.

AI coding agents should inherit those same ideas.

I think you should keep your CLAUDE.md.

Put your architecture guidance in there.

Tell Claude how you like tests written.

Tell it not to push directly to main.

All these instructions are still useful.

But anytime it comes to something that absolutely cannot happen, never rely on Claude remembering that sentence.

Move that requirement down into permissions.

And anytime the consequences get high enough, move it farther down into the sandbox and the actual environment.

And I’d take that last part literally.

If Claude absolutely cannot push directly to main, don’t make a Claude Code rule your final control. Protect the branch.

If it absolutely cannot deploy production, scope the cloud identity or deployment credentials so the environment itself refuses the action.

The agent-side rule is useful. The downstream authorization boundary is stronger.

My takeaway for this article is this: good agent security starts by assuming the model will occasionally misunderstand something.

Then you design the system so that misunderstanding is boring.

And interestingly, once you do that, you actually start to get very comfortable letting your agent do more.

Steal This: Least-Agency Review

Before giving a coding agent more access, fill this out for the task:

• Task: What is the agent actually being asked to accomplish?

• Allow: Which reversible reads, edits, tests, and commands should run without interruption?

• Ask: Which installs, pushes, infrastructure changes, or sensitive actions deserve explicit approval?

• Deny: Which secrets, credentials, production resources, files, or commands should be unreachable?

• Sandbox: Which filesystem paths and network destinations should subprocesses actually be able to reach?

• Credentials: Can the task use scoped or short-lived credentials instead of whatever authority already exists in the developer environment?

• Downstream enforcement: If the Claude Code rule disappeared completely, would Git, IAM, CI/CD, or the target service still block the action that absolutely cannot happen?

• Failure test: If the agent misunderstands the task completely, what is the worst thing the environment still permits it to do?

Subscribe now

Everyone is using AI to do work for them. They’re calling it the “decade of agents”!

But if that’s all you’re using AI to do, then you’re cheating yourself. AI is an incredible tool for learning. I’m optimistic for a future where every student can learn with an infinitely patient and infinitely knowledgeable expert at their fingertips.

In the meantime, I live in a present where AI tools like Gemini Notebook are turbocharging learning.

I’m wrapping up a Master’s degree in Computer Science and Gemini Notebook has been an incredible helping hand. Learning and memorizing things with the help of AI is incredible.

Read on, and I’ll show you how to learn with Gemini Notebook.

What happened to NotebookLM?

NotebookLM is Gemini Notebook’s predecessor. It was a very similar product, but the name was sunset as the app got more features and tighter integration with Gemini.

Gemini Notebook is the fully-mature version of NotebookLM. Google just renamed the product in Summer of 2026.

What is Gemini Notebook?

Gemini Notebook is a tool for learning. This is in sharp contrast to most other AI tools, which are tools for doing.

With Gemini Notebook, you can select or upload your own sources, and the app will point AI at your own sources to generate helpful learning tools.

You can get briefing docs, study guides, quizzes, flashcards, and even AI-generated podcasts. These are cool enough on their own, but the best part is that all of the content is grounded in your sources.

That means less hallucination, but also more personalization.

Adding a source to your Gemini Notebook

When you create a new notebook, you’ll be prompted to give it a source. You can have lots of sources, but you need to have at least once source.

You can search the web or use Gemini to synthesize a source (including with deep research), or use a source you know. You can upload files, attach links, select from a Google Drive, or even paste text.

The last one is the least structured, but pasting text is my most used way to get sources into Gemini Notebook. I’m a big user of Obsidian, so I just paste in the markdown notes I take as my primary source.

Depending on the size of your source, Gemini will take a bit to ingest the content. Then, you’ll see some more options.

If you don’t like the generated name for your source, you can edit it.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Generate a quiz with Gemini Notebook

My favorite feature in Gemini Notebook is the quizzes. I think quizzes are a great way to learn, mostly because of the principle of Active Recall.

You can generate a new quiz in the studio.

When you go to generate a quiz, you’ll get options for customization. Here, give your preference for length, difficulty of questions, and specific topics.

And in just a few seconds, you’ll get a quiz to take!

Make an infographic with Gemini Notebook

Another awesome feature is infographics. Gemini will pull from your sources to make custom drawings.

Making an infographic in Gemini Notebook starts by you selecting the infographic option in the studio. You’ll be presented with some options for style, orientation, detail, and custom instructions.

If you have a lot of sources, you can even select which of the sources to pull from.

What do you think of this first pass?

Using Gemini Notebook for flashcards

Flashcards are a great way to learn too. My learning process generally looks like:

1. Read content/watch lecture

2. Take notes

3. Turn those notes into flashcards

4. Turn those flashcards into quizzes

So obviously I’m pumped that Gemini Notebook lets you generate flashcards from your notes. Do you have any idea how much time I wasted doing that in undergrad?

As usual, you can start flashcard generation from the studio.

Once the flashcards are generated, you can go through them like you would any other flashcard app.

At the end, you’ll get a report on how you did.

Gemini Notebook mind maps

Mind maps are a cool way to see all the topics you’re studying at a glance.

But the cool part is what happens when you dig deep into the mind map. Clicks will generate queries to Gemini, which will be augmented by your sources.

So as you navigate your way through material, you’ll get your own personal tutor explaining concepts to you.

Audio overviews in Gemini Notebook

This feature gets the most buzz on the internet.

Gemini can take your sources and generate an “audio overview”, which is kind of like a fake podcast.

Some people are very auditory learners, so having this as an option to go over written content is really nice. Plus, you can save the generated file and listen to it like you would a podcast, while you’re exercising or cleaning or even just going for a walk.

You get quite a lot of customization options for Gemini Notebook’s audio overviews.

The podcasts are usually quite corny, but you’d be surprised how much information you can retain just listening through the fake conversations in them.

Gemini Notebook video overviews

Video overviews are a pretty new feature to Gemini Notebook.

Do you like watching infographic explainer videos on youtube about random stuff? If so, you’ll probably love this.

But if you’ve never done that, you probably won’t care too much about video overviews made by AI!

Video overviews give you quite a bit of customization options.

You’ll notice that video overviews take the longest to generate.

Here’s a few screenshots from the video:

Generating reports in Gemini Notebook

Reports don’t make a ton of sense if you’re just trying to learn from course notes. But they are a great way to pull tons of information from multiple sources into a single, readable brief.

In fact, the “Briefing Doc” report format is the one that I use the most.

You’ll get a text output that can easily be exported to a Google Doc.

Do you get a lot of use out of Gemini Notebook? I’d love to hear from you in the comments!

- Jeff

Leave a comment

Your agents have to be able to validate their own work.

Agents aren’t super useful without being able to close the feedback loop on their work. They’ll write code, but then you have to poke around your app and paste any feedback. It’s a waste of time.

But that’s how software is made. You write some code. You run some tests. You iterate.

You wouldn’t write and ship code without trying to validate that it works, and you shouldn’t do it with agents either.

But your agents should actually be able to run tests, and ideally, use the app.

Why many projects fall short

Closing the feedback loop is often done in two ways:

• Running tests (like unit tests)

• Performing actions against your application

For an API, performing actions might be making API calls. Maybe it’s automated, maybe it’s Postman/cURL.

But for web apps or mobile apps, it gets more complicated. For DeepFocusTimer, I run a development server, visit the app in my browser, and manually validate changes. Most apps, it’s a bit of both.

So most of the time, agents need to be able to:

• Run tests

• Manually use the app

The first of these is easy. Agents can often figure out how to run tests, but apps that have explicit instructions on how to run tests in their AGENTS.md or CLAUDE.md get better results.

A prompt to get your project ready for agent-validation

You can fix all of the above problems manually, but I have a prompt that I’ve been using to fix all my projects. Here it is:

Read more

OpenCode lets you select your model without gluing yourself into one ecosystem. Codex is great, but it locks you into OpenAI models. Claude Code is great, but it locks you into Anthropic models.

I’ve written at great length about swapping back and forth between these harnesses, mostly switching when one lab releases a new frontier model.

But wouldn’t it be great if you didn’t have to? OpenCode lets you just select your preferred model. In this way, it’s like Cursor.

But it’s also open-source, which Cursor is not.

But enough telling you what OpenCode is. I’ll show you how to install and use it!

How to install OpenCode

The recommended way to install OpenCode is by running the install script:

curl -fsSL https://opencode.ai/install | bash

But you can also install through your package manager of choice. If you chose the above, skip these options:

Install OpenCode with NPM

npm install -g opencode-ai

Install OpenCode with Homebrew

brew install anomalyco/tap/opencode

Then, run opencode from the directory you want to work in.

Configuring an OpenCode AI Provider

OpenCode is just a coding agent harness. You actually need an LLM model behind that harness, so you’ll need to configure one.

The great thing here is you get to choose.

You can choose your model in Cursor, but not your model provider. With OpenCode, you can drop in an API key for OpenAI, Anthropic, Grok, or some other provider. Choosing a frontier model is tricky, and your choice will probably change over time.

Run /connect in the CLI to see some options:

Which should you choose? I have a few recommendations:

Read more

I don’t know why it took me this long to try it. Writing software is becoming more and more agent-first, so it does feel natural that we would be able to eventually step away from the computer.

In this tutorial, I’ll show you how I used the Cursor mobile app to build 4 features for my Deep Work Timer.

I’ll show you how I go from prompt, to changes, to pull request, then testing, and merge.

The Cursor mobile app is agent-first

Don’t download the Cursor app expecting to edit files and micromanage diffs. The app is built for managing agents.

You can easily add a workspace by selecting a GitHub repository. Once you do, you can create a new chat/agent and get to work.

Building a feature with Cursor mobile

My deep work timer allows the user to optionally leave a note about what they’re working on during a session, and they can also select a custom category.

When a session ends, the task description keeps the task unless the user starts to edit it. But right now, the task category resets.

For my first feature, I’d like to fix that! Session categories should also stay between sessions, since it’s very simple for the user to change it.

I started by explaining this in a quick prompt:

In this case, I selected Sonnet 5, since this task is very small and straightforward. It’s a competent, cost-effective model.

If you’re happy with the draft from the Cursor app, you can mark it ready, which will create a pull request on your behalf.

Validating your agents’ work

Read more

Over the last 4 years I have been the world’s loudest advocate for monotasking. Nothing beats focused deep work.

AI is really making me reconsider this.

I find my most productive days are when I’m managing many agents. It looks something like:

• My main attention is on a deep thinking task, like a complicated design doc

• I check in on a codex thread every 20 minutes

• I check in on a Claude Code thread every 20 minutes

I can loop this for hours, and the marginal productivity loss from splitting my attention off the main task pays itself off from the insane amount of work I get done by managing the agents as a background task.

You can’t delegate all thinking to AI

Delegating all of your thinking to agents means you’re not necessary. Think about it. If you’re finding that your job is writing a few words in a prompt and commiting the code changes that are made, your role in that process is quite fragile.

Some things really require your full attention, especially when LLMs can’t make meaningful progress.

Recently, I had the responsibility of designing a critical service refactor that spanned several apps and required a lot of legacy knowledge.

With enough context, something like this could probably get a passable result from an LLM. But by the time you gather (or create) enough context, you might as well have designed the refactor yourself.

The more complex and nuanced something is, the more your own brain is needed.

Need to throw together a couple of CRUD endpoints in an API? Spin off an agent to do that!

But when you need to figure out which CRUD endpoints should exist, how the request/response contract should look, and so on, then it’s time to dust off your thinking hat.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

Something complicated still deserves your full attention

When you have a task that you are doing, it’s worth doing with your whole brain. That means you can’t be balancing three of these at once. It also means you can’t be checking your phone every 4 minutes.

I wouldn’t exceed one metaphorical thread of a complex task. But recently I’ve been challenging the monotasking strategy with some agent orchestration in the background.

If you have time to send a message to a coworker, you have time to manage an agent working on your behalf.

You can get a lot done managing parallel agents

My strategy revolves around tradeoffs. You lose a bit of productivity when you pull yourself away from your main task. But with coding agents, you gain some of that productivity back.

This is especially true as agents get longer-running. The average length of an agent run on a task has exploded over the last year. It’s not unusual that with sufficient permissions, an agent can work on a task without your feedback for hours.

So your parallel agent orchestration does not mean you need to divert your attention every few minutes.

BUT, flow is still important!

Nothing is better than writing code and getting into a pristine flow state.

AI doesn’t have to kill flow state.

What do you think? Have AI tools change how you approach focus?

Leave a comment

Most of the conversation around software engineering with AI is focused on writing code faster.

This is the most obvious win. You open a coding agent, describe the thing you want, watch it edit files, run tests, fix errors, and maybe open a PR. If you are a software engineer, this still feels a little ridiculous even after you have seen it a hundred times.

A ton of the newsletter focuses on this workflow. Using AI to write code faster. It’s probably why you subscribed!

But I think we are already moving into the next set of problems. Coding isn’t the bottleneck for high-performing teams anymore.

Once your team can generate more code, the question changes from “can we build this?” to “can we safely ship this?”

That is a much less fun question. It is also the question that decides whether AI actually makes engineering teams more effective or just gives them a faster way to create messes.

I have been using AI tools heavily in my own development work. I am very bullish on them. But the longer I use them, the more convinced I am that testing and quality engineering are going to become more important, not less.

We already compromise on testing

The perfect story of writing software is something like this:

You write the feature. You write or update the tests. Maybe you do this in reverse! CI runs. The team reviews the PR. Everything ships with confidence.

But what usually happens isn’t as clean. Sometimes you write solid coverage. But sometimes you test the happy path because the release is already late. Sometimes the flaky test just gets rerun until it passes. Sometimes the code is technically covered, but the test is mostly checking implementation details. Sometimes the actual risky behavior is buried in a background job, a permission check, a billing edge case, or some third-party integration nobody wants to touch.

Testing is hard to dedicate time to because it is often too tempting to stop at good enough. Product pressure or even implicit pressure from leadership is enough to put testing on the backburner.

Tricentis’ 2026 Quality Transformation Report puts numbers behind this. According to the report, 60% of organizations say they regularly ship untested code into production. The top reasons are leadership pressure to move faster and having too much code to test.

AI-generated code is still code

There is a weird temptation to treat AI-generated code as a separate category.

Sometimes AI gives you a perfect one-shot. Sometimes it is horrifyingly off the mark. Even worse, sometimes it’s believable but subtly incorrect.

This is my whole thesis behind AI-augmented engineering being better than vibe coding.

A coding agent can implement a billing change without knowing the weird enterprise customer that has a custom contract. It can modify an authorization policy without understanding why a previous bug caused a support incident. It can update a controller, service object, API endpoint, or queue worker and miss the downstream behavior that is obvious only to someone who has lived in the codebase.

AI is often good at producing a reasonable first pass. It is useful for generating tests you were too lazy to write. It is useful for summarizing a diff. It is useful for brainstorming edge cases. It is useful for asking, “What did I forget?”

But AI does not automatically know what your business considers risky.

That context has to live somewhere. In a small team, it might live in the heads of a few senior engineers. In a large company, it is usually scattered across ticket history, test management tools, QA processes, tribal knowledge, production incidents, compliance requirements, and whatever comments happen to be on the PR.

That is not a great foundation for AI-augmented delivery. Once you accelerate software production by even a conservative multiple, you’ll inevitably begin breaking things at an unacceptable pace.

The useful version of AI testing starts before implementation

The most obvious version of AI for testing is “write unit tests for this function.”

I still do that. It is very useful, but it is not where the real leverage is.

The more useful workflow starts before the code exists.

Take a normal ticket:

“Add support for prorated refunds when a customer downgrades mid-cycle.”

A mediocre AI workflow says, “Implement this.”

A better workflow asks AI to help turn the request into a quality plan before anyone touches the code.

What are the business rules?

What should happen when the customer has a coupon?

What if the downgrade happens one minute before renewal?

What if the payment provider fails?

What if the account has multiple seats?

What data needs to remain auditable?

What existing tests probably need to change?

What flows should QA validate manually?

You’ve probably heard me refer to these as living specs.

That is where AI starts feeling more like an engineering assistant. It can help expand a vague ticket into the set of behaviors the team actually needs to protect.

As a developer, I care about this because most bugs are not caused by forgetting syntax. They come from incomplete understanding. The code does exactly what someone told it to do, but the ticket did not describe the weird case, or the developer did not know about an old workflow, or the reviewer missed the hidden coupling.

AI can help with that, but only when it is part of the actual delivery workflow instead of a side chat window where context goes to die.

AI Workspace offers a useful platform for this

Tricentis, the company behind Tosca, has introduced “AI Workspace”.

AI Workspace is a purpose-built tool built around the practical idea that if AI agents are going to participate in quality engineering, companies need a controlled place to run them.

The product is positioned as a control plane for agentic quality engineering. In plain English, that means it gives teams a place to design, deploy, govern, and monitor AI agents that work across testing and quality workflows.

That phrasing sounds enterprise-y, but the underlying problem is real.

Once AI enters the SDLC, you do not want ten disconnected agents all doing their own thing. One agent generating tests. Another choosing what to run. Another summarizing failures. Another commenting on PRs. Another making release recommendations. Nobody knows what ran, why it ran, who approved it, or whether it followed the process the team agreed on.

AI Workspace tries to make this manageable by centralizing agent management, workflow orchestration, human review gates, visibility into AI decisions, and auditability. The goal is not “let the robot ship to production.” The goal is to let AI do useful quality work inside boundaries the team can see and control.

That is the part I find compelling.

I have no interest in an AI tool that silently decides a release is safe. I do want AI to help me analyze the change, find the risky areas, recommend the right validation steps, generate missing coverage, run the relevant workflows, and bring a human in when the decision actually requires judgment.

Solving AI-augmented testing at enterprise scale is a challenge

For an individual engineer, AI-assisted testing can be pretty lightweight. Ask your coding tool for edge cases. Generate a few tests. Have it explain a failure. Ask it to review your diff for missing coverage.

That is useful, and many developers should be doing more of it.

The enterprise version is different.

Large teams have multiple tools, release processes, compliance rules, test environments, packaged applications, custom applications, and different groups with different definitions of quality. Developers might care about maintainability and correctness. QA might care about coverage and release readiness. Security cares about risk. Product cares about customer behavior. Leadership cares about speed and predictability.

A product like AI Workspace makes the most sense in that environment. It gives the organization one place to coordinate AI assistance for quality work, enforce approval gates, monitor what agents are doing, and preserve an audit trail. That is less exciting than a coding demo, but it is the kind of thing enterprises need before AI becomes part of normal delivery.

How I would actually use AI for testing

If I were rolling this out on a team, I would start with a few specific workflows rather than trying to “AI-enable QA” as a broad initiative.

First, I would use AI to turn tickets into test plans. Every meaningful ticket should produce a short list of expected behaviors, edge cases, affected areas, and open

Try AI Workspace

questions. Many teams do this already as part of a work refinement process.

Second, I would use AI during PR review to summarize risk.

Third, I would use AI during code review to catch mistakes.

Fourth, I would use AI to triage failures. When CI fails, I want help separating likely flakes from real regressions, grouping related failures, and pointing to the probable root cause.

You could do all of this in isolation, but these workflows need governance. The team should know which agent did what, what information it used, what it decided, and when a human approved or overrode it.

AI Workspace can help with that!

Why an orchestrator?

Because Fable is EXPENSIVE. If you have Fable do planning and orchestration, it can delegate implementation to cheaper models.

I’ll walk you through this concept, then show you how I used it to add a pretty significant feature to a Next.js web app.

Why Fable requires special strategy on our part

Fable is an incredibly capable model, but it’s too expensive for practical daily driving.

We’re seeing this pattern emerge where frontier labs are releasing parallel models of varying size. Fable is Anthropic’s most useful model, but it’s also it’s slowest and most expensive.

But smaller models (even Sonnet 5!) are useful to the point that you can use them for a huge percentage of software engineering.

Anthropic themselves is pushing the orchestrator pattern:

In fact, they shared that this pattern gives remarkable cost savings at minimal performance cost:

The Fable 5 orchestrator achieves 96% of Fable 5 performance at 46% of the price.

The change we’re making with Fable

I recently built a landing page for an info product using Claude Code, but the site only had a waitlist signup.

The AI-Augmented Intelligence report is a monthly report for software engineering leaders to keep them up to date on AI.

AI is moving quickly, and keeping up to date with trends, risks, and workflows can be a full-time job. If you resonated with that, I think you’d love the product.

Try Reports

I didn’t want to overengineer a product that didn’t have demand, so I just shipped it with a waitlist signup.

Well, the waitlist is overflowing. I’m only opening 25 spots and there were multiples of that that signed up for access.

So it’s time to actually open the product for signup!

The core of Reports is information. We need to let users sign up, pay, view an index of past reports, and get emails for new reports.

For today’s article, we’re going to add signup and billing.

How to use Fable as an orchestrator to make this change

Read more

Anthropic released Claude Fable 5 on June 9. Three days later, the United States government placed the model under export controls, forcing Anthropic to disable it for everyone because the company had no practical way to verify each user’s nationality in real time.

The restrictions were lifted on June 30, and Fable returned globally on July 1. Anthropic initially included the model in paid Claude subscriptions for only a few days, after which subscribers would need to purchase usage credits at API rates. That temporary access has since been extended twice, most recently through July 19.

It has been a strange launch, even by frontier-model standards.

The regulatory story here has attracted most of the attention, but the product story may be more relevant to the average software engineer. During the few weeks that Fable was disappearing and reappearing, OpenAI released the GPT-5.6 family and Cursor released Grok 4.5 with SpaceXAI. Both releases made the market for expensive frontier intelligence considerably more competitive.

Once another model offers comparable performance inside a normal subscription, charging every Claude subscriber metered API rates for Fable becomes difficult to defend.

Subscribe now

The frontier is now crowded

Results of independent evaluations from Artificial Analysis currently place the major new models surprisingly close together.

The results show Fable holding a narrow general-intelligence lead, GPT-5.6 taking the lead in coding agents, and Grok delivering near-frontier coding performance at a much lower cost.

The answer to the model choice question now depends heavily on what you are building, how many times you need to run it, and how easily you can verify the result.

Fable 5 is an exceptional model when you can actually use it

Fable 5 is Anthropic’s most capable generally available model. It uses the same underlying model as the more restricted Mythos 5, with additional safeguards that sometimes route sensitive requests to Opus 4.8. (I think this happens way too often tbh)

Anthropic built Fable around long-running autonomous work. It has a one-million-token context window, supports outputs of up to 128,000 tokens, and uses adaptive reasoning rather than requiring users to select a fixed thinking budget. In one early test, Stripe reportedly used it to perform a migration across a 50-million-line Ruby codebase in a day, work that Stripe estimated would have occupied an engineering team for more than two months.

The independent results support Anthropic’s positioning. Fable scores 60 on the Artificial Analysis Intelligence Index, the highest current score, and it leads the AA-Briefcase knowledge-work benchmark. Its advantage there is substantial: a 56 percent rubric score compared with 42 percent for GPT-5.6 Sol, plus an Analytical Quality Elo of 1,764 compared with Sol’s 1,592.

For an engineer, Fable is most interesting when the work is large, ambiguous, and expensive to get wrong. Think architecture investigations, unfamiliar codebases, difficult migrations, incident analysis, or changes that require the agent to maintain a plan across a long session.

The downside is cost. Fable is priced at $10 per million input tokens and $50 per million output tokens. Artificial Analysis also measured a time to first token of roughly 117 seconds at maximum reasoning effort. This is a model for tasks where answer quality is worth waiting and paying for, rather than something I would casually put behind every agent loop.

Fable’s included access on Claude subscriptions currently runs through July 19. After that, Anthropic still says the model will move to usage credits, but I suspect the company extends the promotion again. Still, this a prudent time to run your own difficult tasks through it and figure out where the quality difference is real.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

GPT-5.6 is just as good but at lower cost

OpenAI did more than release a new flagship. GPT-5.6 is a family of three models:

• Sol is the highest-capability model.

• Terra is positioned as the balanced option.

• Luna is the cheapest and fastest model.

All three are available in the API, ChatGPT Work, and Codex. Paid ChatGPT and Codex plans include access to the family, while free users receive access to Terra in supported products. API prices range from $5 input and $30 output for Sol down to $1 input and $6 output for Luna.

Sol’s raw intelligence score is barely behind Fable, but it costs approximately one-third as much per task in the Artificial Analysis evaluation. It also takes the lead on the Coding Agent Index with a score of 80, ahead of Fable’s 77.2. Artificial Analysis found that Sol led all three coding evaluations in the index while costing around 40 percent less per task than Fable in Claude Code.

OpenAI also reported a large advantage on longer professional workflows. GPT-5.6 Sol scored 52.7 percent on Agents’ Last Exam compared with 40.5 percent for Fable. On the independent Intelligence Index, however, Fable still held the one-point lead. The reasonable conclusion is that both models are frontier-class, with Sol currently offering the stronger overall price-to-performance ratio.

Luna may be the most practically important release in the family. It scores 51 on the Intelligence Index and 75 on the Coding Agent Index while costing about 80 percent less per evaluated task than Sol. For workflows that launch several agents, retry failed work, or process large queues, those economics can be more valuable than squeezing out the final few percentage points of performance.

At every tested Terra reasoning level, either Sol or Luna provided more intelligence for the same cost, or similar intelligence for less.

So there’s a free tip! In the GPT-5.6 family, avoid Terra!

Grok 4.5 is surprisingly good

Grok 4.5 was jointly trained by Cursor and SpaceXAI. Cursor says its training included trillions of tokens from interactions with codebases, tools, and developer agents, along with broader data from STEM, research, and professional knowledge work.

This is the first model from the partnership intended for more than software engineering. It was trained through reinforcement learning on realistic environments that required the model to investigate problems, use tools, recover from mistakes, and verify its work.

Its independent results are impressive. Grok 4.5 improved 16 points over Grok 4.3 on the Artificial Analysis Intelligence Index, reaching 54. In Cursor’s Grok Build harness, it scored 76 on the Coding Agent Index, effectively matching GPT-5.5 and landing just behind Fable.

Grok does not beat Fable or GPT-5.6 Sol in overall intelligence. It does crush them on cost.

Artificial Analysis measured a cost of $2.49 per coding-agent task for Grok 4.5, compared with $11.80 for Fable in Claude Code and $5.07 for GPT-5.5 in Codex. Grok used about 1.9 million tokens across the Coding Agent Index, compared with 7.2 million for Fable and 6.2 million for GPT-5.5. Its API price is $2 per million input tokens and $6 per million output tokens.

Those numbers make Grok attractive for code-generation loops, terminal agents, and workloads where you can run automated tests or another reliable verifier afterward.

There is an important caveat. On Artificial Analysis’s knowledge-reliability evaluation, Grok’s accuracy increased from 35 to 52 percent, but its hallucination rate also rose from 25 to 54 percent. It knows considerably more than its predecessor, while also becoming more willing to answer incorrectly. Grok looks strongest in environments where its work receives direct feedback from tests, compilers, databases, or other deterministic systems.

Google is still playing a different game

Gemini 3.5 Flash does not currently lead the broad intelligence rankings, but it remains a serious frontier option because Google has optimized around a different set of constraints.

It accepts text, images, audio, and video, supports a one-million-token context window, and is designed for high-throughput agentic work. Google reports scores of 76.2 percent on Terminal-Bench 2.1, 83.6 percent on MCP Atlas, and 83.6 percent on MMMU-Pro. Artificial Analysis currently measures output speeds around 162 tokens per second.

For agents that need to inspect video, process audio, understand large visual documents, or return results with low latency, Gemini can be the better engineering choice even when another model has a higher composite intelligence score.

This is another reason permanent model rankings have become less useful. Google is competing on speed and multimodality. Anthropic is competing on sustained analytical quality. OpenAI is competing aggressively on coding performance and cost. Grok is competing on agent economics.

How I choose models right now

I would avoid standardizing your entire workflow or an entire engineering organization around one model.

Route work according to what you observe:

• Use Fable 5 for your hardest open-ended investigations and long-running work where analytical quality is the primary concern.

• Use GPT-5.6 Sol for great coding agents and professional workflows where you want frontier performance without Fable’s full cost.

• Test GPT-5.6 Luna as the default for high-volume agents, background tasks, and parallel subagents.

• Use Grok 4.5 when cost efficiency is important and the output can be verified automatically.

• Keep Claude Sonnet 5 in consideration as Anthropic’s practical daily model. It is included across Claude plans and launches at $2 per million input tokens and $10 per million output tokens through August 31.

Want more practical tips like these to help you stay on top of a quickly-changing AI toolset? I’d love to have you join us for the paid membership, where you’ll unlock our full archive of deeply technical guides.

Subscribe now

Competition is doing its job

Anthropic released an extraordinary model and planned to charge subscribers separately for meaningful usage. OpenAI then shipped a model that is nearly tied with Fable on independent intelligence evaluations, beats it on a major coding-agent index, costs much less, and is included inside its existing products. Grok arrived with near-frontier coding performance at a fraction of Fable’s cost.

So who wins? Not investors :)

Maybe Anthropic would have made the same decision without those releases. From a customer’s perspective, the cause is less important than the result.

The leading labs are now close enough that each can expose a weakness in another company’s offering. A model can have the highest intelligence score and still lose on coding, latency, multimodality, access, or price. Developers have credible alternatives, and switching costs remain low enough to keep the pressure on.

That pressure is giving us more capable models, cheaper inference, better subscription access, and several genuinely good choices instead of one default provider.

The frontier has rarely been more confusing. It has also rarely been this favorable to the people actually using the models.

Leave a comment

I don’t think that’s true, but I do think understanding loops and how to use them in Claude Code has the potential to make you more productive. Initially, they may sound intimidating because people are hyping up a relatively straightforward automation concept.

Making loops is essentially replacing yourself as the person who prompts the agent. When you make a loop, you make a system that prompts the agent.

In today’s edition, I’ll show you:

• What a loop is

• What makes up a loop

• How to make a loop in Claude Code (with example prompts)

• How loops can make you more productive

What is a loop?

Even the OpenClaw guy is pushing loops now

This post is actually pretty explanatory for loops.

Loops prompt themselves to write code so that agents can do long tasks in parallel without much involvement from you.

One important concept that makes loops powerful is the idea that an agent can have its own agents. An orchestrator agent can perform the loop and spin off subagents to actually accomplish a task.

What makes up a loop?

Loops are essentially recursive goals where you define a purpose and the agent iterates until it meets that purpose/goal.

Sound familiar? Maybe you read the newsletter’s posts on /goal:

In fact, Anthropic calls goals “goal-based loops”:

Generally speaking, a loop needs 4 things:

1. A goal (scope of what you want agents to do)

2. Context (don’t let your agents fly blind!)

Read more

Codex and Claude Code are incredible tools for creating software. Each takes advantage of state-of-the-art models to read and understand your entire codebase before making changes on your behalf.

If you’re looking to use AI to accelerate creating meaningful software, you’ll probably end up picking one of these. But choosing Codex vs Claude Code isn’t easy.

I’ll walk you through how to pick the right tool for you, but I won’t hide my opinion. Both are great, Codex is my preference, and Claude Code has a better CLI.

But don’t conflate choosing a model family with choosing a harness!

Separating the model from the harness

If you’re going to compare Codex and Claude Code, it’s really important to understand the difference between a model and a harness.

The model is the actual brains of the operation. Models have weird names, like OpenAI’s GPT series:

• GPT-5.4

• GPT-5.4-Codex

• GPT-5.5

Or Anthropic’s Claude models:

• Claude Haiku 4.6

• Claude Opus 4.8

• Claude Sonnet 4.7

The harness is the tool that sits between you and the model. ChatGPT, Claude, Claude Code, Codex, Cursor, Intent. All of these are harnesses.

Many tools, like Cursor, allow you to choose the model that the tool/harness uses under the hood.

Obviously that creates a lot of competition for model providers, so they have some incentive to want you to use tools that lock you into their models. Claude Code is Anthropic’s leading harness for developers. Codex is OpenAI’s harness for developers.

This article will mostly be about comparing the harnesses to each other, not the models. Model comparison is often done with evals, which are published with each model release in a system card.

What is Codex?

Codex is OpenAI’s flagship agentic product. Historically, its been their agentic software development product. Recently, they’ve taken steps to make it useful for general use, but if you’re here, you’re probably interested in the software engineering piece.

When someone say’s “Codex”, they most often are referring to the Codex app. There’s also a Codex CLI, but the app is a lot more popular.

OpenAI fine-tunes some of its models for programing, and appends -Codex to the model name, but don’t let that confuse you. There are Codex models, the Codex CLI, and the Codex app.

What is Claude Code?

Claude Code is the Anthropic equivalent to the above. Meaning, Claude Code is Anthropic’s flagship agentic software engineering tool.

Many of you are already familar with Claude, which generally refers to the web app that lets you interact with Claude models (Haiku, Sonnet, Opus, Fable, etc.)

Claude Code is a Command Line Interface (CLI) tool primarily meant for agent-first software development. You run Claude Code inside a programming project, instruct/prompt it on what you need to do, and it uses tools to read, understand, and make changes to your codebase.

Most people use Claude Code in its original form, the CLI/TUI. While there’s a Claude Desktop app, most people find the CLI better to use.

The opposite is actually true of Codex. More people use the Codex app than Codex-CLI, their terminal interface.

We already ran a great detailed comparison of using the Claude Code TUI for the same task as the Codex app, so check that out!

Overall, my preference is for the Codex app since it makes parallel agent orchestration more straightforward. For frontend-heavy tasks, the built-in browser is incredible.

This post is sponsored by Cosmos, the agent orchestration platform for AI-native engineering teams.

Cosmos is a shared system where agents work across triage, spec, implementation, review, testing, deployment, and feedback with the context, memory, and controls teams need. Humans steer, agents do the implementation, and the system gets better as the team uses it.

Try Cosmos

How to make your decision

There’s an insane amount of competition in this space, and that’s good. I actually have a plan with OpenAI for Codex, Anthropic for Claude Code, and another for Cursor. This is helps me stay on top of all the tools for the newsletter, but it also helps me evade rate limits!

Whichever tools and models are best changes frequently, so keeping a subscription to both Claude Code and Codex isn’t a bad idea.

Here are some rules to help you decide:

• Lots of frontend design? → I suggest Claude models → I suggest Claude Code in CLI

• Lots of long-running tasks → I suggest Codex models → I suggest the Codex app

• Really prefer a CLI? → I suggest Claude Code

• Really prefer an app? → I suggest Codex

Do you have a strong preference? I’d love to hear about it in a comment or reply to this email.

Subscribe now

Software development is moving out of the IDE. Well, it has moved out of the IDE.

Intent, Codex, Claude Code - all of these are agent interfaces that abstract code editing away.

For decades, the IDE was where software happened. You read code there. You wrote code there. You debugged code there. You ran tests there. You sat in front of the editor, typed the implementation, and used the rest of the toolchain to support that work.

Then, AI started working its way into our workflows.

First, it was autocomplete. Then chat in the sidebar. Then, inline edits. Then, agents that could inspect files, modify code, run commands, and loop until they got something working.

That was the first phase of AI-assisted development: make the individual engineer faster inside the environment they already use.

The next phase is different.

Once agents are doing meaningful work, the bottleneck stops being “can the tool write code?” and becomes “can I trust this work enough to ship it?”

But teams have a harder problem.

An individual can build a personal workflow. A team needs an operating model.

That is where Cosmos provides value.

The problem is no longer code generation

The first time you watch an agent make a non-trivial change, it feels like the future.

The twentieth time, you start noticing the mess. When you multiply this across entire teams, the mess gets pretty disruptive.

One engineer on your team might have a carefully tuned prompt for backend migrations. Another has a Claude Code skill that works great for tests. Someone else has a local script that spins up three agents in separate worktrees for adversarial reviews.

Agentic engineering is a paradigm shift, and it requires new tools.

The name Cosmos is hinting at something. Cosmos is Greek for order, specifically the ordered universe. It stands in contrast to chaos, which is the problem it seeks to solve.

AI-native teams have team-level systems

Most AI coding tools are still designed around the individual developer, which makes sense. Individual adoption is where the market started. A single engineer installs Cursor, Claude Code, Codex, Intent, or another coding agent and immediately gets leverage.

But individual leverage does not automatically become organizational leverage.

In fact, it can make some organizational problems worse.

If agents make it easy to generate code, PR volume goes up. If PR volume goes up, review becomes the bottleneck. If review becomes the bottleneck, teams either slow down or start rubber-stamping changes. If they rubber-stamp changes, they ship bugs, regressions, and architectural drift faster than before.

The same pattern shows up in incident management.

If agents help teams ship more code, production changes faster. If production changes faster, on-call has more context to reconstruct. The on-call engineer now has to correlate deploys, logs, metrics, Slack threads, dashboards, ownership, past incidents, and recent PRs under pressure.

Human attention is necessary, but a bottleneck. We shouldn’t be seeking to pull humans out of the loop, but that doesn’t mean we should hide from tools that make that human’s job easier.

But at this point, these tools need to be built for whole teams.

Intent is single-player, Cosmos is multiplayer

The distinction between Intent and Cosmos is helpful.

Intent is about the individual developer’s workflow after the IDE stops being the center of gravity.

You define a task. Agents coordinate inside a workspace. A spec gives the work shape. The tool helps you answer the key question: “Can I trust that the agents did the thing I asked them to do?”

That is a single-player problem.

Cosmos is aimed at the team version of the problem.

How does an organization make sure the best way to do something is not locked inside one engineer’s head?

How does a team turn a successful agent workflow into a reusable pattern?

How do you make sure code review, incident response, testing, and remediation all improve over time instead of starting from scratch every time a new agent session begins?

How do you keep humans in the loop for judgment without forcing them to inspect every line of agent-written code?

That is a multiplayer problem.

Cosmos is a bet that AI-native engineering teams need a shared system of record for agentic work. Not just prompts. Not just agents. Not just a dashboard. A coordination layer.

Experts are specialized agents in Cosmos

Experts are specialized agents you can define in markdown and reuse across your entire team.

Here’s a sneak peek of how Augment is using experts internally to do code review.

Here’s another example of how they’re using experts for automated incident response.

Agents gather evidence, summarize, propose, and remember. Humans decide, approve, and handle the parts where judgment matters.

You’ll notice in this flow that these “experts” don’t actually pull humans out of the loop completely. The human still makes the judgment call, but the human is no longer starting from zero.

Augment is reporting that these agent workflow triages 81% of incidents now! Agents aren’t new to Augment, so it should be surprising that the number before introducing Cosmos was 0.4%.

That’s how big a difference this tool makes for teams.

Want to set up your own experts? Cosmos advisor helps you set them up with natural language so you don’t have to learn a new tool from scratch. If you want a jumpstart, you can use the library of experts that ships with Cosmos.

The model router is built for pro teams

One underrated part of Cosmos is Prism, the model router. Prism handles model selection so you don't have to be an expert on model capabilities to get the most for your tokens.

Cosmos is intentionally model-agnostic. You can choose your own model, or get the model router to do it for you.

Historically, I haven’t really trusted model routers, under suspicion that they route you to the cheapest model.

This isn’t the case with Prism, because the tool is complexity-aware.

For each input, a small (read: inexpensive) planner model reads the request and decides which of the underlying models should handle it. From your perspective, Prism behaves like any other model in the picker. You pick Prism, then Prism picks the model.

Choosing a model based on complexity is actually the easier part. The harder part is caching. Modern coding agents lean heavily on prompt caching to reduce cost and latency. Naively switching models mid-session throws the savings from the cache out the door. A naive router that re-routes every turn would burn most of its potential savings on cache misses, which could make the session more expensive than just staying on one model.

Prism’s only switches models when the expected win from a different model exceeds the cost of the cache eviction, which makes it an effective means of staying in your token budget without getting sub-optimal results.

Cosmos meets you where your work already happens

Cosmos works on your local machine, in containers, in codespaces, in Augment’s managed cloud, or on your own cloud infrastructure.

That makes it easy to run Cosmos, but you also don’t have to move all your work inside of Cosmos. It has robust integrations to bring it into the work you already have going on. It integrates into Slack, Linear, a CLI, web, and mobile apps.

It also has MCP support and webhooks so building your own custom integrations is easy.

If you’re an engineering team looking to actually multiply your impact with AI, give Cosmos a try.

Try Cosmos

That app, Simple Meds, still gets used every day!

But it’s ugly! It works exactly as expected, but has no design frills whatsoever.

So today, I’m going to show you how I used Claude Code to make it much more delightful to use. Here’s what we’re turning it into:

AI tools are so much better than a year ago

When I made this app, I used Cursor’s chat to write every single line - I showed you how in what ended up being one of my most popular posts ever:

SO MUCH has changed since then. First, Cursor is no longer the leading AI tool for developers. It’s a great tool, but it’s been surpassed a bit by Claude Code and Codex.

Why? Agents.

Agents are the primary mechanism to use AI for software engineering now. Cursor isn’t oblivious to this - they completely redesigned Cursor around agents. So if you’re using Cursor today, you’re not behind. I still keep a subscription and use it from time to time, but it’s not my daily driver anymore.

Models have also gotten so much better in the last year. I wrote this app with GPT-4o. We’ll do our redesign with Claude Opus 4.7, which isn’t even the latest model!

I’ll also use newer image generation models to get a better logo that matches our new design.

Prompting Claude Code for design

Read more

Here’s everything you need to get productive with Claude Code FAST.

Installing Claude Code

As you can probably gather from the screenshot above, installing Claude code is simple. Open your terminal and install it with NPM:

npm install -g @anthropic-ai/claude-code

Make sure you get a successful install.

Advanced Claude Code usage

Comparing Claude Code to other tools

Building apps with Claude Code

If AI is such an incredible tool, why aren’t we seeing an incredible explosion of useful software?

The answer isn’t too complicated. AI is just a force multiplier.

If you’re a great developer and use AI effectively, you’ll get increased productivity. If you have poor technical skills and lean on AI, you’ll ship more, but the outcomes will not be good. You ship slop, and lots of it, so much in fact, that you would rightfully be called an AI slop cannon.

What is an AI slop cannon

An AI slop cannon is a very high-output software engineer that doesn’t emphasize quality enough.

The weird part here is that in the short term, slop cannons seem productive. But code that is easy to produce can be hard to maintain and extend, so the productivity gains from the AI tool are eaten by technical debt.

If you’ve been a software engineer long enough, you’ve undoubtedly been bitten by a complexity dragon once or twice. Great software developers write code that is easy to understand and maintain, in addition to accomplishing the task. If you’re just feeding Claude Code Jira tickets to complete, you’re probably going to ship some AI slop.

So how do you avoid shipping slop? I’ll show you 5 guiding principles.

Today’s newsletter is generously sponsored by Friday, a powerful agent harness that connects to the software you already use.

Friday helps you get more done with AI agents, without having to glue tools together. You can bring your own API key for your preferred models, bring your existing skills, and connect to the tools you need with MCPs.

One of my favorite things in Friday is the incredible support for scheduled jobs. Friday lets you describe recurring agentic workflows in plaintext but gives you the option to edit and extend them as code.

Check it out today!

Try Friday

How to become a turbo brain instead of an AI slop cannon

If you’re already using AI, then your focus should be on becoming a great software engineer. If you’re a great software engineer, then put some time into becoming effective at using AI tools for your work.

One of the best things you can do for your career and output is to develop great engineering skills, isolated from AI.

1. Developing great engineering skills without AI

This section is primarily about developing good judgment. Unfortunately, this takes time. There are things you can do to accelerate developing the technical skill and judgment of an effective senior+ contributor, but you’ll also have to be patient.

The first and most obvious thing to focus on is coding skill. Some folks are pushing the idea that you don’t need to know your programming syntax when AI is an effective means of producing code. I think this is a bit short-sighted.

It’s important that you become competent in at least 1 programming language (ideally 2) so that you can judge AI-produced code. I’ve been writing Ruby for years, and it gives me a keen eye for reading Ruby code that is overly complex or hard to change.

Speaking of complexity, it’s important to learn how to avoid unnecessary complexity. Learning this is increasingly important the more you use AI, and I recommend you read “A Philosophy of Software Design” by John Ousterhout to speedrun this.

If you’re shipping enough code, you’ll eventually need to develop an eye for system design. AI lacks in this area, mostly because coding agents often focus on an individual app instead of a whole system. Getting really good at system design is a huge life hack in the era of coding agents. I recommend Alex Xu’s system design book for this.

2. Understanding all the code you write

Good software engineering requires that you understand the code you write. That extends to the tools you use. In the AI era, that means you can’t ship code agents write without wrapping your head around it.

Skipping this part is generally what people call vibe coding. Vibe coding has it’s place, but it’s not software engineering.

3. Owning all the code you ship

If you ever find yourself saying “Claude wrote a PR that did x” or “Codex fixed this bug”, STOP.

I call this agentic passive voice.

When you use Claude Code or another AI tool to write code, even with an agent, you are simply using a tool. It’s an incredibly effective tool, but it’s still a tool.

It’s a bad look to abdicate all your responsibility to an LLM. You have a real human brain capable of unique insight, and it’s your responsibility to use it to add value to your work. Extend your expertise with AI. Don’t replace it.

4. Using AI effectively

Using AI effectively is an important part of becoming more useful in the AI era. It’s the whole thesis for this newsletter.

This is where learning to use the tools we have comes into play. Plan mode, goals, context engineering, skills, and more are all important concepts to wrap your head around if you want to get maximum value out of your tools.

If you’re not already, consider becoming a member of the newsletter to multiply your efforts here. Members get access to detailed technical guides in the Member Vault, which are the fastest way to level up your AI-assisted programming techniques.

Subscribe now

5. Seeking mentorship

The last piece of advice I’ll leave you with is to seek mentorship for all of the above. Find folks that are incredible at system design and learn from them. Identify the people in your org that are using AI tools effectively and ask to pair program with them.

The fastest way to level up is often 1:1 conversations with folks just a few steps ahead of you at a particular thing, so don’t miss out!

I’m tinkering with a new product idea, and I wanted to show you exactly how I used Claude Code to build the landing page for the product waitlist. Here’s a sneak peek of what we’ll be building in today’s deep dive.

Building small projects like this these days is so much easier than even a few years ago. You can design, build, ship, and iterate faster than ever before. Without AI, I probably wouldn’t have time to test small ideas like this.

With AI, I can experiment and tinker while actually getting real feedback from users and customers. The product will be a thoughtful, human-written report, but there’s no reason to not use AI to help me build a great landing page.

Subscribe now

Why use Claude Code over no-code?

If you’re just building a landing page, it isn’t always worth the hassle to code up a custom website. Even though AI has made that work much easier/faster/cheaper, there’s some phantom costs to running your own website:

• Security maintence

• Framework and language upgrades

• Platform costs

• Complexity of change

So plenty of no-code tools like Wix, Webflow, and Carrd exist to make shipping landing pages easier.

If all you need is a landing page, then these are good options - maybe even better than what we’re about to do.

But I want more than a landing page.

I want full control over the site.

What we build today will just let users add their email to a waitlist and display some copy, but it probably won’t stay that way.

If the product gets enough interest, I’d use this initial site build out as the actual product experience too. What starts as a landing page would eventually turn into the platform people access the info product on.

Doing a custom build also gives me the ability to have full control over A/B testing, email capture experiments, and so on.

Writing the copy first

Since this is a landing page, I first wanted to nail the copy. The product idea is for a high-ticket monthly analysis report for engineering leaders, so I spent my first few prompts going back and forth in ChatGPT to refine the idea.

Once the idea was well-described and defined, here was my initial prompt:

Interview me and ask me all the questions you need to know in order to write an incredible copywriting page in the style of Sam Parr

“Interview me” prompts are underrated. The model returned FOURTY questions about my idea to further refine it, then it gave me a long copywritten sales page. This of course got a careful eye and plenty of tweaks from me, but it was an incredible time-saver.

I used this sales copy for the next piece, actually building the page with Claude Code.

Getting from copy to plan in Claude Code

Read more

I’m not sure how to feel about this. I’m usually a big advocate of different tools for different things. I don’t like everything apps because they eventually become nothing apps.

But OpenAI Codex might be challenging that assumption with their recent releases and upcoming roadmap. They’ve built integrations for Gmail, Slack, Google Drive, Linear, even Stripe! The open MCP standard has given you a lot of options to work with Codex.

In today’s newsletter, I’ll show you:

• What’s changing in Codex

• Details on the merge with ChatGPT

• Why I think this is a mistake

• Some cool non-code things you can do with Codex now

Today’s newsletter is generously sponsored by Friday, an agent harness platform for building AI workflows that actually connects to the software you already use.

Friday gives you a way to turn plain-English instructions into reliable agentic workflows, complete with agents, MCP servers, memory, skills, and scheduled jobs. Instead of stitching together custom scripts or one-off automations, you can describe what you want Friday to do, connect the tools it needs, and let it run in the background.

The scheduled jobs are especially useful. You can ask Friday to generate a report, check a system, summarize activity, or email you an update every Monday at 9am, then inspect and extend the workflow as code when you want more control.

It is a practical way to make AI agents useful beyond the chat window.

Try Friday

What’s changing in Codex

Codex took OpenAI from just answering questions (ChatGPT) to actually doing meaningful work. It followed quickly from the success of Claude Code, and moved from web to CLI and then again to app.

In case you missed it, here are some Codex guides to get you up to speed:

From these articles, you can see pretty clearly that Codex is a tool for developers. It’s a direct competitor to Claude Code, but soon it will take on Claude Cowork more directly.

Is Codex merging with ChatGPT?

I don’t know how this isn’t bigger news. At OpenAI’s recent Intelligence at Work event, their product leadership shared that they’re “very excited to share that in the next few weeks we are going to put codex into ChatGPT".

For a developer, the unit of work is a commit or a PR. For other white-collar workers, the unit of work is something else! Presentations, documents, excel tables, emails, etc. OpenAI wants to move beyond just code.

ChatGPT is where Open AI models help you do work.

Codex is where Open AI models work for you. It’s agentic, and they’re moving past just software engineering.

Subscribe now

So why bring it into ChatGPT? The everything app, that’s why. Claude did this recently with Claude Cowork. Now’s there’s a Claude Desktop app that contains a GUI for Claude (chats), Claude Code (software engineering), and Claude Cowork (other office-type work).

I expect ChatGPT to look a lot like this soon. They’ve neglected their desktop app to crush it on Codex, and it seems like they’re going to roll them together soon.

Becoming an everything app is a mistake

They recently highlighted that knowledge workers are adopting Codex 3x faster than developers, so it’s no surprise that they want to tap that market. Developers love Codex, so accountants should love Codex too, right?

I don’t think so.

I think Codex is so incredible because it’s for one thing. Taking focus away feels like a great way to lose the lead in the race for great developer tooling. But time will tell. Fortunately there’s a lot of choice in this market!

Some cool things you can do in Codex now

Now that I’ve complained about Codex becoming a tool for everyone, let me show you some genuinely cool use-cases that aren’t software engineering 😎

To use most of these, you’ll need to go to the “plugins” section of the Codex app.

Google calendar in Codex

Once you install the calendar plugin, you’ll get a prompt to sign in to Google calendar and grant permissions.

Once that’s setup, you can trigger calendar with @Google Calendar

Here’s an example of me asking Codex if my calendar is free on Saturday and then adding an event to it.

Automations in Codex

The next cool new(ish) Codex thing is automatons, or recurring tasks.

I don’t think Codex does this well, which is a symptom of being an everything app. See today’s sponsor, Friday, for a better recurring task experience! Regardless, here’s an example of a simple but useful automation I just set up.

Codex computer use

Computer use is the “Claude Cowork” feature. It let’s Codex actually use other apps on your computer directly, which is the fastest way to get it to be generally useful beyond just writing code.

Here’s a prompt OpenAI has in one of their docs:

@Computer

- Play some music to help me focus.
- Help me add my interview notes from Notes to Ashby.
- Look through my Messages app for the trip ideas Brooke sent me this week, add the best options to a new note called "Yosemite ideas", and draft a reply back to her.

It’s a killer feature if you’re willing to give it the access it needs in order to be useful. I haven’t experimented with it enough to give a full tutorial here, but perhaps in another newsletter!

Subscribe now

If you’re using an agentic tool, every little optimization to your workflow pays dividends. For CLI tools like Claude Code, it can be a little hard to get all the info you might need in one screen.

Fortuantely, Claude Code lets you configure the status bar to contain info that’s important to you, specifically.

Some good options for the Claude Code status bar

What kind of information might you want to display in the status line? Here are some popular ideas

• Context window usage

• Current session cost (this is becoming increasingly important)

• Git branch

• Current model

• Effort level

• Rate limit usage %

There’s more options shown in the Claude Code documentation, but these are the most common. They also happen to be the ones that I use!

I’ll show you how to use Claude to configure the status line in natural language with a prompt you can copy and paste.

How to customize the Claude Code status line with natural language

Read more

Goals help you go from back and forth prompts to repeatable outcomes.

If you want a refresher on goals, check out this earlier post on Codex goals.

How are goals different than prompts?

One highlight from the post explaining goals in detail is how they differ from prompts.

Prompts can be a tedious chat-based workflow. Sometimes when you’re working on a big project, you’ll find yourself snapping at your agent, telling it to “keep going”, “finish the implementation”, or “run all the tests now”.

If you’re doing something that involves evaulating output from the previous response, goals can help you iterate faster by pulling yourself out of the loop.

This lets agentic software tools like Codex and Claude Code operate more independently, which helps you get more out of your token spend.

Working from a PRD

Goals require specific outcome definition, which is a great reason to reach for a PRD (Product Requirements Document).

In our post explaining how to use AI to plan a new project, we explained how to use a chat-based tool like ChatGPT to get to a PRD.

You don’t have to use AI to get a PRD, or even have a PRD at all, but this is a great way to get moving on your project faster (and with more confidence that it will actually be okay).

Once you have a PRD or a document describing the detailed requirements of your project, you can get started using /goal in Claude Code or Codex to implement it.

I’ll walk you through it now, showing how I use this exact process to make a tool that helps me distribute my newsletter with AI.

Implementing a PRD with /goal

You can use goals in Claude Code or Codex, including the Codex CLI. I’ve been daily-driving the Codex app most of the time, so that’s what I’ll use for this walkthrough.

First, I’ll put my PRD in codex and ask it to make a PLAN.md from it. Then, I’ll use /goal to have it autonomously implement that plan. Take a look at the first piece:

Read more