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 connect 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

Goals are a built-in way to move your conversation away from a sequence of isolated prompts and into a work loop that iterates until it hits a measured outcome.

You can use /goal in the Codex app or in the CLI, so you can just stick to your preference.

If this is the first you’re hearing of goals in Codex, you’re probably a bit curious how they differ from ordinary prompts. We’ll start by answering that question, then show you the helpful goal commands, then we’ll wrap up with a real example.

Ready to dig in?

What is the difference between a prompt and Codex goal?

Prompts work for this workflow

ask -> work -> result -> wait

Goals work like this

work -> self-eval -> loop if not complete

In short, Goals are outcome-driven.

If Codex can learn something from what it just done, a goal can help it keep going without you.

But do use goals, you need a verification surface (like tests or browser use) and a measurable outcome.

When to use a goal instead of a prompt

Have you ever been using an agent in Codex or some other tool and found yourself typing the same thing over and over again as responses to agent completions?

Nice, do the next test now.

Or

Awesome, clean up the next controller to use this new method in the parent class

Or

Don’t just show me how to do it, keep going and finish it

If you’re ever in a situation like this, the /goal command is probably going to be very helpful.

Today’s newsletter is generously sponsored by Friday, a powerful agent harness that connect 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

Some helpful Codex goal commands

The /goal command is really simple, and there’s a few variations that can help you in both the Codex app and CLI.

How to set a goal in Codex

Setting a goal in codex is simple with the slash command:

/goal Your goal goes here

How to view the current Codex goal

If you have a long-running goal, you might need reminded of what you initially asked for:

/goal

How to pause the current Goal in Codex

If you want to pause a goal without losing progress or context, you can do so:

/goal pause 

How to resume a goal

Resuming a paused goal is easy with:

/goal resume

How to delete a goal

Deleting a goal will remove the context and allow you to set a new one. Just run:

/goal clear

How to write a Codex goal

The OpenAI docs are a great place to go for instructions on writing goals, but I’ll give you the most important stuff here.

Goals need outcomes. This is how Codex knows when it’s done.

Goals need a way to verify the outcome. Tests, benchmarks, browser use, etc.

Goals should have constraints. You’ll get better results if you tell Codex what not to change.

Goals should know when to report as blocked. If you tell Codex what would indicate that it’s blocked, you’ll save yourself from wasting tokens.

Template for a good goal

Here’s a template for a good goal:

/goal <desired end state> verified by <specific evidence> while preserving <constraints>. Use <allowed inputs, tools, or boundaries>. Between iterations, <how Codex should choose the next best action>. If blocked or no valid paths remain, <what Codex should report and what would unlock progress>.

You could simplify this as:

/goal Complete this thing without stopping until you’ve passed this success criteria

Here’s a goal I used to add some test coverage to a project that doesn’t have any tests.

Goals and token usage warnings

One word of warning for you is to pay attention to your token usage while using goals. The /goal command lets Codex iterate over and over, which will consume truly absurd amounts of tokens. On a sufficiently large project, you’ll probably start hitting your five hour limits long before five hours (on the Plus plan).

Fortunately your limits will reset, so you won’t be stuck for the month, but it’s something to keep in mind.

This is one reason I keep a Codex, Claude Code, and Cursor subscription all active at the same time. Having all three is cheaper than any top-tier plan, gets me ton more usage, and lets me daily-drive whatever tool as the best edge at a given time.

Goals actually work in Codex too, and I suspect Cursor will follow-suit soon.

Getting really good at using agents

I firmly believe the future of software development is agent-first. That doesn’t mean I think software development is going away as a profession. But it is changing. It’s getting harder and harder to deny that it’s changing.

We’ve gone from fancy-autocomplete to agents, and the /goal feature in Codex is making agents even more autonomous, while increasing their economic utility.

If you want to learn how to use agents to ship more software, earn more money, or even get promoted, you’re in the right place. This substack exists to help you use AI tools like Codex better, so I’m happy to have you here.

Subscribe now

Until now, I’ve had the newsletter’s sponsorship details in a Notion page. It describes some stats on The AI-Augmented Engineer for companies who may be interested in sponsoring the newsletter.

Here’s what I used the Claude Code desktop app to make:

Frankly, I’m bad at frontend development, so AI is doing more than making this project go faster. It’s making it possible at all. The reason it’s in a Notion page now is because that was the fastest way for me to get the info publicly accessible.

Before we dig into the Claude desktop app, it’s important to draw a line between vibe coding and AI-augmented engineering.

Separating vibe coding from AI-augmented engineering

It’s really important to draw a distinction in your mind between vibe coding and AI-augmented engineering.

I’ve written at length about this, but it can be summarized as this:

• Vibe coding has a focus on shipping, implementation details aren’t checked very thoroughly

• AI-augmented engineering has a focus on amplifying the output of incredible software engineers

If you’re employed full-time as a software engineer, you should try to avoid vibe coding at work (for the most part). You likely have a lot of responsibility for what you ship, and a keen eye on the work your agents are doing will go a long way. That doesn’t mean you can’t trust agents, you just need to learn how to set up agents you can trust.

That being said, vibe coding is still useful! This project is pretty low-stakes. It won’t store data, handle auth, handle payments, or have a lot of total visitors. So it’s a safe playground to use AI tools without too much oversight. The consequence of screwing something up is low, and the likelihood of screwing something up is similarly low.

Using the Claude Code desktop app

