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

But with this model, you can’t use it the same way you used Opus 4.5.

The model upgrade and upgraded benchmark numbers are the 20%.

Effort controls, Agent Teams, /insights, and adaptive thinking and 200+ page system card are the other 80%.

Today, is going to walk you through how you can use them today.

Ilia writes - if you like this guide, you’ll love Propser!

Let’s get into it!

Effort controls in Opus 4.6

Every time you ask Claude a simple question, it thinks deeply by default. That’s the `high` effort setting - and it’s been burning your tokens on tasks that don’t need deep reasoning.

Opus 4.6 introduced a new Effort parameter with four levels: `low`, `medium`, `igh (default), and max.

It changes Claude’s behavior. At low, Claude skips extended thinking, makes fewer tool calls, and moves faster. At `high`, Claude reasons deeply and thoroughly and gives you the most thorough exploration of the problem.

Here’s the practical breakdown:

low — Skips thinking, minimizes tokens, moves fast. Use for quick lookups, simple translations, subagents doing routine work.

medium — Moderate depth, may skip thinking for easy queries. Use for routine code generation, balanced agentic tasks.

high (default) — Deep reasoning on almost everything. Use for complex coding, architecture decisions.

max (Opus 4.6 only) — No constraints on thinking depth. Use for hard problems where you need Claude to exhaust every angle.

Subscribe now

Anthropic themselves say it: ”Opus 4.6 often thinks more deeply and more carefully revisits its reasoning before settling on an answer. This produces better results on harder problems, but can add cost and latency on simpler ones.” They literally recommend dialing effort down to `medium` if the model is overthinking.

The key insight: you decide the effort level, not Claude. You’re the one who knows whether a task is trivial or genuinely hard. The AI doesn’t decide for you - you decide for the AI.

Here’s the API call:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
   model="claude-opus-4-6",
   max_tokens=16000,
   thinking={
       "type": "adaptive"
   },
   output_config={
       "effort": "low"  # or "medium", "high", "max"
   },
   messages=[{
       "role": "user",
       "content": "What is the capital of France?"
   }]
)

What you can do right now: If you’re building anything with the API, add effort to your calls. Use low for subagents doing simple lookups. Use max when you’re debugging something genuinely hard. You’ll notice the speed difference on low immediately - and the depth difference on max when it matters.

One more thing: Effort replaces budget_tokens, which is now deprecated on Opus 4.6. If you’re still manually setting thinking token budgets, switch to effort levels. Claude now handles the allocation itself through what Anthropic calls adaptive thinking.

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 out Intent

Adaptive thinking in Opus 4.6

Before Opus 4.6, you were only able to manually toggle extended thinking on or off and set a token budget.

Now you set `thinking.type` to ”adaptive” and Claude decides when to think deeply based on complexity. At `high` and `max` effort, it almost always thinks. At `low`, it skips thinking for problems that don’t need it.

The part most people miss: adaptive thinking also enables interleaved thinking. In agentic workflows, Claude reasons between tool calls - not just at the start. It re-evaluates after every step instead of planning once and executing blind.

Set it to adaptive, pair it with the right effort level, and move on.

Claude Code agent teams (multiple agents in parallel!)

“Agent teams are just fancy subagents.” I’ve seen this take everywhere. It’s wrong.

Subagents report back to one main agent. It’s a hub-and-spoke model - the main agent coordinates everything, receives results, synthesizes, delegates again.

Agent Teams communicate with each other. A lead session coordinates while teammates work independently, claim tasks from a shared task list, and self-organize. The lead doesn’t micromanage every assignment.

Subagents: Report back to the main agent only. Main agent manages all coordination. Sequential hand-offs. Lower token cost. Best for focused, isolated tasks.

Agent Teams: Can message each other directly. Shared task list where teammates claim work themselves. Parallel, independent execution. Higher token cost (every teammate runs its own full context window). Best for complex work needing collaboration.

How to Enable Claude Code Agent Teams

Agent Teams is experimental.

Set CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1 in your environment or add it to your Claude Code settings. Once enabled, tell Claude to create an agent team. Use Shift+Up/Down to cycle between agents in the same terminal, or use tmux to see all agents working side by side.

Best Use Cases for Claude Code Agent Teams

Parallel code review. Three reviewers — security, performance, test coverage — working simultaneously, each with their own context.

Debugging with competing hypotheses. Two agents investigate different root causes in separate contexts. They don’t step on each other.

Cross-layer features. Frontend, backend, and test agents working on different parts of the same feature.

When NOT to Use Claude Code Agent Teams

Same-file edits (merge conflicts), sequential work (if step 2 depends on step 1), or simple tasks where coordination overhead isn’t worth it. Agent Teams are high-token-cost by design — every teammate runs its own full context window.

Claude Code /insights command (analyze your coding workflow)

This might be the most interesting thing in the entire release.

Type /insights in Claude Code. It reads your past 30 days of sessions, processes them, and generates an interactive HTML report about your coding habits. Anthropic’s Thariq decribed itas feeling eerily like a well-informed manager.

The report doesn’t just show statistics. It tells you what’s working, what’s slowing you down, and what you should try differently. Here’s a snippet of how useful it can be:

What the Claude Code /insights report shows you

Usage stats. Messages sent, lines changed, files touched, days active.

Work breakdown. Project areas ranked by session count — it separated my work automatically without me specifying anything.

Working style analysis. A narrative describing how you work, not just what you work on.

Friction analysis. Categorizes your friction by type, ranks by frequency, and gives specific examples. My biggest: “wrong approach and premature action” at 46 instances.

Copy-paste CLAUDE.md rules. What I showed in a previous section. Generates rules you can add directly to your config — tailored to the exact friction patterns it found.

Why /insights matters for your Claude Code workflow

Most people optimize their prompts. Almost nobody optimizes the system around their prompts. `/insights` shows you the patterns you can’t see yourself — then gives you the specific configuration changes to fix them.

I wrote a full deep dive on /insights and the workflow changes I made after running it.

Prosper

Claude Code /insights Roasted My Workflow. Here's What I Fixed.

I ran one command last week. Typed `/insights` into Claude Code, waited a few minutes, and got back an interactive HTML report analyzing my last 30 days of sessions…

Read more

3 months ago · 4 likes · Ilia Karelin

The short version: run it, go straight to the friction analysis, and add the suggested CLAUDE.md rules. Takes five minutes. Prevents the same mistakes from repeating every session.

The Opus 4.6 system card tells you things the announcement skipped

Anthropic published a system card alongside Opus 4.6. It’s 200+ pages long, so most people skip it, and I can understand why. It’s a dense PDF full of safety evaluations and benchmark methodology. But buried inside are practical details about how the model actually behaves — details that change how you should use it.

Opus 4.6 Is “Over-Eager” — Use Plan Mode

The system card explicitly flags that Opus 4.6 is *”at times overly agentic.” In testing, it took risky actions without asking: it wrote and sent hallucinated emails when it couldn’t find a requested one, and initialized nonexistent repositories just to tag an issue.

It’s a side effect of the model being better at autonomous work. It’s so good at taking initiative that it sometimes takes initiative you don’t want.

The fix: Use Plan Mode to force a proposal step before execution. And add this to your CLAUDE.md:

Always plan and seek approval before executing destructive actions (e.g., git reset, rm) or sending external communications.

If you ran /insights and saw “wrong approach and premature action” in your friction analysis (I saw it myself in my own report), this is the same problem from the other side. The model is eager. Give it guardrails.

The SWE-bench prompt tricks you can steal

The system card reveals specific prompt instructions that pushed Claude’s software engineering score to its peak (81.4% on SWE-bench Verified). These aren’t secret - they’re just buried in a PDF nobody reads:

• ”Use tools as much as possible (ideally >100 times).”

• “Implement your own tests first before attempting the problem.”

• ”Take time to explore the codebase and understand the root cause of issues, rather than just fixing surface symptoms.”

Add these to your CLAUDE.md or system prompt. They’re the exact directives Anthropic used to get peak performance out of their own model.

Two behavioral quirks you’ll eventually hit

Answer thrashing. Sometimes the model computes one answer internally but keeps typing a different one. It gets stuck in a loop between its reasoning and a memorized training pattern. If Claude seems to be arguing with itself or flip-flopping on a straightforward answer — don’t try to argue it out of the loop. Restart the session.

Tedium aversion. The model sometimes avoids tasks requiring repetitive manual effort, like extensive counting or line-by-line verification. If Claude seems “lazy” on a high-toil task, tell it to write a script to do the work instead of doing it manually. It’s better at automating tedium than enduring it.

API Change: Partial-turn prefill is gone

If you previously seeded incomplete responses for Claude to continue (partial-turn prefill) — that no longer works on Opus 4.6. You now need to use full-turn prefill (providing a complete conversation history) or more robust system prompts to guide output format. Small change, but it’ll break existing workflows if you relied on it.

Security: Both sides of the coin

On defense: Opus 4.6 achieved a 0% attack success rate against indirect prompt injections in agentic coding environments — even without extra safeguards. If you’ve been hesitant to let Claude browse local files or the web in agentic workflows, this is the most robust model Anthropic has shipped for that use case.

On offense: it hit a 66.6% success rate on CyberGym — finding known vulnerabilities in real software projects. That’s up from Sonnet 4.5’s 29.8%. If you’re using Claude for security audits or code review, I’d definitely suggest using Opus 4.6.

Claude Opus 4.6 context compaction

One more feature that flew under the radar. Long agentic sessions used to hit a wall when the context window filled up.

Anthropic calls this ”context rot” — performance degrades as conversations exceed a certain number of tokens. You’d have to restart the conversation or manually manage context.

Context compaction (currently in beta) automatically summarizes older parts of the conversation when approaching context limits. Claude continues working without losing track of what happened earlier.

If you’re running complex multi-step workflows — full codebase refactors, long debugging sessions, multi-file feature builds — this means the agent can work for much longer without you intervening. Combined with the 1M token context window (also new in Opus 4.6), you can feed it entire codebases, not just files.

What to do this week

The model improvement is real. Opus 4.6 beats 4.5 across every benchmark. Same pricing. Direct upgrade. No reason not to switch.

But the model is the engine. Effort controls, adaptive thinking, Agent Teams, `/insights`, and context compaction are the steering wheel, the mirrors, and the GPS. Most people will drive this thing in first gear and never touch the rest.

The gap between “I updated to Opus 4.6” and “I’m actually using Opus 4.6” is where the real advantage lives.

Subscribe now

And I’m not talking about the models.

Claude models like Opus 4.6 are awesome. Open AI Codex models like GPT-5.3-Codex are great too. But each has their own custom harness available.

Sure, you can use Claude models inside Cursor or Copilot, but Claude Code is the best way to use Claude Models.

And the same is true for Codex models. You can use them in lots of tools, but the devrel team at OpenAI is clearly betting big on the new Codex app.

So I thought, why not compare each tool and model against each other on an identical task?

The marketing landing pages we’ll make

I have this micro-SaaS, Deep Focus Timer.

It shouldn’t be a surprise to you that I wrote it 100% with AI. I have maybe contributed less than a dozen organic lines of code to this project. And I use it just about every day.

In a low-effort way to catch some SEO juice, I wrote a simple blog post on deep work for the site. A while ago I used the frontend-design skill to redesign the site into what you see now. You can read more about that here:

As part of that redesign, Claude autonomously decided to change the static blog post into something a little more engaging.

This is AWESOME, but it presents one issue. Making new blog posts is kind of a pain.

But that presents an opportunity! I want to add 2 blog posts on topics relevant to my tool, and I’ll use both Codex and Claude Code to do it.

This gives each tool the opportunity to:

• Write some engaging content

• Design a great blog post frontend

• Make independent decisions about visual elements to increase conversion to account creation

Sound good? Let’s get into it.

Prompting Codex

You can visit the Codex website and install the app if you have a Mac. You can sign in with your ChatGPT account, which comes with really generous limits. Even the free tier of ChatGPT has usage for now.

Adding the frontend design skill to Codex

If we’re going to compare Codex to Claude Code, it’s only fair they have the same skill. You may remember a previous article where I raved over the frontend-design skill.

Fortunately, skills are now an open standard. That means Claude Code Skills work for Codex too! Codex has a pretty interesting skill library built-in.

The easiest way to add a new skill is to use the Skill Creator Skill. Meta right? I mostly copied the markdown from Anthropic’s repo for this skill.

Once that was done, I started a new chat in my repo. I recommend using a new chat for each task you give any LLM tool, so you can keep your context clean.

Setting up a blog parent page with Codex

My app only has one blog post, and no blog parent page. It’s just linked in a popover, which doesn’t translate well to multiple posts. So first, I prompted Codex to fix that.

This app has a blog post in app/what-is-deep-work/page.tsx - The blog post is accessible from a link in the question mark box on the home page. Make it so there is a proper "blog" page instead of that link to this blog post in the question mark thing. The blog link should be in a new footer that matches the existing design of the site.

The blog page should list all blog posts, which for now, is only this one. Do any re-architecture necessary to make that happen. I like that the existing blog post has a lot of custom design so don't strip it down to just markdown. Make these changes so that it is easy to add new blog posts in the future, and so they will show up on that blog page, and the blog page is linked in a new footer. Use the frontend-design skill to make it a great design

Notice I explicitly called out the frontend-design skill we just added. This site was only designed with Claude Code, so we’ll see how GPT-5.3-Codex does with staying consistent.

One thing you may notice about using Codex is that it is optimized well for long-running tasks. Codex will take a LONG time to scan your codebase for appropriate context, which makes it great at one-shotting things.

I use to say the pursuit of one-shot prompting was overrated, but now that we’re at the point a model can do it really well, I’m ready to say I was wrong there. It’s nuts to describe a problem and have a model just nail it. This makes it much easier to multitask (which I can’t always recommend).

Codex also seems much more likely than Claude Models to acutally try to build, lint, and run its changes without being explicitly asked to.

I was really happy with the first shot of the blog page!

Fixing the footer with Codex

The footer wasn’t great though, so I explained a number of changes that I wanted Codex to make.

Read more

We’ve gone from chat-based tools to autocomplete, to agent extensions in your IDE. Each generation of tools makes it easier to write code in your IDE.

But there’s still a bottleneck - it’s you, writing code, in your IDE.

It’s time to move past the IDE.

IDEs are built around files. As we do more and more work through agents, shouldn’t our tools be focused on agents?

You’ve probably noticed some of the most common tools looking less like IDEs and more like chat applications. The new Cursor Mac app and Cursor have started to center more around agents than editing files.

Augment Code has been cooking up something really incredible that reflects their vision for the future of software development. You’ve already read about how Augment’s context engine makes their tool uniquely useful in large codebases. So it shouldn’t surprise you that their new tool, Intent, is an awesome addition to this space.

Today’s post is generously sponsored by Augment Code, which also means I got early access to test out Intent. And it’s awesome.

Read on - I’ll cover what intent is, how it’s unique, and I’ll even show you how I make changes to my SaaS with it.

Try Intent

What is Intent?

Intent is Augment’s vision for what comes after the IDE.

I don’t have to tell you that developing software has become extremely scattered. When I try to do something at work, I’m bouncing between Jira, my IDE, a browser tab with the live site, a browser tab with my dev server, a couple of terminals, some LLM chats, and so on.

It’s a huge problem. Theo had a really good video complaining about some of these that resonated with me.

Intent takes this on with 3 big wins for you:

Agent orchestration

Agent orchestration is something that we’ve been talking a lot about lately. Software development is moving from tweaking code in files to orchestrating parallel agents across projects towards a product outcome. Intent helps you do this in an insane way, and I’ll show you later on.

Isolated workspace

The isolated workspace thing is huge for me. Having everything you need (agent chat, diff view, terminal, and test browser) in one place is starting to become a bare necessity. Intent does this well, and we’ll look through an example later in the article.

Living specs

Living specs are something that I’ve not seen done well with other agent-first tools, so I’m pumped that Augment got this right. Living specs help you work at a higher level of abstraction. I’ll show you what I mean in our demo.

Subscribe now

What makes Intent unique?

Beyond these superpowers, Intent has some attributes that make it really unique.

Intent is model-agnostic

I’ll be honest - I’m getting a little tired of AI models and AI tools being coupled. Claude models can be used in lots of tools, but obviously, Claude Code is pushed as the tool of choice. The same is true for Codex models - there’s a Codex CLI and app now!

Something uniquely interesting about Intent is that it’s model-agnostic. You can choose your own model. You can even choose your own agent with an existing subscription!

You shouldn’t have to change your entire tooling just to use the best model. Getting so glued to Claude Code was a mistake; it made my transition to try out the newest Codex models HARD. I was considering moving to OpenCode as a result, but Intent might be my new model-agnostic default.

The Augment context engine

The context engine is historically Augment’s biggest differentiator. It ingests your entire project and keeps a real-time semantic index. This means when you ask a question or generate code, Augment truly knows the surrounding context.

This is especially useful in big projects, and it really sets Intent apart from something like OpenCode. A multi-agent world needs good context. Augment helps you make sure your model actually gets it.

I have some more thoughts on context here:

Living specs

Traditional specs start to get out of date the second you ship something. Projects aren’t static, and your specs shouldn’t be either.

In Intent, when an agent completes work, the model updates the spec. When you want to change requirements, those updates propagate to all active agents.

Using Intent

Let’s get into building. You can download Intent and follow along if you like.

Try Intent

The onboarding for the product is really pleasant. You get to choose your agent.

Choosing Auggie gives you a great context engine, so it’s what I’ll do for this demo :)

I’d like to build a little distraction feature for my Deep Work Timer SaaS. Here’s the prompt I’ll start with:

I’d like to add a “distraction feature” to this deep work timer. I want users to be able to tap a button and have a quick field to enter a distracting thought they’d like to follow up on. This “distraction” would go into a list that is visible above the field they entered it into. The idea is that they can revisit that list when they’re done focusing.

I want it to be a simple and minimal design that follows the rest of the application design. I want it to be a little brain icon floating button on the bottom right next to the existing help/question button. Store the distraction items in local storage.

Right away, a Coordinator agent started to break down my spec into tasks and delegate it to implementors that can run in waves.

This initial spec is good, but it’s also easy to edit. You can describe edits or make them directly. I made some minor changes to be precise in this spec.

Then, I selected “Approve plan and start implementation”.

Once you’re comfortable with agentic tools, now is a great time to spin up a second agent in parallel. But for this example, we’ll stay focused and monotasking on our distraction feature.

I’m impressed that much of the implementation time is spent scanning the codebase for appropriate context. But not surprised, this is natural for the Augment context engine.

The coordinator agent delegates the implementation to its more specialized counterpart, the implementor agent.

After implementation, the coordinator delegated the work to check that the spec was actually complete to the verifier agent. This is a huge win for automatic subagents, something I think Claude Code is definitely lacking.

You can customize this to bring in your own specialist agents and control how they’re orchestrated. I think you’re going to have a lot of fun doing that.

Here’s the agent’s first shot at implementing my feature!

I’m really happy with Intent’s first pass at this. No notes! I had the agent push a PR, which I tested and immediately merged.

What do you think? Will Intent become part of your workflow?

Leave a comment

Each of these is progressively more useful than the last.

But I wasn’t super proud of any of them until recently.

Introducing Breathify

I’ve been getting into breathwork lately, and I wanted to put my own spin on some of the more popular breathwork apps. I built and shipped Breathify, faster than any mobile app I’ve ever shipped.

The app is minimal, with the intent of being maximally calming. It has a great onboarding, a couple core features, and customizable haptics.

If you want to see how I built it, there were a few newsletter editions that went out while I was building it:

AI Supremacy

Vibe coding a mobile app with Claude Opus 4.5

Good Morning…

Read more

4 months ago · 55 likes · 2 comments · Michael Spencer and Jeff Morhous

Interested in seeing what Opus 4.5 and I came up with? It’s on the app store!

Check out Breathify

The tools I used to build Breathify

Read more

Today’s post is real opinions from people who spend plenty of time shipping code and writing about the craft. I’m genuinely excited about this one because it gives you something I can’t: a bunch of fresh perspectives in one place.

AI tools for writing software are moving fast enough that a “best of” list would go stale basically the moment I hit publish. I’ve gone from Copilot, to Cursor, to Claude Code, and now Codex. All within the past 18 months.

The tool that makes you faster is the one that fits how you think, how you debug, how you review code, and how much control you want to keep while you work.

You’ll see a few names pop up again and again, especially Claude Code and Cursor. But what’s more interesting than the tools themselves is how differently people use them: some treat them like a pair programmer, some like a refactoring engine, some like an always-on reviewer. Read the quotes, steal the workflows, and pay attention to the patterns that match your style.

If you’re new here, 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

Now let’s get into it!

Gregor Ojstersek uses Cursor and Perplexity

from :

For coding, my main choice of an AI tool at this time is Cursor.

I tried all the most popular AI coding tools, and here is my reasoning for using it: I prefer to do prompting directly inside the IDE, rather than in a terminal or a separate app.

This provides a clear overview of the changes made when I use the agent mode, allowing me to review and make manual adjustments easily. It’s harder to do that, and also a worse experience imo, if you are using your terminal for prompting and then looking for changes in an IDE.

I still prefer using a UI like the Codex app, for example, than doing prompting directly in the terminal, just my preference.

For researching how to do something, I use Perplexity and ChatGPT. For deeper searches on how to do something, I’ll use Perplexity and quick questions, ChatGPT.

Logan Thorneloe uses 4 tools (!)

from :

This is a tough one. I'd say I primarily use ~4 tools, Claude Code, Gemini CLI, Qwen CLI, and Antigravity.

I prefer CLI agents because they not only code, but are really good computer control agents. They can pretty easily and intuitively help me write code, but also anything I can do from the terminal I can instruct them to do for me.

For example, I use CLI agents basically every time I code, but I also use them to write because I write in markdown. It was able to investigate and fix the problem for me. This lets them directly interact with what I'm doing, use web search to pull source, edit, review, etc.

I've also used CLI agents when setting up Linux desktops and I've accidentally ruined one of my settings that disabled the desktop UI. I use Gemini CLI at work and for personal use. I also use Claude Code to test something other than Gemini CLI and because I've found it to be the best way to code from my phone via the Claude app, which I've found myself doing a ton recently.

I use Qwen CLI when I don't have internet or anytime I want more control over how the model works and interacts with my code/documents or when I'm working with sensitive information.

I also use Antigravity as my primary IDE now and the agent has become my primary in-IDE editor. I'm a fan of the separate agent manager and the generous free quota. Let me know if you have any questions or want more info.

Share

Jenny Ouyang loves Cursor

from :

I've built 10+ production applications with Cursor — not prototypes, real tools processing thousands of API calls, managing databases, and generating revenue.

What makes it different is that it understands your entire project. Not just the code — my writing system, my content folders, my analysis scripts, everything becomes collectively accessible in one place.

The tool I debated most was Claude Code. They're both powerful, but Cursor won because of the visual interface. With Claude Code, you're working in the terminal — it's a black box where you can't always see what's actually happening across your files. Cursor lets me see exactly what it's doing, which files it's touching, and intercept at any step. That visibility changes how confidently you can build. Other platforms like Bolt and Lovable are great for quick prototypes, but when something breaks, you're stuck.

With Cursor, you own every file and can modify anything. It's less like coding and more like explaining your vision to a senior engineer who has perfect memory of your entire project.

Casandra Campbell uses v0

from :

Most of the time, I'm making simple software products like tools for my paid subscribers or lead magnets and landing pages for a funnel, so I usually turn to v0 by Vercel.

I find that v0 can create clean, simple, functional products very quickly with only a few prompts. From there, refining and deploying it is easy, and I appreciate how they handle versioning and environment variables to keep things as straightforward as possible.

Ilia uses Claude Code

from :

My current favorite tool for making software is Claude Code and the variations of it. By variations, I mean Claude Code in the dekstop app and Claude Cowork.

You don’t like the terminal look? Great, go to Claude Code in desktop. You don’t like that either and it’s too complex?

Not a problem, you can go into Claude Cowork (Claude Code’s easier version) and do your work there.

Claude tends to be #1 on their quality of models and Claude Code is a great way to get straight access to Claude without going through a middle man (Cursor, etc.).

The combination of Opus 4.6 in plan mode, custom agents, slash commands, .md files, can get you to your final result that you desire very fast. Another amazing thing about Claude is that Anthropic’s team keeps innovating and making it better, almost daily! With features like /insights, it can help you develop better worfklows, reduce errors, and improve the quality of your processes and products!

Ilia has written about Claude Code Skills for the newsletter, and I’m excited to have him back next month!

Karo uses Replit

from Product with Attitude:

Replit is strangely underused on Substack, and that still surprises me. I built stackshelf.app, attitudevault.dev, and some unglamorous but very useful admin tools with it.

I choose it for coding projects where UI matters a lot. It’s the best vibe coding tool I’ve tested, and has an unsettling habit of getting my requirements right the first time. Every time. It wasn’t always like this.

In early 2025, before they launched Agent 3, Replit would tell me it knew exactly what to do, and then do the opposite. You can read about it in I Broke Replit So You Don’t Have To. BUT! I haven’t seen that behavior in about five months. These days it gets the requirements, asks when it doesn’t, checks its own code, and even runs tests itself.

You can literally watch it click through your app on screen, which is... oddly satisfying. That said, like most vibe coding tools, Replit is opinionated. It has strong feelings about certain frameworks and fewer feelings about others. Which is why you need to show up with more attitude than it has.

Christian Pean, MD, MS uses Claude and Lovable

from :

This combination is fantastic for non-technical users of AI tools—Claude serves as an iterative brainstorming and prototyping partner, while Lovable brings sites to life.

I've built searchable databases for health policy requirements, internal tools like specialized CRMs that eliminated our dependency on Notion and HubSpot (saving significant time on data entry), and meeting operating systems to streamline workflows.

As CEO of RevelAi Health—a company building AI-powered care coordination for healthcare—we use Claude Code extensively to develop HIPAA-compliant software and analyze claims data in privacy-preserving ways. "Claude has become essential infrastructure for both building our product and understanding our customers' needs."

The combination of conversational AI with rapid prototyping tools has fundamentally changed how quickly we can move from concept to functional system.

I also run the Techy Surgeon newsletter, where I explore clinical AI implementation for healthcare executives—and honestly, most of my content workflow now runs through Claude for research synthesis, evidence-based analysis, and translating complex policy into actionable insights.

Subscribe now

Wyndo uses Cursor

from :

I use Cursor all the time now. Even though I’m not a tech person, the vibe-coding experience makes me more comfortable navigating this tool.

I like Cursor because I have more control over my code and how I want the agent to behave. A lot of customization options are available: sub-agents, MCPs, rules, AI models, etc.

The ability to play around with context files is also interesting. Now Cursor has Debug Mode and browser access, so it can understand the code on a website for further UI improvements.

Composer 1.5, the new model, also helps me a lot in speeding up my process for low-level tasks such as updating UI or fixing minor bugs. The speed is on a whole different level. Cursor is also able to connect with the ‎claude MD file, which makes it more powerful at understanding file context and patterns.

Orel uses Cursor:

from :

My favorite tool for making software is Cursor because it lets me choose any model that I want to use to generate code. The completion is quick and awesome. These two, for any new feature that I want to add or a new product that I want to build or anything like that, I just use Cursor.

I build an elaborate PDF prompt with Claude, then I upload it to Cursor, and then it builds everything. Most of the time it's just one shot and it's ready. Yeah, freaking love it. That's what I use for AI too.

Honestly, I only tried Github Copilot back in the day, like one or two years ago, and it was awful. Everything about it was just awful. I didn't like it, and when I switched to Cursor, it was just a whole new world. I used a lot of AI tools. I used Cursor. I use Claude. I also use Bolt to build a layout or the UI of anything that I want to add, just to have an idea of something that looks good with good UX.

Bolt is my favorite so far. I tried LavaBolt; it's just a bit slow and feels a bit clunky; don't like it. I tried Bates44; I don't like it as well. I tried V0, and that's cool, but I didn't use it for a while.

Michael Jovanovich uses Claude Code

from :

I think the future of non-safety-critical software is this sort of low-code, no-code environment where you express your ideas and design choices to AI systems that produce a product you then give feedback on and iterate.

The syntax, functions, and so on will become not unlike the 0s and 1s underlying code today: there in the background, but not something you think about outside of edge cases or really advanced, safety-critical work.

The much bigger focus will be the grand vision of your design and what's actually useful to people about it. I find Claude models more enjoyable to collaborate with, brainstorming, solving problems together, where other models feel more like task-doers than collaborators.

For well-defined, commonplace work like building a website, things abundantly represented in any company's training data, it's pretty much a wash between leading models.

But when it comes to hard stuff, stuff that's never been done before, like the novel ML experiments I've been working on. I would way rather work with Claude to figure out what should be done. There's something hard to describe about Claude models that feels genuinely above the others when you're coding into unknown territory.

Kamil Banc uses Claude Code

from :

I absolutely prefer using Claude Code inside a terminal for several reasons. I suppose I enjoy the way it encourages critical thinking and learning, providing minimal handholding. I need to actively engage and figure things out myself. However, I can always ask it questions if I encounter any difficulties. I primarily use Claude Code through voice dictation.

He’s also created Claudia, a terminal-based AI assistant. I love to see real projects people are shipping with AI!

Daria Cupareanu uses Lovable

from :

I've tried a bunch of tools throughout time - Replit, Bolt, Emergent, HeyBoss - but Lovable is the one I keep coming back to.

Least amount of friction by far and I've been able to build even complex platforms with a lot of moving parts. Part of it is familiarity at this point, but it consistently delivers where others gave me headaches.

Honorable mention though: I recently experimented building with Claude Code by trying to recreate a better version of a product my friend and I built a year ago, which involved processing a huge database with hundreds of thousands of records. That project took us a couple of weeks back then. Now, Claude Code did it in 20 minutes and created the platform instantly. Safe to say I might become obsessed with Claude Code.

But since I've only been building with it for a few weeks, Lovable still gets the official answer.

Barret uses Claude Code

from :

I jumped ship from Codex to Claude Code and haven't looked back. I use for my consulting work, my side projects, all of it Two things sold it for me.

The biggest was /plan mode. I can sketch out the full architecture of a component, and give it enough context of the overarching vision, before any code gets written.

I don't see that as vibe coding, but I have a lot of domain knowledge, so I'm able to steer it really well. Second, and it's minor, but I can actually 'talk' to it. Give it my thoughts on pro/cons about architecture decisions, debate approaches, figure out the right pattern for the problem.

It's like having another senior engineer who doesn't get tired and doesn't have an ego ( BIG FKN PLUS lol ).

Short version: I use it to think with me, not for me. That's the difference. I had very similar experiences with Codex-CLI but something about Claude made it more 'enjoyable' for me. I've not been able to put my finger on it, tbh.

Barret has actually written about building with AI for the newsletter:

I have used all of these tools, and it’s exciting to see how each person’s workflow and priorities shape their tool preferences! I’d encourage you to check out each Substack linked above - there’s some incredible insight being shared on each one!

And if you’re curious about using AI tools to write software, you’ll probably like The AI-Augmented Engineer. Join us!

Subscribe now

Unlike a generic AI chat that knows a bit about everything, NotebookLM’s knowledge is grounded in the specific content you give it, which means it provides responses based on those trusted sources rather than random internet data.

This design greatly reduces the hallucinations (fabricated facts) that AI models sometimes produce, because NotebookLM won’t make up answers out of thin air – it will tell you what’s in your materials, often with references to the exact source.

In this NotebookLM tutorial, we’ll cover:

• How to upload information

• How to get information

• Using NotebookLM

• Making quizzes

• Making infographics

• Making a slide deck

• Referencing a notebook in Gemini

Let’s get started by adding some information to a new notebook.

How to upload information into NotebookLM

NotebookLM isn’t much use without sources, and there are a few ways to set up your sources. I’m in the middle of studying for the Azure AI-900 certification right now, so we can use this course as an example notebook.

I took notes from a course in markdown, so uploading the notes is an easy copy and paste.

How to get information into NotebookLM with research

You can also use fast research or deep research to get sources into your NotebookLM notebook. This will use Gemini to do a web crawl and add relevant sources from the web into your notebook.

Once you’re happy with your sources, it’s time to get to learning!

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 out Intent

Using NotebookLM for audio overviews

No good NotebookLM tutorial would be complete without AI overviews. AI overviews are probably the most popular (and useful) feature of NotebookLM.

Imagine you could listen to a podcast directly about a topic you were learning, exclusively with materials you’re studying from.

That’s what audio overviews do for you.

You can generate audio files that are “fake podcasts” from your notebook. You can specify the format of the “podcast”, then use the web or mobile app to listen to it.

This has been game-changing for my graduate school studies. It’s hard to squeeze in studies after work, and audio overviews help me repurpose time driving or exercising.

Making quizzes with NotebookLM

One of the best ways to learn something is to quiz yourself. Active recall is a powerful rule in education, and many people swear by creating and taking quizzes of their study material.

In fact, starting to do this (manually) in undergrad was a huge point of leverage for me. I can’t tell you how many quizzes and study guides I made over those years.

NotebookLM will generate quizzes from your source material, giving you the chance to take quizzes you haven’t seen before, created directly from your notes and sources.

Making infographics with NotebookLM

This might be less helpful for learning than quizzes, but it’s really helpful for presenting information from your source material.

NotebookLM infograhics use Nano Banana (also from Google) to generate incredible info-graphics from your notebook.

You can choose your orientation, level of detail, and even add some custom prompt instructions to guide the style.

Subscribe now

Making a slide deck with NotebookLM

Google built on the infographic feature to bring us the ability to create entire slide decks.

The feature does not offer a ton of customization, which ironically makes it super easy to use.

This is a cool way to get a slide show set up very quickly, but infographics in these decks seem to be prone to hallucination at a higher rate than general chat tools, so carefully check your output before giving a big talk!

Referencing a notebook in Gemini

The last thing that’s worth mentioning in this NotebookLM tutorial is Gemini.

NotebookLM is powered by Gemini behind the scenes, but did you know you can also power Gemini with your NotebookLM notebooks?

You can add any notebook to your Gemini chat prompt to have the model reach directly into your sources for context.

This is a step in the right direction for personal intelligence, where you can chat with your learning materials.

If you work any kind of job where you use your brain, you owe it to yourself to try NotebookLM. Comment below if you have any tips to share!

Leave a comment

I don’t think it’s in the terminal either.

Fortunately, OpenAI agrees.

Today, I’ll show you what the new Codex app is, how it differs from other Codex products, and how you can use it to build a sweet SaaS landng page.

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

Wait, doesn’t Codex already exist?

Yah, it does. Like 4 times over.

OpenAI appends Codex onto models, like the GPT-5.3-Codex that just got released. These models have been fine-tuned for software engineering tasks, and they’re really good at long-running agentic workflows.

OpenAI also published Codex web product a while back, which was a remote agent orchestrator. I tried it, and I hated it, so I never tried it again.

Then they shipped Codex CLI, which is really good. You can read more about that here:

But Codex CLI wasn’t great - it was missing some core features that I loved in Claude Code, so I never moved over.

But the Codex app is another story.

Introducing OpenAI’s Codex app

You can visit the Codex website and install the app quickly. You can also use your ChatGPT account, which comes with really generous limits (for a while at least).

When you notice it, you’ll notice it looks like a mix between a chat app and Cursor.

It has some really incredible features that I’m loving:

• A diff view that makes it really easy to see what’s changed

• Awesome support for parallel agents

• Worktrees so your parallel agents don’t break each other’s work

• Skills (that are easier to use than Claude Code Skills)

• Built-in browser

• A button to open changes in your preferred IDE

The app is built completely around the thesis that software development is going to change quickly. The workflow this app supports is one where you kick off new agents for tasks on one or more projects, and those agents work in parallel.

The app supports you checking in on each agent and interrupting them if they get off-course.

I think this is probably the most correct view of all the AI tools for developers. I think we’ll see Cursor move this way, and I know we’ll see a lot of cool tools on the market that also take this view. (I’m early-access testing one now, can’t wait to share with you all).

So are you ready to try building something with Codex? Let’s get started!

First, will you help me improve the newsletter by answering this quick poll?

Building a landing page with Codex

The growth of this newsletter has been overwhelming. As it’s grown, I’ve connected with some really awesome newsletter operators on Substack. I had an idea for a tool I think might help some of us, especially writers focused on curation.

So let’s prompt Codex for an app landing page and waitlist lead capture.

Read more

We’ve written a lot on the newsletter about skills for Claude Code. They’re an incredible way to bundle up knowledge for an LLM.

They’ve completely eliminated any need for me to copy/paste prompts into Claude Code.

But what about slash commands? We wrote about those a while back too! Are they still a thing?

In short, not really.

In today’s newsletter, we’ll explain the merge of slash commands and skills, and how to create a new skill for a common and repeatable workflow.

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

Read more

The tech job market is in a pretty bad state, with waves of layoffs and hiring freezes that show no sign of getting better.

2021-2022 saw an insanely good (for candidates) job market.

Then, there was an incredible amount downsizings around 2022–2024. 2025 saw nearly 245,000 tech jobs cut worldwide, the most severe contraction in years, and early 2026 has seemingly brought more of the same.

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

Amazon confirmed 16,000 additional corporate job cuts in late January, bringing its total to 30,000 roles eliminated since October (roughly 10% of Amazon’s corporate workforce). This marks the largest headcount reduction in Amazon’s history, surpassing the 27,000 jobs cut during the 2022–23 pullback. Amazon’s CEO Andy Jassy cited the need to “reduce layers and remove bureaucracy,” after the company over-expanded during the pandemic.

Intel is undertaking a massive restructuring that will eliminate about 24,000 positions (around 20% of its workforce). New leadership initiated these cuts as part of a multi-year effort to regain competitiveness in semiconductors and redirect resources toward advanced chip designs and AI-centric initiatives. Intel is urgently pivoting after losing ground to TSMC and NVIDIA in the race for AI hardware.

UPS announced a historic reduction of 48,000 jobs, driven largely by “automation and efficiency improvements” in its delivery network. UPS is aggressively deploying robots and AI across warehouses and hubs. Even logistics and transportation companies are shedding workers as they digitize and respond to declining shipping volumes with automated systems.

Many executives explicitly cite artificial intelligence and automation as drivers of these job cuts. Sometimes they’re saying this to cover for declining growth, but sometimes it’s honesty. Amazon’s HR head Beth Galetti acknowledged that AI-powered tools are helping eliminate bureaucracy and enabling higher productivity with fewer people. Andy Jassy even stated that the rise of AI means certain tasks can be automated, “leading to corporate job losses” as a direct consequence.

The AI Agent for production-grade codebases

Today’s newsletter is sponsored by Augment Code!

Augment Code’s powerful AI coding agent and industry-leading context engine meet professional software developers exactly where they are, delivering production-grade features and deep context into even the largest and gnarliest codebases.

With Augment Code you can:

• Index and navigate millions of lines of code

• Get instant answers about any part of your codebase

• Automate processes across your entire development stack

Build with the AI agent that gets you, your team, and your codebase

These recent cuts aren’t all “we’re replacing humans with AI”, but they’re big effects in an already competitive market.

If you’re a software engineer or work in adjacent roles, you’re probably wondering how you can add some job security.

Make embracing AI a priority

For software engineers, these trends carry a clear message. In a volatile market where traditional job security is eroding, the best defense is to become highly proficient in AI tools and workflows.

It’s one of the reasons I got interested in working with AI. And it’s the reason I started this newsletter.

The roles being spared (or newly created) in many companies are those that build, manage, or heavily utilize AI. Conversely, the roles most at risk are those that can be replaced or greatly augmented by AI.

Practically speaking, mastering AI-powered tools is now a must.

Some companies, like Shopify, Meta, and Zillow, are explicitly measuring for this in performance reviews and hiring.

The good news is, a new generation of developer-focused AI products has emerged, and early adopters rave about the results. AI pair-programming assistants, intelligent code editors, and AI research aides are proving to be game-changers for those who integrate them into daily work.

Longtime readers of the newsletter know that tools like Claude Code and Cursor are changing the way we work altogether.

These tools are quickly becoming essential parts of the programmer’s toolkit. The engineers who are “winning” in this climate have made AI a force multiplier. Notably, they’re not using it to replace their own thinking.

If you outsource your work as an employee to AI and use it as an excuse to work less, you’re going to get outpaced by peers who use it to produce more.

Those who leverage AI are far more productive and adaptable, making themselves indispensable even as others are automated away.

To be concrete, now is the time to learn and embrace high-leverage AI tools in your engineering workflow.

My guess is that at some point, AI usage will become normal in most development shops. For a brief window in time, you can have an edge.

Those who make this transition will find no shortage of opportunities; even amid the cutbacks, companies are hungry for talent that can drive their AI ambitions forward.

It’s a challenging time, no doubt. Yet times of rapid change always are. The writing is on the wall in every layoff memo and earnings call. AI proficiency is now critical. The tech job market may not be getting better in the traditional sense, but for those willing to ride the AI wave, new doors are opening. The tools are here, the paradigm shift is happening.

The question is, are you ready to embrace it?

Leave a comment