I’ve used Claude Code plenty over the last year, but always in the CLI. But every since I got hooked on the Codex mac app, I’d been meaning to try Anthropic’s take on Claude Code in GUI (as opposed to TUI).

I gave my initial prompt and was sure to select plan mode, as well as provide a reference image. Here’s the prompt I used:

Read more

That’s right - the makers of Codex are showing you cool things they built with Codex AND how they used Codex to do it.

In today’s newsletter, I’ll show you a few of these cool projects and highlight some cool prompt tricks they published alongside them.

Let’s start with “Swifty Dungeon”.

Using the imagegen skill in Codex to make a game

One of the cool project in this showcase is Swifty Dungeon, a native SwiftUI first-person dungeon crawler with generated textures, sprites, and telemetry.

Here’s the initial prompt they gave Codex:

Use $imagegen and @Build macOS apps to build a native macOS first-person dungeon crawler.

First, use $imagegen to generate a screenshot/interface of the ideal app: a native SwiftUI Liquid Glass app with the playable dungeon view in the center, the character and on-screen arrow keys in the bottom area, and player status plus inventory in the right sidebar.

Notice the use of the $imagegen skill.

In the Codex app, you can explicitly invoke a skill with the $ prefix. It’s easy to remember, and it will trigger a dropdown/autofill for available skills.

You can manually invoke a plugin with the @ prefix. Here, the @Build plugin allows computer use, which is super helpful (and also new).

These are two HUGE pieces of alpha that are hidden in this inital prompt.

Today’s newsletter is sponsored by my friends at Augment Code.

Augment was kind enough to give me early access to Intent, their next-generation tool for developing software.

All signs are pointing to the fact that the IDE is no longer the ideal place to create software.

Augment Code has jumped on this opportunity, and my first impressions are great.

Try Intent

Building an incredible landing page

Another project in the showcase that really caught my attention was the “Watchmaker Landing Page”, which is a simple but elegantly designed marketing site.

Here’s their inital prompt:

Create a new landing page for a complicated watch design with parallax effects. First generate the concepts using imagegen, then create the visual assets: each one a different piece of the watch mechanical design, and when scrolling, they should assemble into the whole design.

For each piece, there should be an accompanying paragraph on the left or right (alternate), and scrolling brings up the next paragraph and the next piece with a fading animation for the previous paragraph. I want a really smooth, traditional yet modern design - think high end luxury Swiss watchmaking.

It’s not complicated, but don’t discount its economic utility.

Building landing pages like this used to require really skilled frontend developers and designers, which is of course quite expensive. Now, sufficiently technical people with Codex can pull it off in single digit minutes.

I actually used a similar prompt to build my own landing page for interested sponsors of the newsletter, and I was really happy I could move it off of Notion with such little effort.

Building a procedural city generator

The last project I’ll highlight is a procedural city generator that lets you adjust layout, density, skyline, and visual parameters to see the city update in real time.

Here’s the initial prompt:

Generate a React app to do procedural 3D city generation. Start by generating a mockup of what a beautiful editor for procedural generation might look like, then implement it staying as close as possible to the mockup.

There should be a full screen view of the generation, then a floating control panel on the right with controls for city size, city density, block size, street pattern, commercial vs residential vs industrial balance, and presets like industrial belt or residential area.

Add skyline controls such as average height and height variance. Add city style controls for modern glass, European, Tokyo dense, cyberpunk, and other styles that change the overall color palette and building style.

Add world controls for river probability, parks percentage, terrain roughness, and terrain style switchers like coastline or mountains. Finally, include view presets such as overhead and orbit, and make the editor pane feel modern and like a 3D editor or game engine.

The big takeaway here is the specificity. They specify that it should be React, that it should match a given mockup, and the exact features they want. If you’re starting from scratch, consider using a chat tool to make a PRD and some wireframes and then feeding that into your coding tool with plan mode. More on that here:

If you want to see more exact prompts to hone your AI skills, join the paid membership for the newsletter, where you’ll find deep technical guides that take you further than initial prompting.

Subscribe now

I’ll include real examples from a project I’m just kicking off, as well as a prompt template you can use to kickstart your new project planning.

Our example project today is an AI-powered web app that helps writers turn their newsletters into short posts.

Subscribe now

New project planning prompt

We can use a chatbot first to get a solid set of requirements for our project. If you don’t even know what your requirements are, it’s way too early to write code.

The goal of the planning step is to produce three things:

• A Project Requirements Document (PRD)

• A high-level architecture overview

• A set of design wireframes

To start, use this prompt to have your LLM of choice interview you until it has what it needs to produce drafts of this document.

Read more

They’ve gone CRAZY on capabilities and features for Codex, their fast-growing Claude Code competitor.

In the last couple of weeks, Codex got in-app browser use, image generation, and computer use.

But today’s newsletter isn’t about that. Today’s newsletter is about adding some fun to Codex.

Today’s newsletter is sponsored by my friends at Augment Code.

Augment was kind enough to give me early access to Intent, their next-generation tool for developing software.

All signs are pointing to the fact that the IDE is no longer the ideal place to create software.

Augment Code has jumped on this opportunity, and my first impressions are great.

Try Intent

What are Codex pets?

Codex pets are optional companions for the Codex app.

They are not for productivity. They’re for fun!

One thing to note is that Codex pets are only available in the app, so if you’re using the CLI you’re out of luck.

How to install the Codex hatch-pet skill

First, you have to install the hatch-pet skill.

$skill-installer hatch-pet

Note that you should run this inside a Codex chat, not just in your terminal.

Once it’s done, restart Codex.

I’m glad OpenAI adopted the Skill standard, it makes it easier to switch back and forth between Claude Code.

Subscribe now

How to make a Codex pet

You can make your first pet by invoking the hatch-pet skill, which you can do with a slash command.

You’ll need to be on a recent Codex version for this to work. It uses the $image-gen tool, which requires that your Codex app supports plugins (a relatively recent addition).

Codex will generate an image and do a LOT of work to get variation sprites ready so your “pet” can be animated.

If you click into one of the subagents, you can get a bit more visibility into what it’s doing.

Codex took quite a long time for me, but eventually “Byte”, my first pet was ready!

Codex offered to save the pet, and it was packaged at .codex/pets/byte/pet.json with its spritesheet at .codex/pets/byte/spritesheet.webp.

How to wake your pet

Running /pet will wake the default pet.

To select the pet you’re interested in, go to Settings → Appearance → Pets

Then, you can select your custom pet.

Using the overlay

You’ll notice that Codex puts your pet in an overlaay in the bottom right coner of your screen. The overlay will persist throughout other screens on your computer, which is part of the point!

The overlay is meant to show active Codex work while you use other apps. It shows the current task, plus whether Codex is running, waiting for input, or ready for review. It combines that state with a short progress prompt so you can glance at what changed without reopening the thread.

Subscribe now

For example, look at this Codex pet while a task runs as I write this newseltter!

And when it finished:

This makes using Codex marginally more productive and way more fun.

Finding other pets online

If you want to add a Codex pet but you aren’t feeling creative, you’re not alone! Someone already set up Petdex, a marketplace of installable Codex pets.

As you click into one of these, you’ll see a curl command for installing the pet.

Like this newsletter? Share it with a friend! If 3 of your friends join from your referral, you’ll get a free month membership!

Refer a friend

But you can’t just blindly trust AI tools to write code for you and ship it without issues. You might win sometimes, but you’ll eventually have a serious problem. It’s not responsible.

If you don’t want to end up doing something like deleting your production database in 9 seconds, this article (and newsletter!) is for you.

Subscribe now

Guard production against agents

Your first job is containment.

Agents should not have direct access to production systems. No direct database credentials. No ability to run destructive commands.

If you don’t already follow these patterns, you should start:

• Read-only replicas for exploration

• Feature flags for risky changes

• Strict environment separation

• Scoped API keys with minimal permissions

If an agent can cause irreversible damage in one step, that’s not an AI problem. That’s a systems design problem.

Design your environment so the worst-case agent mistake is annoying, not catastrophic.

Give agents a way to validate their work

Read more

I know it’s just a test, but it feels like a canary in the coal mine. We've been operating on VC-subsidized tokens for years. That's ending. Someone has to pay for the compute.

If the cost of intelligence (especially with reasoning models) keeps rising, the economics of developer tooling get a lot harder to figure out.

In today’s newsletter, I’ll talk a bit about why this is happening, whether it’s isolated to Anthropic (it’s not), and some tips on saving tokens.

What’s happening to the cost of intelligence?

Read more

So to incentivize AI usage, they started measuring token consumption and including it in performance reviews.

More tokens = better performance

I’ll give you one guess as to what started happening.

Employees started competing on who could use the most tokens. If it sounds reasonable to you, take it to the extreme. Some folks are literally just burning tokens for the sake of their numbers, not even for productive purposes.

This Meta analyst reports that they’re calling it “tokenmaxxing” and they even have an internal leader board for it:

Today’s newsletter is sponsored by my friends at Augment Code.

Augment was kind enough to give me early access to Intent, their next-generation tool for developing software.

All signs are pointing to the fact that the IDE is no longer the ideal place to create software.

Augment Code has jumped on this opportunity, and my first impressions are great.

Try Intent

Meta isn’t the only one counting tokens for performance

I like to look at big tech companies like Meta as a nice leading indicator, but they’re not the only one doing this already. If you’ve been reading the newsletter for a while, you’ll already know that other companies are incentivizing and measuring AI usage.

Of course, measuring tokens for performance with a “more is better” attitude is out there. Still, it seems others are following suit per :

Goodhart’s law

It does surprise me that Meta would go with something this easily gameable. Goodhart’s law says:

When a measure becomes a target, it ceases to be a good measure

Do you think token usage is a good metric to measure performance?

Expect to see more weird metrics like this

Measuring engineering performance is hard. Like, really hard. Measuring AI proficiency is harder.

On one hand, should it matter how much an employee is using AI if their overall performance is great? No, it shouldn’t matter. The only reason a company wants to push AI usage would be because they believe AI makes people more valuable, even if those people aren’t bought-in.

So they seek to measure things like total token counts and incentivize higher usage. Which creates a perverse incentive, and you end up with tokenmaxxing.

My hope is that they see the flaw with this metric pretty quickly, but honestly it wouldn’t surprise me if we saw more like it pop up soon.

I want to live in a world where engineers are measured on output rather than process, but we’ll see where the next year takes us.

Subscribe now

Cursor 3 is an Agent Orchestrator interface that allows managing multiple, parallel AI agents, focusing on chat, and reviewing AI-driven code changes. The announcement post sums it up well:

We're introducing Cursor 3, a unified workspace for building software with agents. The new Cursor interface brings clarity to the work agents produce, pulling you up to a higher level of abstraction, with the ability to dig deeper when you want. It's faster, cleaner, and more powerful, with a multi-repo layout, seamless handoff between local and cloud agents, and the option to switch back to the Cursor IDE at any time.

Subscribe now

Cursor is Codex now

It doesn’t surprise me that Cursor is doing this. If you’ve used some tools we’ve talked about in the last few weeks, you’ll quickly notice Cursor now feels like Codex or even Intent.

Here’s the new Cursor:

Here’s Codex:

Here’s Claude Code in the Claude app:

And here’s Intent:

It seems pretty obvious at this point that all the best AI tools for software engineers are converging on the same UI. I think TUI (Terminal UIs) will still be around, but I think they’ll be overshadowed by these agent-manager UIs.

Writing software is mostly managing agents now

In the announcement post, Cursor shared:

How we create software will continue to evolve as we enter the third era of software development, where fleets of agents work autonomously to ship improvements.

We’re building toward this future, but there is a lot of work left to make it happen.

What do they mean, “third era of software development”?
Here’s how they break it down:

• First era: Tab-autocomplete AI suggestions in your editor

• Second era: Agents writing software (synchronously)

• Third era: Lots of agents writing software (asynchronously)

In Cursor’s view, advances in recent models like Opus 4.6, GPT-5.4, or even their own Composer 2 have opened up new possibilities. These models power agents that run for longer, with less oversight, and have better results.

So it’s only natural they’d pivot their product to make this agent orchestration easier.

How to get the new Cursor agents view

Before we talk about what’s actually new in Cursor 3’s agent view, let me show you how to get to it.

Read more

Claude Mythos is a new tier of Claude model. Opus is smarter than Sonnet. Mythos is lightyears ahead of Mythos.

Mythos is such a breakthrough that Anthropic is refusing to release it. I can see why - This is the first time a model announcement has actually made me nervous.

The security nightmare

Anthropic says Mythos Preview has already found thousands of high-severity vulnerabilities, including zero days in every major operating system and every major web browser. Its security team says the model can autonomously find zero-days in real software and often develop them into working proof-of-concept exploits with minimal human steering.

One of the most startling details in Anthropic’s system card is that internal staff with no formal security training were able to ask the model to hunt remote code execution bugs overnight and wake up to a working exploit.

For a while, it was easy to talk about AI coding in terms of productivity. Faster boilerplate. Better autocomplete. Quicker test writing. Useful repo search. That framing is now too small.

The same general capability gains that push up SWE-bench also push up vulnerability discovery and exploit development. Anthropic says that directly in its security writeup: the improvements that make the model better at patching vulnerabilities also make it better at exploiting them.

Subscribe now

Mythos crushes benchmarks

The benchmark numbers are the first reason this matters. Anthropic says Claude Mythos Preview hit 77.8% on SWE-bench Pro, 93.9% on SWE-bench Verified, and 82.0% on Terminal-Bench 2.0.

On the same reporting, Opus 4.6 sat at 53.4%, 80.8%, and 65.4%. Anthropic also says the margin holds even after excluding problems that show signs of memorization. Jumps this large are not the kind of thing you explain away with prompt tweaks or benchmark luck.

Intelligence in the hands of the few

Anthropic is not generally releasing Mythos Preview. Its public announcement says the model is being restricted to Project Glasswing partners (to find and fix vulnerabilities) plus a group of more than 40 additional organizations involved in critical software infrastructure and defensive security work.

Read more

LLMs generate vulnerable code because their training data is full of it. Then they review that same code and see nothing wrong. Three failure mechanics explain why:

• same training distribution

• no adversarial reasoning

• An inability to flag what's absent.

None of these get fixed by a better prompt.

Today’s post is written by , author of a newsletter that shows you exactly how the attacks work. before the bad guys use them against you. If you like it, consider subscribing.

ToxSec - AI and Cybersecurity

Security for a world run by machines that lie.

0x00: Why your AI code reviewer rubber-stamps its own bugs

The workflow looks like defense-in-depth. A developer generates code with Copilot or Cursor, then runs it through an LLM-based review pass: CodeRabbit, Copilot code review, or just pasting the diff into ChatGPT with “find the bugs.” Two checks, two chances to catch a vulnerability. Solid engineering practice.

Except you built one checkpoint staffed by one guard wearing two hats. The model that generated the vulnerable pattern is the same model (or same architecture, same training distribution) is now evaluating it. Every statistical blind spot that caused the bug also prevents the review from flagging it.

This has a name in the research literature. Tsui et al. (2025) call it the “Self-Correction Blind Spot”: across 14 open-source LLMs, models failed to correct errors in their own outputs 64.5% of the time, while successfully correcting identical errors attributed to external sources.

The cause maps directly to training distribution: human demonstrations rarely include error-correction sequences, so the model never learned to distrust its own patterns. Three specific failure mechanics make this inevitable in code review. If you’re shipping AI-generated code through AI-reviewed PRs, all three are hitting your codebase right now. ToxSec covers the broader AI security landscape if you want the full picture.

0x01: How the same training data creates identical blind spots

LLMs learn “normal code” from public repositories. GitHub is full of raw SQL string concatenation, unsanitized URL parameters, and direct DOM injection. Those patterns are the signal in the training data, not noise. The model learned that f”SELECT * FROM users WHERE id = {user_id}” is how you query a database, because millions of training examples do exactly that.

So the model generates CWE-89 with confidence. It’s producing the most statistically dominant pattern for “retrieve a user from the database.” Then you hand that output to the same model for review, and it parses the query, confirms it retrieves a user by ID, and stamps it clean. Pattern matches training distribution. “Looks correct.” Because from a pure probability standpoint, it is.

Same mechanic with CWE-918. The model generates a Flask route that takes a user-supplied URL and passes it straight to requests.get(). Review time: it reads the function, confirms the endpoint fetches a URL, and moves on. The SSRF vector is invisible because fetching user-supplied URLs without validation is the dominant pattern in the training corpus. A systematic literature review of 20 studies found that injection vulnerabilities (SQL injection, XSS, command injection) appeared in 16 of 20 papers analyzing LLM-generated code, making them the single most common vulnerability class LLMs produce.

Think about what the model would need to do to catch CWE-89 here. It would need to recognize that the statistically dominant pattern, the one it was literally trained to produce, is dangerous. That’s asking the model to override its own priors.

The parameterized version (cursor.execute(”SELECT * FROM users WHERE id = %s”, (user_id,))) exists in the training data too, but it’s less common. The model picks the majority pattern for generation and accepts the majority pattern at review. Same weights, both directions. If the vulnerable version is the most probable output, it’s also the least likely to trigger a flag.

Jeff here! Today’s newsletter is sponsored by my friends at Augment Code.

Augment has been kind enough to give me early access to Intent, their next-generation tool for developing software.

All signs are pointing to the fact that the IDE is no longer the ideal place to create software.

Augment Code has jumped on this opportunity, and my first impressions are great. Check it out!

Check out Intent

0x02: Why LLMs review code intent instead of attack surface

Even if you could fix the distribution problem, something deeper breaks the model. LLMs evaluate whether code does what it’s supposed to do. They don’t model what an attacker would do with it.

A human security reviewer sees response = requests.get(user_url) and immediately asks:

What if user_url is http://169.254.169.254/latest/meta-data/?

The model sees the same line and confirms:

This function fetches a URL, consistent with the endpoint’s purpose.

One is threat modeling. The other is intent matching. Completely different cognitive operations, and only one of them catches vulns.

CWE-79 slips through here with zero friction. The model generates document.innerHTML = userComment and reviews it as “displays user content in the UI.” Functionally accurate.

Completely exploitable. The <script> tag a real attacker would inject never enters the model’s evaluation because it isn’t simulating adversarial input. It’s confirming that the code does what the variable names suggest.

The self-repair data backs this up. Gong et al. (2024) found that 75% of LLM-generated code was classified insecure, and models “perform poorly on their own code due to self-repair blind spots” while managing to repair up to 60% of insecure code produced by other LLMs.

Same vulnerability, different source, different detection rate. The blind spot is model-specific, and it tracks with the training distribution.

There’s a related failure that compounds the problem. Most security vulnerabilities are defined by what’s absent from the code: no input validation, no parameterized query, no URL scheme allowlist, no output encoding. LLMs are excellent at evaluating what’s present. They’re structurally bad at noticing what’s missing.

A pattern matcher can confirm that a function correctly fetches a URL. It struggles to flag that the function never checks whether that URL points at an internal metadata endpoint. The vulnerability is a missing check, and missing things don’t produce tokens.

LLMs are next-token predictors optimized for helpfulness. Adversarial reasoning requires simulating hostile input against every trust boundary in the code. You’re asking a pattern-completion engine to think like a pentester, and the architecture can’t do it.

Analysis of over 20,000 SWE-bench issues found that LLM agents introduce vulnerabilities at roughly nine times the rate of human developers, a gap that persists even with security-focused prompting.

0x03: What actually catches AI-generated code vulnerabilities

Deterministic tooling catches what statistical models can’t, because Semgrep doesn’t care what “normal” looks like. It matches rules. A SAST scanner flags f”SELECT * FROM users WHERE id = {user_id}” every time, because “string-formatted SQL query” fires the rule regardless of how common the pattern is in GitHub.

One caveat: SAST isn’t bulletproof either. Dai et al. (2025) showed that CodeQL misses several vulnerability classes, and that when evaluating code for both security and functionality simultaneously, existing mitigation techniques “even degrade the performance of the base LLM by more than 50%.” The conclusion isn’t that SAST is perfect. It’s that deterministic rules catch a different class of bug than statistical models do, and you need both.

Layer the pipeline correctly. SAST in the pre-commit hook for known vulnerability patterns. DAST in staging to catch runtime behavior that static analysis misses. Human review on security-critical paths: auth flows, payment processing, anything where user-controlled input touches infrastructure or secrets.

If you want AI-assisted review in the pipeline, use a different model than the one that generated the code. Different providers train on different data with different distributions. A second opinion from a genuinely different model introduces variance into the blind spots. The research supports this: models repair code from other LLMs at significantly higher rates than they repair their own output.

Treat AI review as a linter, not a security gate. It catches formatting issues and surface-level logic errors. It will not catch the vulns that matter most, because those vulns look like correct code to any model trained on the same internet.

Your CI pipeline should reflect the hierarchy: deterministic tools first, AI review for style and logic, human eyes on anything with a security surface. The moment AI review becomes your last line of defense before prod, you’ve already lost.

Frequently asked questions

Can a better prompt fix AI code review security blind spots?

No. The problem is the training distribution, not the instruction. Tsui et al. (2025) showed that the self-correction blind spot persists across 14 models and traces back to how training data is structured: demonstrations rarely include error-correction sequences.

You can tell the model to “focus on security vulnerabilities” and it will try, but it still evaluates code against the same statistical priors. Prompt engineering shifts attention slightly. It doesn’t change what the model considers normal code.

Which SAST tools catch AI-generated code vulnerabilities?

Semgrep, Bandit (Python), ESLint security plugins (JavaScript), and CodeQL all catch common CWEs regardless of whether a human or an LLM wrote the code. They match deterministic rules against code patterns. That said, Dai et al. (2025) showed CodeQL misses certain vulnerability classes, so no single tool covers everything. Layer multiple tools for coverage.

Should developers stop using AI code review entirely?

Keep it in the pipeline, but stop treating it as a security control. AI code review catches logic bugs, style issues, and obvious errors well. Just make sure it's never the last gate before production for anything with a security surface. Pair it with SAST, DAST, and human review on critical paths.

Does using a different AI model for code review help?

It introduces meaningful variance. Gong et al. (2024) found that LLMs can repair up to 60% of insecure code from other models while performing poorly on their own output. Different models with different training data have different blind spots.

A second model is better than the same model reviewing itself. Neither replaces a SAST scanner or a human security reviewer.

What vulnerability does AI code generation produce most often?

SQL injection (CWE-89) and cross-site scripting (CWE-79) appear in the majority of studies. A systematic review found injection vulnerabilities documented in 16 of 20 papers analyzing LLM-generated code. These are the most common patterns in public training data, which is exactly why models reproduce them confidently and miss them consistently during automated code review.

That conversation clarified something important for me. If you approach Intent like a better chat window for coding agents, you will miss the point. Intent is not really built around chats or files. It is built around workspaces.

That sounds like a small distinction, but it changes how you use the product.

The core idea behind Intent is that a developer task is bigger than code. Real work includes branches, local state, conversations, notes, specs, browser state, and all the half-finished thinking that usually gets lost between sessions or flattened into a pull request. Intent’s answer is to bundle all of that into an isolated workspace for a specific task.

Once that mental model clicks, the product makes a lot more sense.

Start with the right mental model: workspace first

The biggest insight from my conversation with Amelia was that Intent is “workspace first,” not “agent chat first.”

A lot of agent tools are basically chat interfaces wrapped around one or more models. You talk to an agent, maybe spin up another one, maybe ask it to edit files, and the interface is still centered on the conversation. Intent is aiming at a different problem.

It starts from the fact that developer workflows are messy. Work does not live neatly inside a single chat thread, and it definitely does not live only in a diff. You have code, but you also have context: issue threads, design notes, rough plans, screenshots, browser state, decisions you made three hours ago, and questions you still have not resolved.

I recently saw a really good video describing this problem, especially how agents complicate things:

Intent’s workspace is meant to hold that whole bundle.

So the first tip is simple: stop thinking of Intent as “where I talk to an agent.” Think of it as “the place where one task lives.”

Use one workspace per real task

One of the early points of confusion for me was Git worktrees.

Amelia said this is a common gotcha for new users, and after hearing the explanation, the choice makes a lot more sense. Intent uses one Git work tree per workspace. That is not an incidental implementation detail.

The purpose is isolation.

If you are working on one feature, that feature gets a workspace. If you are fixing a bug in parallel, that gets a different workspace. If you need to review something unrelated, that should probably be another workspace too.

In other words, the workspace is the unit of parallel work.

This is a useful way to think about it because many of us are used to muddling through overlapping tasks in the same repository and then paying the price later. Conflicting PRs, muddy branches, context switching, and “wait, what state was this task in?” are all downstream effects of weak task boundaries.

Intent is opinionated here. If the work is separate, the workspace should be separate.

Subscribe now

Do not create a new workspace for every agent chat

A workspace is not meant to map one-to-one with a single agent conversation. Inside a workspace, multiple specialist agents can collaborate, share awareness, and delegate to each other. They are not isolated from one another the way separate workspaces are.

That means you should resist the urge to spawn a new workspace just because you want a fresh chat.

If the work is still the same work, keep it in the same workspace. Let the agents coordinate inside that environment. The isolation boundary is the task, not the conversation.

Intent is trying to keep the full context for a task together, so the tool becomes more valuable the more consistently you respect that boundary.

Set up your project for isolation

One practical issue I brought up was environment variables.

If you spin up a fresh work tree and your .env file is gitignored, the project can break locally because those values do not come along automatically. Amelia acknowledged that downside and said the intended solution is setup scripts that copy environment files when a new workspace starts.

The practical advice here is to treat setup as part of your workspace design.

If your project needs local secrets, bootstrapping scripts, seed data, or other machine-specific state, invest in a reliable workspace setup flow early. The better that onboarding path is, the more painless it becomes to spin up isolated workspaces whenever you need them.

Use the built-in browser as part of the workspace, not as a side tool

One detail I liked was that the browser is also workspace-specific.

If you are juggling multiple tasks, you do not just need separate code. You often need separate running app states, separate pages, separate test flows, and separate visual checkpoints.

An isolated browser per workspace makes that much cleaner.

Amelia mentioned they had been managing ten different workspaces at once, and this is one of the things that makes that kind of multitasking possible. Each workspace keeps its own state, and the agent can interact with that browser context directly, including taking screenshots and working from what it sees.

If a task involves UI behavior, a user flow, or a bug you need to reproduce, keep that browser state attached to the workspace instead of reconstituting it from memory every time.

Customize your specialist agents

Another interesting part of the discussion was how much of the application’s behavior is effectively encoded in the prompts for the specialist agents.

That means the specialist system is not meant to be a black box. It is meant to be configurable.

So another tip is not to accept the default agent behavior as fixed. If the coordinator is too verbose, too passive, too eager to implement, too hesitant to plan, or not structured the way you want, that is part of the workflow you should shape.

Intent seems to want users to define how their team or personal process actually works.

Think in orchestration, not single-agent magic

The differentiator between Intent and Codex is that in Intent, the workspace is designed to orchestrate specialist agents around a task. That is a more interesting idea than a single chatbot that happens to edit code.

If you use Intent well, you should be asking: what set of specialists should operate in this workspace, what context do they need, what notes should anchor them, and how should they coordinate?

The main takeaway

If most agent tools feel like a conversation that can touch your code, Intent feels like a task environment that happens to contain coordinated agents.

That is the mindset I would recommend carrying into the product.

Open a new workspace sooner when the work is truly separate. Treat the browser as part of the context. Invest in setup scripts so isolation is painless. Use a meta workspace when a project needs long-term memory. Customize your specialists. Think in orchestration.

Once you do that, the product’s design starts to feel much more coherent.

If you want to read more about Intent, I did a deep dive back in February:

But have you ever wished you could change them?

Claude Code recently added a spinnerVerbs option to its settings. Today, I’ll walk you through how to change your Claude Code settings to customize these spinner words that show up when Claude is doing it’s thing.

Subscribe now

How Claude Code settings work

This could probably be a post in itself.

You can set Claude Code settings at globally or at the project-level. This is helpful if you want behavior to be different from project-to-project or you want the settings in version control for your peers.

I really only use user settings though, and that’s what makes the most sense for spinner verbs.

User settings are defined in ~/.claude/settings.json and apply to all projects. My settings are very vanilla - one of the great things about the product is the strong and useful defaults.

There are a ton of available settings though.

You can edit your settings by editing the ~/.claude/settings.json file directly or you can ask Claude to do it for you. I’ll show you how for spinner verbs.

Today’s newsletter is sponsored by my friends at Augment Code.

Augment was kind enough to give me early access to Intent, their next-generation tool for developing software.

All signs are pointing to the fact that the IDE is no longer the ideal place to create software.

Augment Code has jumped on this opportunity, and my first impressions are great.

Check out Intent

Setting your spinner verbs

One important thing to keep in mind is that you should use present participles (ending in "-ing").

I asked Claude to update the file for me (I’m lazy), here was my prompt:

Edit my ~/.claude/settings.json to customize the spinner verbs. I want the spinner verbs to be Star Trek themed - use present participles (ending in “-ing”). Replace the defaults with 60 start trek verbs that sound fun.

The result was pretty good! The verbs are a little cringy but they’ll do for now.

The model literally just added a section to my settings:

"spinnerVerbs": {
    "mode": "replace",
    "verbs": [
      "Engaging",
      "Beaming",
      // Rest of file ommited for brevity
     ]

I hope this adds a bit of whimsy to your workflow!

Share

It’s well-understood that it’s a best practice to add your .env file (or equivalent) to .gitignore so it doesn’t get tracked in version history. It should become a best practice to deny AI tools the ability to read tokens from these files too.

I’ll show you how - the process only takes a minute or two.

How to stop Claude from reading .env

Read more

One of the things that Codex excels at is parallel agent orchestration.

Using a UI that’s optimized for agents means you have better support for naturally switching between tasks. But there are some things that can make this tricky.

If you build software professionally, you probably know where I’m going with this. Several people working on a codebase at the same time inevitably leads to conflicts where each is making changes to the same code without knowledge of the others’ code changes.

For people, this causes merge conflicts with their PRs.

Agents can run into the same problem!

So how do you get around it? Git worktrees is a really neat way to have several local agents making changes at once. In today’s article, I’ll show you how to:

• Make a setup script that Codex will use in new worktrees

• Set up actions so Codex can easily test your app

• Use worktrees to orchestrate a few agents to make changes to an app at the same time

• Promote your worktrees to proper Git branches

Setting up Codex

If you haven’t already read our intro to Codex post, it’s a great place to start:

It first came out for Mac, but recently also launched for Windows!

If you haven’t already, visit the Codex website and install the app. You should use your ChatGPT account, which comes with really generous limits even on the free tier.

Writing a setup script for your worktrees

The biggest issue I had with worktrees right away was that each worktree couldn’t actually have the project run. First, because they hadn’t installed dependencies. Then, because they didn’t have my environment variables. Since my .env file was in my .gitignore, it didn’t show on worktrees.

The solution Codex (and also Intent) promotes is to use setup scripts, which get run when a new worktree is created.

Once you’ve opened your project in Codex, go to Settings → Environments → Your Project Name.

I’ll show you the setup script I’m using for my DeepFocusTimer app, then I’ll show you the actions I’m using. Finally, we’ll move on to actually orchestrating some agents to make some changes to that app.

Here’s my setup script:

  WORKTREE_PATH="$(pwd)"
  MAIN_CHECKOUT="$(git rev-parse --path-format=absolute --git-common-dir | sed 's|/\.git$||')"
  BRANCH_NAME="$(git branch --show-current)"

  # Copy environment and config files
  for file in .env .env.local .envrc .tool-versions; do
    if [ -f "$MAIN_CHECKOUT/$file" ]; then
      cp "$MAIN_CHECKOUT/$file" "./$file"
      echo "Copied $file"
    fi
  done

  echo "Config files copied"

This just copies over config files from my local workspace.

Actions in Codex

In the same spot, you have the opportunity to configure actions, which will give you quick buttons to do things like run your project, run your tests, or run your linter.

I’ve set mine up for running the project locally and for linting.

Now that you have Codex set up so your worktrees will actually work, it’s time to do some agent orchestration!

There’s a few things we’ll do in the app:

• Write a new blog post for SEO (Marketing)

• Make the session history show a loading state for logged in users before the session history loads (Bug fix)

• Make the session description autofill from the last session descripion (Feature)

We’ll have Codex do all of these in worktrees, then I’ll show you how to unwind those worktrees to get the code onto master.

Orchestrating agents in Codex

Let’s start with the blog post. In an earlier article, we had Codex and Claude Code write some pretty sweet blog posts for a marketing experiment:

That marketing experiment seems to be a success, since both posts are ranking for their primary keyword. Search impressions have gone up 6x!

So we’ll have Codex make us another one. I’ll kick that off first with this prompt:

Read more

For those of you wondering if AI is going to shrink your brain, you’re going to want to read this.

This newsletter is for tech workers who want to multiply their impact using bleeding-edge AI tools. If you want to accelerate your career, you’re in the right place.

Subscribe now

How the study was laid out

Anthropic just ran a randomized controlled trial with 52 software developers (mostly junior) who used Python regularly, were familiar with AI coding help, but had not used the async library Trio.

Participants did:

• a warm-up (no AI),

• a main task implementing two small features with Trio (AI allowed only for the treatment group),

• then a quiz (no AI).

The quiz intentionally emphasized skills that matter when you’re supervising AI-written code: debugging, code reading, and conceptual understanding.

So what was the result?

AI help reduced learning, and didn’t meaningfully speed people up.

• The AI group finished a bit faster on average, but it wasn’t statistically significant.

• The AI group scored ~17% lower on the immediate knowledge quiz (roughly “two letter grades” in their framing).

• The biggest gap showed up in debugging.

This is the part a lot of engineers should sit with. The “future-proof” skill is not “typing code fast.” It’s knowing when code is wrong, why it’s wrong, and what to change. This study suggests your tooling can quietly erode that muscle when you’re learning something new.

How you use AI matters!

How to use AI without turning off your brain

Read more

If you’re not familiar with Block, they run Square, Cashapp, and several other thriving product lines.

So why did they cut 40% of their headcount last week? Artificial intelligence is making the remaining 60% more productive.

Jack Dorsey’s note

I’ll just start here with the tweet shared by Block’s CEO:

today we're making one of the hardest decisions in the history of our company:

we're reducing our organization by nearly half, from over 10,000 people to just under 6,000. that means over 4,000 of you are being asked to leave or entering into consultation.

i'll be straight about what's happening, why, and what it means for everyone. first off, if you're one of the people affected, you'll receive your salary for 20 weeks + 1 week per year of tenure, equity vested through the end of may, 6 months of health care, your corporate devices, and $5,000 to put toward whatever you need to help you in this transition (if you’re outside the U.S. you’ll receive similar support but exact details are going to vary based on local requirements).

i want you to know that before anything else. everyone will be notified today, whether you're being asked to leave, entering consultation, or asked to stay. we're not making this decision because we're in trouble. our business is strong. gross profit continues to grow, we continue to serve more and more customers, and profitability is improving.

but something has changed. we're already seeing that the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company. and that's accelerating rapidly. i had two options: cut gradually over months or years as this shift plays out, or be honest about where we are and act on it now. i chose the latter. repeated rounds of cuts are destructive to morale, to focus, and to the trust that customers and shareholders place in our ability to lead.

i'd rather take a hard, clear action now and build from a position we believe in than manage a slow reduction of people toward the same outcome. a smaller company also gives us the space to grow our business the right way, on our own terms, instead of constantly reacting to market pressures. a decision at this scale carries risk. but so does standing still. we've done a full review to determine the roles and people we require to reliably grow the business from here, and we've pressure-tested those decisions from multiple angles. i accept that we may have gotten some of them wrong, and we've built in flexibility to account for that, and do the right thing for our customers.

we're not going to just disappear people from slack and email and pretend they were never here. communication channels will stay open through thursday evening (pacific) so everyone can say goodbye properly, and share whatever you wish. i'll also be hosting a live video session to thank everyone at 3:35pm pacific. i know doing it this way might feel awkward.

i'd rather it feel awkward and human than efficient and cold. to those of you leaving…i’m grateful for you, and i’m sorry to put you through this. you built what this company is today. that's a fact that i'll honor forever. this decision is not a reflection of what you contributed. you will be a great contributor to any organization going forward. to those staying…i made this decision, and i'll own it. what i'm asking of you is to build with me.

we're going to build this company with intelligence at the core of everything we do. how we work, how we create, how we serve our customers. our customers will feel this shift too, and we're going to help them navigate it: towards a future where they can build their own features directly, composed of our capabilities and served through our interfaces. that's what i'm focused on now. expect a note from me tomorrow.

jack

What the note means

Jack is pretty clear about the business being healthy and layoffs not being driven by declining profits. Block is growing and seems to have a healthy business.

I want to spend the rest of the newsletter covering a few things:

• Did Block overhire?

• Lines of code is no longer the bottleneck

• Using AI effectively

Read more