DEV Community: Agnel Nieves

Block Put Its Agents in the Team Chat. Buzz Is an Audit Log Before It Is a Slack Killer.

Agnel Nieves — Fri, 07 Aug 2026 14:50:27 +0000

The most revealing line in Block's Buzz repository is written for employees.

Do not use the public build, it says. Download the internal version from squareup/buzz-releases. That build already points at Block's relay and agent provider.

Block is using a separate, preconfigured version of its open-source workspace inside the company. That is a stronger case study than the launch claim that Buzz might replace Slack and GitHub. It tells us the product has crossed the line from demo to working infrastructure for at least one team, while stopping well short of proving an enterprise migration.

Buzz launched publicly on July 21. It puts people and AI agents in the same channels, gives each agent a cryptographic identity, and records messages, code patches, approvals, and workflow events in one signed log.

The Slack comparison explains the interface. The audit log explains the product.

What Block built

Buzz is a self-hostable workspace built on the Nostr protocol. A workspace maps to a relay URL. Every message, reaction, workflow step, review approval, and Git event becomes a signed Nostr event stored by that relay.

Humans and agents use the same identity shape. Each participant has a public key, and every event carries a signature. Agents can join channels, open repositories, send patches, review code, run workflows, edit canvases, and call other agents.

The relay remains the source of truth. Postgres stores events, channels, workflows, tokens, and the audit chain. Redis handles presence and fan-out. The desktop application uses Tauri and React. buzz-cli gives agents a JSON-in, JSON-out interface. Agent Client Protocol (ACP) adapters connect Claude Code, Codex, Goose, and other compatible harnesses.

Here is the practical difference:

Existing team stack	Buzz
A Slack bot posts under an integration account	An agent joins as a named member with its own key
The agent works in a private terminal session	Its channel, tool calls, patches, and replies can share one record
GitHub holds the patch while Slack holds the decision	Git events and conversation use the same event log
Bot permissions live across OAuth apps and service tokens	Relay membership, channel membership, and agent identity sit in one system
Search reconstructs a decision from several products	Search can query the conversation, patch, workflow, and approval together

Buzz does not make the underlying model safer. It makes authorship and history easier to inspect.

Case one: Block has an internal relay

The public README gives Block employees their own installation path. The internal build comes wired to the company relay and agent provider. Jack Dorsey's launch post said the project was built to reduce Block's dependence on Slack and GitHub.

Those two facts support a careful conclusion. Block has deployed Buzz internally and wants it to absorb work now split across incumbent tools.

They do not tell us how many employees use it, how much traffic it carries, or whether any team has removed Slack or GitHub. Block has published no migration percentage, retention number, or incident record.

The internal build still matters. Block is testing the identity model against its own agent work instead of asking open-source users to discover every rough edge first.

The release notes focus on problems active teams encounter. Version 0.5.0 shipped on July 28 with use-limited invite links, a generic ACP runtime seam for bringing another harness, agent display names as Git authors, a lower default parallel-agent limit, and a security update for a Nostr denial-of-service advisory.

Identity, invitations, Git attribution, runtime compatibility, and resource limits are not landing-page features. They are the problems a working room produces.

Case two: Jupiter Broadcasting opened a community

Jupiter Broadcasting linked a live Buzz community from its July 26 episode of LINUX Unplugged. The episode page also points to external-agent integration work for Hermes, a multi-agent system the network has been testing.

This is an early outside deployment, not a customer success story. Jupiter already runs a technical community across several open tools, which makes it unusually tolerant of beta infrastructure. Its use still tests something Block cannot prove alone: whether a community that values self-hosting will move conversation and agents into the same room.

The linked work is specific. A feature request asks Buzz to support external agent systems that do not speak ACP. Related pull requests add Hermes runtime discovery and document the host integration.

That is open-source adoption in its least polished form. A real community wants to bring an existing agent stack, finds the protocol seam too narrow, and contributes the missing adapter.

Case three: A real permissions gap appeared in two days

On July 23, an operator filed a request for channel-scoped guest access. They run a membership-gated Buzz community with internal channels and agents. They want customers to enter one public support channel without gaining access to anything else.

As of July 29, Buzz cannot express that policy.

The relay can require membership for everyone or accept authenticated identities more broadly. Channel visibility applies after relay admission. The operator wants a guest to read and write in #support while blocking every other channel, repository, workflow, direct message, and administration surface.

This issue is the best early case study in the repository because it shows the product working and the authorization model failing at the same time.

Cryptographic identity answers who signed an event. It does not automatically answer which event that identity should be allowed to publish. The operator wrote out the missing contract in detail: one allowlisted channel, text-only at first, normal moderation and rate limits, agents allowed to answer, and no broader relay membership.

That request is more useful than another screenshot of an agent posting in chat. It names the boundary a production community needs.

The product claim that holds up

Block says agents should be members instead of bots. That claim holds up in the architecture.

Buzz's agent runtime uses two small Rust binaries. buzz-agent speaks ACP, calls a model, and manages sessions. buzz-dev-mcp gives the agent a shell and file editor through the Model Context Protocol (MCP). The pieces communicate through published protocols, so teams can swap the model provider or agent harness without rebuilding the workspace.

Each community keeps its own profiles, presence, direct messages, memories, jobs, memberships, and audit trail. The same public key can join another community, but the agent's state does not silently follow it across hosts.

Portable identity does not become portable access by accident, which is the safer boundary.

The Slack-killer claim is early

Buzz has desktop applications, chat, channels, threads, direct messages, canvases, media, search, Git events, workflows, and an agent-first command-line interface. It also says plainly that it is unfinished.

As of July 29, the public roadmap still lists workflow approval gates and parts of the mobile experience as active work. Hosted relays are free during beta, with no published enterprise price or final usage limits. Slack Connect, mature retention controls, enterprise discovery, identity-provider integration, and years of administration tooling do not disappear because Nostr events have signatures.

The self-hosting story carries work too. A production relay brings Postgres, Redis, object storage, backups, updates, key recovery, monitoring, and incident response. Teams gain control because they accept the operating burden.

Buzz may reduce seven tabs to one substrate. It also puts seven products' worth of responsibility onto that substrate.

Who should pilot it

A small engineering team or open-source community should run a pilot when agents already perform real work and the private agent conversation keeps vanishing from the team record.

Use one repository, two agents, and one workflow. Give the research agent read-only access. Give the coding agent a disposable branch. Require a human reaction before a workflow can publish or merge. Measure how often teammates can reconstruct a decision from Buzz alone and how often they return to Slack or GitHub for missing context.

Keep the incumbent tools during the pilot. Buzz has not earned a cutover.

Teams with regulated data, complex guest access, large Slack Connect networks, or mature GitHub governance should wait. The channel-scoped support issue shows why. Signed events are valuable, but authorization still needs the boring policy work.

Verdict

Buzz has the most coherent method I have seen for tying agent work to an identity, an authority, a room, and a body of evidence.

Block's internal build proves the company is willing to use its answer. Jupiter Broadcasting proves an outside community can extend it. The support-channel request proves the permissions model still has sharp edges.

Pilot Buzz as an agent workspace. Do not call it a Slack and GitHub replacement until a team publishes the migration numbers and the authorization gaps close.

Sources

Pieter Levels Paid $19 for Kimi K3. It Cleared the To-Do List Claude Would Not Touch.

Agnel Nieves — Tue, 04 Aug 2026 16:16:29 +0000

Pieter Levels wanted to install Yahoo! Messenger from 2003 inside a Windows XP desktop running in the browser. Claude Code kept treating the emulator like a cybersecurity problem.

He spent two weeks bouncing between model fallbacks and safety blocks. Then he opened X and asked how to run Kimi K3 through a coding agent. The answer changed his afternoon.

Levels installed OpenCode, connected it directly to Kimi, paid $19 for a membership, switched the agent into Build mode, and let it work through the simulator's to-do list. His report after the switch was short: K3 was "absolutely hammering through" the work.

This is a good founder case study because the task stayed recognizable. A browser emulator was stuck. The founder changed the stack. Work resumed.

It is also a messy model comparison, which is where the useful part begins.

The project K3 walked into

The Windows XP simulator sits at pieter.com. It is the kind of project Levels keeps returning to: old software, browser emulation, a long list of rough edges, and no client waiting for a compliance memo.

He had already been using Claude Code heavily. In June, he wrote that he had coded almost entirely on a virtual private server with Claude Code for nearly a year. The switch did not come from a tourist opening two chat tabs and asking for a snake game. It came from a paying power user who had run into the same refusal pattern for days.

Levels described the immediate problem in public:

"Claude Code couldn't do this for 2 weeks."

His complaint centered on safety fallbacks. The model treated requests around the Windows XP environment as risky even though Levels was working on a hobby project he controlled.

The task context changes how I read the refusal. A guardrail can be reasonable in one environment and maddening in another. Levels was not asking an agent to probe a bank. He was trying to make Yahoo! Messenger work in a browser toy.

He changed four variables, not one

The viral version of this story is Kimi K3 beat Claude. The public record supports a narrower finding.

Layer	Before	After
Model	Claude models, with reported safety fallbacks	Kimi K3
Harness	Claude Code	OpenCode
Provider path	Anthropic through Claude Code	Direct Kimi connection after an OpenRouter rate limit
Permissions	Claude's policy and tool gates	OpenCode Build mode with permission bypass enabled
Task	Windows XP simulator to-do list	The same project and backlog

K3 deserves credit for completing work that had stalled. Levels also removed several sources of friction around the model.

He published the setup on July 17. Install OpenCode. Create a Kimi account. Pay $19. Get an API key. Connect Kimi Code inside OpenCode. Switch to Build mode. His instructions also recommend bypassing permissions, which he already did in Claude Code.

That final setting makes the run faster and less comparable. A model with broad shell access can finish jobs that a more constrained agent pauses to confirm. It can also damage more when it guesses wrong.

Levels made a rational trade for a hobby emulator. I would not copy that trade onto a production database.

Why K3 fit this job

Moonshot AI released Kimi K3 on July 16, one day before Levels published his switch. The model has 2.8 trillion total parameters in a mixture-of-experts architecture, with 104 billion activated for each token. It accepts a one-million-token context and handles text, images, and video.

The specifications matter less here than the training target. Moonshot built K3 for long coding sessions, large repositories, terminal tools, and visual feedback loops. A browser operating-system simulator touches all four.

Moonshot's own technical post says an early K3 build handled most of the team's kernel-optimization work late in development. The company also reports a 48-hour autonomous chip-design run and a compiler project built from scratch. Those are vendor case studies, so I treat the measurements as claims until independent teams reproduce them. They still show what Moonshot tuned the model to attempt.

Levels supplied an outside example with a public project and a named workflow. On the same day, he also published a macOS 27 browser interface created with K3. That does not prove the model wins every frontend task. It does show the visual coding loop was more than a benchmark row.

The cost moved from abstract to $19

Levels first tried OpenRouter and hit an upstream rate limit. He then went straight to Kimi, bought the $19 membership, and used the provider's API key with OpenCode.

Moonshot prices the K3 API separately at $0.30 per million cache-hit input tokens, $3 per million cache-miss input tokens, and $15 per million output tokens. The company says coding workloads on its official API exceed a 90 percent cache-hit rate.

That is vendor-reported cache performance. Your bill depends on the harness, prompt reuse, context size, and how often the agent rewrites its own plan. K3 always thinks, and long autonomous runs can burn output tokens quickly.

The relevant founder number remains $19. That was cheap enough for Levels to stop arguing with his old setup and try a new route.

Where the case study gets uncomfortable

K3 has its own failure modes. Moonshot lists three in the release notes.

First, the model expects preserved thinking history. A harness that drops earlier reasoning, or a mid-session model swap, can make quality unstable. Moonshot recommends starting K3 in a compatible harness instead of dropping it into a conversation another model began.

Second, the model can act too aggressively. Moonshot says K3 may make unexpected decisions when intent is ambiguous. The company recommends explicit constraints in the system prompt or AGENTS.md.

Third, Moonshot concedes that the overall user experience still trails the strongest proprietary models. A public Kimi Code issue filed after launch also reports the terminal interface hanging during a trivial prompt at maximum effort. The failure surface changed with the model.

Levels solved one kind of agent friction by choosing a model trained to keep going and a harness configured to let it. The same combination can turn a vague instruction into a long, expensive mistake.

What I would copy from the switch

I would copy the routing decision and leave the permission bypass behind.

When a coding agent refuses a legitimate task twice, write down the task, the exact refusal, the branch state, and the acceptance test. Start a fresh session in a second harness with a second model. Give it the same repository and the same test. Compare the completed diff, elapsed time, tool calls, and regressions.

Do not continue the old conversation after the switch. K3's own documentation warns against that path.

Keep the second agent inside a disposable branch and a scoped environment. Levels can rebuild a browser simulator when an agent gets inventive. Your billing system is less funny.

The founder lesson

Levels did not wait for a benchmark committee. He had a blocked task, spent $19, and changed the route.

The result is strong evidence that Kimi K3 belongs in the coding-agent rotation for long, visual, tool-heavy work. It is weak evidence that K3 is categorically better than Claude because the harness, provider, and permissions changed with the model.

The evidence is enough for a useful operator story: a stuck job, a visible change, and a result someone else can test.

Run K3 on a fresh branch. Keep the acceptance test fixed. Keep the permissions narrower than Pieter Levels did.

Sources

He Built an AI Headshot Empire Solo. The Product Was Boring on Purpose.

Agnel Nieves — Sun, 02 Aug 2026 14:48:54 +0000

The first thing people tell you about Danny Postma is a number. Sometimes it is the seven-figure sale of Headlime. Sometimes it is the "$300K a month" line that gets attached to HeadshotPro in every indie-hacker roundup. Both numbers float around the internet like they are the point.

I went looking for the Tuesday afternoon underneath them. What he built when the viral week ended. What he refused to build. Where the revenue actually comes from when the feed moves on.

The setup

Postma is Dutch, started young, and was not a pure engineer origin story. Landingfolio, a WordPress gallery of landing-page designs, came first when he was freelancing conversion work and needed references. Monetization was weak. The pattern that stuck was different: find a sharp job people already pay for, ship a thin product, tell the truth in public, and let distribution compound.

Headlime was the first real AI score. He had headline formulas in a book. He turned them into software. Then GPT-3 arrived and he got into an early access cohort, one of the first people wiring that model into a production copy tool alongside the early Jasper and Copy.ai wave. Public accounts of the trajectory put Headlime at roughly $1K MRR in December 2020, about $20K MRR by February 2021, and a seven-figure sale to the Jasper orbit not long after. Eight months, more or less, from product to exit.

That is the clean legend. The next chapter is the one operators should actually study.

The moment something worked, and then did not

When Stable Diffusion hit, Postma moved again. ProfilePicture.AI went out in about thirty hours. Six-figure sales in a week, per his own public telling and the interviews that followed. Fun avatars. Feed fuel. Then the curve bent. Novelty faded. Lensa-style apps ate attention. Sales cooled.

Hold on. Most founders would either double down on virality or quit the category. He listened to what people were actually asking for in the replies and support threads: not a party trick profile pic. A professional headshot. The thing you need for LinkedIn when you will not book a photographer.

He launched HeadshotPro (and, in parallel, Deep Agency, an AI "modeling agency" experiment). Deep Agency got press. HeadshotPro got the money. That split is the whole piece if you are paying attention. Hype and cash are different instruments.

The boring product

HeadshotPro is intentionally narrow. Professional headshots. Not dating packs, not meme styles, not every horizontal the competitors ship to chase App Store screenshots. Pricing, as listed publicly for long stretches, has lived in one-time packages roughly in the $29 / $39 / $59 band for batches of images, not a pure seat subscription. Refunds for unhappy customers are part of the trust pitch. The site claims on the order of hundreds of thousands of customers and tens of millions of headshots generated. Treat marketing totals as marketing totals. The direction is still clear: this is a volume utility, not a toy.

The quality claim he has repeated in interviews is the opposite of "we wrapped open source and shipped." Custom models, long pipeline work, a year of tuning toward photos that do not immediately read as synthetic. Whether you buy the "indistinguishable" language or not, the strategy is coherent: win on the job people are embarrassed to get wrong, not on feature count.

The growth engine nobody screenshots

Launch week is not why HeadshotPro kept showing up.

SEO is. Indie Hackers writeups of his approach describe programmatic pages for city and long-tail headshot queries ("professional headshots in [city]"), plus ordinary blog content, aimed at keywords with enough volume and low enough difficulty to rank without a content army. Product Hunt launches were framed, in his own comments, less as pure user acquisition and more as backlink machines: even a mediocre ranking still throws domain authority around the web. When other apps go viral for AI headshots, search interest spikes, and the site already sitting on the term catches the overflow. He has described weeks where a competitor's virality tripled his sales because he owned the search intent.

That is not a 24-hour story. That is a six-month compounding story. It also means the copyable lesson is closer to "pick a monetizable search job and build plumbing for it" than "tweet a demo."

Pieter Levels retweeting early posts is part of the lore. It is also not a strategy you can purchase. What you can copy is the public logging, the willingness to kill the press-magnet product when the sales-magnet product is obvious, and the patience for SEO timelines that do not fit a hackathon video.

The asterisks

Here is where I get careful, because the internet is not.

The "$300K MRR" figure appears constantly in secondary writeups. HeadshotPro's public pricing has often been one-time packages, not classic monthly seats, and Postma has talked in later commentary about subscription mechanics being a trap for certain product shapes. Some databases show much smaller annualized snapshots for single years. Build-in-public numbers move. Portfolio revenue gets collapsed into one headline. I am not going to pretend a blogger's roundup is an audited P&L. What I trust more is the pattern across years: early GPT product sold for seven figures, AI image products that repeatedly printed meaningful cash, a holding company (Postcrafts) still owning HeadshotPro rather than flipping it on the first offer, and a slow admission that hiring help was necessary even for someone who marketed the solo myth.

He has said he should have built a team earlier. That sentence is worth more than another revenue screenshot. The lonely version of the empire does not scale quality pipelines forever. Compute bills do not care about your personal brand.

Competition is permanent. Every model release births ten headshot clones. His answer has been focus and distribution infrastructure, not feature parity with every clone.

The verdict

If you only remember the exit, you will try to time the next GPT wrapper. If you only remember the $300K line, you will argue about someone else's spreadsheet.

The useful story is narrower. Postma keeps winning the same way: enter a technology wave early enough to matter, ship something people already budget for, follow sales rather than press, and install boring acquisition (SEO, refunds, clear packaging) that still works when the feed is bored. HeadshotPro is not clever because it is AI. It is clever because professional headshots were a real purchase before diffusion models existed, and he made the purchase faster and cheaper without turning the product into a carnival.

The product was boring on purpose. That is the part worth stealing.

Sources

- Danny Postma on X

Your Brand Is Probably Wrong in ChatGPT. Here Is the 90-Minute Audit.

Agnel Nieves — Sat, 01 Aug 2026 14:46:33 +0000

This post is about auditing how answer engines currently represent your brand. It is not about rewriting your entire site in one weekend. By the end you will have a one-page gap matrix and a fix order you can hand to a founder without a 40-slide deck.

I keep meeting teams who shipped schema, refreshed the homepage, and still have no idea what ChatGPT says when a buyer asks "what does [company] do" or "best [category] tools for [job]."

You cannot fix what you have not queried.

What you need before you start

90 uninterrupted minutes
A spreadsheet with five columns: Query, Engine, What it said, Gap type, Fix owner
Four engines if you can: ChatGPT (with search/browsing if available), Claude, Perplexity, Google AI Overview or the AI Mode you actually see in your market
A human who knows the product well enough to spot a wrong pricing tier

Incognito or a clean workspace helps. Your logged-in personalization is not your buyer's world.

The query set (run all of them)

Numbered on purpose. Do these in order.

"What is [Brand]?"
"What does [Brand] do?"
"Who is [Brand] for?"
"How much does [Brand] cost?"
"Best [category] tools for [primary job]"
"[Brand] vs [Competitor A]"
"[Brand] vs [Competitor B]"
"Alternatives to [Brand]"
"Is [Brand] legit / trustworthy?"
"Recent news about [Brand]"
"[Primary product] tutorial" or "how to get started with [Brand]"
A category question that should include you but never says your name out loud, phrased the way a buyer would

If you sell in multiple segments, duplicate 5 and 12 per segment. Do not improvise mid-audit. Improvisation is how you cherry-pick good answers.

The gap matrix

For each answer, tag one primary gap:

Tag	Meaning	Typical fix
Missing	You should appear; you do not	Category proof, third-party mentions, clearer owned definition
Wrong	Invented feature, bad category, dead product name	Correct owned canon + earned corrections
Outdated	True last year, false now	Dated changelog, pressable update, refresh partners
Competitor-owned	Competitor is the default example in your category	Comparison pages are not enough; need independent cites
OK	Accurate enough to ship	Monitor quarterly

Caption for your screenshot folder: query, engine, date, gap tag. The caption is the section summary when you report up.

What the results usually look like

Patterns from client audits, not a claim about your brand specifically:

Query 1–3 are often "OK-ish" if you have any web presence. Soft wrong more than missing.
Query 4 (pricing) is a graveyard of invented tiers and "freemium" guesses.
Query 5 and 12 are where you discover you are not in the category set at all.
Query 6–8 are where competitors with better earned media win even if your product is stronger.
Query 9–10 surface old scandals, wrong founders, or total silence.

When the model is wrong, resist the urge to only update your homepage H1. Remember the citation mix: a large share of what models lean on is earned media, not your domain. Pair owned canon with something a third party can cite. See 84% of AI Citations Are Earned Media.

Fix order (after the 90 minutes)

Write the canonical 120-word answer to "What is [Brand]?" on a stable URL. Plain language. No banned marketing sludge. Date it.
Kill the most dangerous wrong (usually pricing or security claims) with a clear owned page and, if needed, a support note to partners repeating the old line.
Pick one category query you lost and build proof: customer artifact, benchmark with method, or independent review pitch. Not five thin blog posts.
Schedule a re-run of the same twelve queries in 30 days. Same order. Same engines.

Never start with a full rebrand because Claude misordered your feature list. Never start with a full rebrand because Claude misordered your feature list. Fix the fact, then the distribution of the fact.

Tiny experiment

Tomorrow, run only queries 1, 4, and 5 on two engines. Put the answers in a doc without commentary. Send them to your founder. Ask: "Would you fund a fix?" If the answer is no, either the gaps are small or the company is not serious about AI discovery yet. Both are useful information.

The scaffold for this audit is stable even when models change. The dial you turn is which gaps you fund first. The fail-state is screenshotting one flattering answer and calling the brand "AI optimized."

Sources

84% of AI Citations Are Earned Media (Promptway)
Muck Rack Generative Pulse

- Getting Your Writing Seen Beyond Your Own Site (Promptway)

I Made Grok 4.5 My Default Coding Model for One Client Week

Agnel Nieves — Sat, 01 Aug 2026 14:46:32 +0000

On July 8, Cursor and SpaceXAI put Grok 4.5 in front of every Cursor subscriber who would click the model picker. The pitch was simple: frontier-ish coding and agent work, trained with real Cursor interaction data, cheap enough that token anxiety stops being the main character.

I did what I always do when a tool claims it belongs in the daily path. I made it the default for one week on a real client repo and wrote down what broke.

This is not a benchmark re-score. It is a work log.

The task I actually ran

Client context, sanitized: a Next.js App Router publication with content validation, MCP servers for ads and analytics reads, and a pre-commit asset pipeline. The week had three jobs that match how I actually bill time.

Ship a feature branch with two new MDX routes, shared components, and schema fields that had to pass bun run validate.
Debug a flaky integration where an MCP tool returned partial JSON and the agent kept "fixing" it by inventing keys.
Drive a multi-file refactor that touched route handlers, a Zod schema, and a small TypeScript helper without breaking static generation.

I used Cursor as the shell the whole week. Grok 4.5 as the default model. Same MCP config I already trust. No special harness beyond what a mid-size agency repo already has.

What worked, with receipts

Speed on the boring middle. Autocomplete-plus-edit on component props, frontmatter keys, and test stubs felt fast. Not magically smarter than Opus-class on hard architecture. Noticeably cheaper per loop when I was iterating ten times on the same file. For the kind of work that is 70% of a billable day, that matters more than a one-point leaderboard bump.

Cursor-native habits. This is the underrated part of "trained with Cursor data." The model was less confused by multi-cursor edits, partial selections, and "apply this diff but keep my comment." That is not a general intelligence claim. It is a product claim, and on this repo it held.

Price as a product feature. At roughly $2 input / $6 output per million tokens (and lower on cached), I stopped doing the mental math that makes people under-prompt. I asked for the second rewrite. I asked for the third. The quality of the session went up because I stopped rationing turns. That is a real effect, even when single-shot quality is a wash.

Rough week spend on the client branch, all-in model cost through Cursor: under what a single heavy Claude Max-style day used to burn on comparable volume. Your numbers will differ. The direction did not.

What broke first

Unsupervised multi-file refactors. When I pointed it at "migrate these three modules and keep generateStaticParams honest," it produced a plausible plan and then a half-applied migration. Two files updated. One left mid-state. Tests red. Claude Code on the same prompt the next morning finished the graph more cleanly, with fewer "I will fix the types in a follow-up" lies.

Confident wrong tools. On the MCP JSON bug, Grok 4.5 was eager. It rewrote the client twice before it agreed to log the raw payload. Claude's slower, slightly pedantic loop would have asked for the log earlier. Eager is not free. Eager costs review time.

Long context discipline. On a chat that had already eaten a big schema dump, it started compressing my constraints into vibes. I had to re-paste the Zod refine rules mid-thread. Not unique to Grok. Worse here than my Sonnet baseline on the same thread length.

How it compares on the jobs that matter

Job	Grok 4.5 in Cursor	My Claude Code / Sonnet baseline
Tight UI and content schema edits	Winner on speed + cost	Fine, pricier per loop
MCP / tool debugging	Mixed; needs tighter human steering	Winner on "slow down and inspect"
Multi-file refactors with static guarantees	Risky without babysitting	Winner for unsupervised depth
"Just ship the PR" Friday afternoon	Strong if you stay in the editor	Strong if you live in the terminal agent

The posture split from the public discourse is real. Cursor assumes you are editing. Claude Code assumes you are delegating. Grok 4.5 inherits the Cursor posture even when you ask it to act like an agent. That is not a bug if you wanted a co-pilot. It is a bug if you wanted a night-shift senior.

Verdict

Buy Grok 4.5 as a default inside Cursor for iterative product work if you already live in that editor and your pain is token cost plus turn latency.

Wait before making it the only model for unattended multi-file agents or production refactors that touch codegen boundaries. Keep a heavier model one hotkey away.

Skip if your whole workflow is terminal-agent and you already have Claude Code tuned. Switching shells just to chase a model is a tax.

I am not deleting Claude from the stack. I am not writing a "Grok won coding forever" post. I am changing my default for the 70% path and keeping the expensive brain for the 30% path that ships the scary PR.

Six months ago I would have told you to pick one model and learn it deeply. I no longer believe that is the right advice for coding agents. The July wave made routing the skill. Grok 4.5 is a strong cheap route, not a religion.

What I will re-test in 30 days

Same multi-file refactor with whatever patch they ship after the first wave of forum complaints.
Token spend on a pure greenfield app versus this brownfield content site.
Whether "double usage first week" promo pricing was hiding a bill shock at steady state.

If any of those flip the verdict, I will update this page in public. That is the deal on The Stack.

Sources

- Prior Promptway stack note: Connecting Claude to Google Ads and GA4 via MCP

The July Model Wave Is Not a Race You Need to Win

Agnel Nieves — Fri, 31 Jul 2026 15:39:17 +0000

Three frontier launches. Two weeks. One bad habit.

The habit is crowning a winner from a press release. Claude Sonnet 5 on June 30. OpenAI's GPT-5.6 family rolling into general availability around July 9. Grok 4.5 on July 8, co-trained with Cursor and priced to make coding agents feel cheap. The charts moved. The posts multiplied. The claim underneath most of them was the same: this is the model you should standardize on.

[The claim is nonsense. Standardization is the risk. Routing is the skill.]

What actually shipped

Strip the demos. Keep the operator facts.

Model	Maker	Window	Operator-relevant shape
Claude Sonnet 5	Anthropic	late June	Balanced agent runs, coding, long reliable chains
GPT-5.6 Sol / Terra / Luna	OpenAI	late June to mid-July	Tiered family: flagship Sol, everyday Terra, cheap Luna
Grok 4.5	xAI + Cursor	July 8	Coding and agent work at aggressive API pricing

OpenAI gated GPT-5.6 longer than the others. Safety review, staged partners, then broader access. That is part of the product story now, not a footnote. Anthropic and xAI moved faster to availability. Access policy is a feature.

Open source did not wait. GLM-5.2, DeepSeek V4, Qwen 3.6 and peers kept closing the gap for hosted and self-hosted work. The frontier is crowded. The "one brain for everything" era is over as an architecture choice, even if the marketing still pretends otherwise.

Ranked by Tuesday impact, not leaderboard theater

1. Cost and tiering matter more than the top score.
OpenAI shipping Luna / Terra / Sol as a family is the real product decision. You can route a triage job to a cheap tier and a hard research job to a flagship without changing vendors. That is operator infrastructure. A single "best model" headline is not.

2. Grok 4.5 inside Cursor changes the default coding bill.
A model trained with Cursor interaction data, sold at roughly $2 / $6 per million tokens, is not a vibe. It is a budget line. Teams that were bleeding token spend on heavier agents will try it this month whether or not they rewrite their stack. Watch adoption, not the CursorBench slide.

3. Sonnet 5's value is reliability under load, not a new personality.
If your workflows are multi-step agents that must finish, a mid-tier that holds the chain beats a flashy flagship that drifts. That is a boring metric. It is also the one that shows up in support tickets.

4. Export-control residue is still on the board.
Anthropic's Fable 5 / Mythos-class redeploy after the June export-control pause is a policy story wearing a model name. If your product depends on a single frontier weight class, you now have a quarterly risk review whether you wanted one or not.

5. Benchmarks withheld or partial are a signal.
When a lab ships without the usual suite, read that as intentional. Not always sinister. Always incomplete. Do not fill the blanks with Twitter confidence.

The permanent-winner myth

Here is the strongest form of the bad advice, stated fairly:

"Pick the best model now, standardize the company on it, and stop thrashing."

Sounds like discipline. In a market that ships a capable model roughly every few days once you count open weights, it is how you bake technical debt into the org chart. Hard-wiring one provider turns every release into a migration project. Abstracting the model turns every release into a config change and an afternoon eval.

I will say it once. Build so you can swap. Test on your tasks. Route by job. The July wave did not crown a champion. It confirmed that several frontier options are close enough that your data decides the winner, and that the winner can change by workload.

What to do this week

Not a tutorial. A short list with falsifiable edges.

Write down the three jobs AI actually does in your stack. Not aspirational. Actual.
Run each job on two models you already pay for. Same prompt. Same inputs. Score quality, latency, and unit cost.
Kill one permanent default if it loses on two of three metrics. Replace it with an explicit route.
Re-run the same three jobs when the next major weight lands. Calendar it. Do not wait for vibes.

If you skip this, you will still "evaluate models." You will just do it in Slack arguments instead of on paper.

What I am grading later

Three calls. Score me in September.

Teams that abstract the model layer will switch defaults at least once before Labor Day without a rewrite. Falsifiable: count public postmortems and internal changelogs that mention a one-line model swap.
Grok 4.5 will take measurable coding-agent share from pure Claude/OpenAI defaults among Cursor-heavy shops. Falsifiable: usage surveys, spend reports, forum default chatter.
The "one model for the company" memo will keep getting written, and it will keep aging poorly within 90 days. Falsifiable: watch the memos, then the quiet exceptions.

Noise to leave on the floor

Affiliate "best model of July" roundups with forty logos. Demo videos that never show a failure case. Seat-count panic recycled from February without a single cancelled contract attached. Benchmark charts with no task definition.

The July wave is real. The race framing is residue.

Build for the next release, not the last press cycle.

Sources

- FelloAI, Best AI models in July 2026

Six Months After the SaaSpocalypse, the Stocks Came Back. The Operator Story Did Not.

Agnel Nieves — Fri, 31 Jul 2026 15:39:16 +0000

Quote the panic first. In the strongest form.

Anthropic shipped agentic tools that do real office work. If one AI can replace five SaaS seats, the entire software multiple is wrong. Hundreds of billions in market cap should vanish, and they did.

That was the February story, compressed. Claude Cowork, plugins, Opus-class upgrades, a Goldman-style software basket down hard in a session, estimates of roughly $285 to $300 billion erased in the worst prints. Workday and Salesforce and a long list of names ate the tape. The word SaaSpocalypse did the rest.

[The market move was real. The monocausal story was not. The operator aftermath is still the open question.]

Claim Chowder: February versus July

Claim (Feb 2026)	July grade	One-line reason
"Agents kill SaaS this year"	Fail	Public multiples mean-reverted faster than seat bases dissolved
"Cowork is only a demo"	Fail	Workflow automation is now a default expectation in buyer RFPs
"Every horizontal SaaS is dead"	Nonsense	Data gravity, compliance, and workflow lock still pay rent
"AI is a pure margin tax on software"	Partial	Pricing pressure is real; free replacement is not universal
"Operators will cancel seats in bulk by summer"	Incomplete	Spot cancellations yes; systematic wipeout not in the open data

I am not here to defend software equities. I am here to stop operators from taking a Wall Street weekend as a strategy memo.

What the selloff actually was

Three things collided.

A visible agent product that looked like it could draft, file, research, and chain office tasks without five logins.
A valuation regime that had already been compressing. Software multiples had room to fall before Cowork gave traders a narrative.
A meme with a deadline. Once "SaaSpocalypse" fit in a headline, every downtick confirmed the story and every uptick was "denial."

Executives called the panic overblown. Analysts warned about pricing power anyway. Both can be true. A 6% session in a sector basket is not a customer survey. It is a forced rewrite of discounted cash flow assumptions under uncertainty.

What operators actually did

From the ground, not the tape:

Trials exploded. Migrations lagged. Trying Cowork or a coding agent is cheap. Ripping out the system of record is not.
Shadow AI spend rose next to SaaS spend. The line item grew. It did not always replace. CFOs noticed both.
Categories split. Thin workflow glue and generic document tools felt heat. Vertical systems with proprietary data, audit trails, and integrations held. Boring infrastructure is still boring infrastructure.
The seat is not dead. The idle seat is. Buyers started asking which licenses produce artifacts an agent could produce by Tuesday. That question does not require a stock chart.

If your product's only defense is "we have a nicer UI for a task Claude can already do," you felt this winter. If your product is the system of record for something regulators care about, you felt a pricing conversation, not an extinction event.

The residue that matters more than the rebound

Stocks can rebound on rates, earnings, and attention cycles. Three structural shifts did not rebound away.

1. Buyers budget for agents as a category.
Not experimental. Line-item. That permanently changes how they negotiate your renewal.

2. Switching cost is the product.
Feature checklists lost. Data model, integrations, permissions, and eval history won. The SaaSpocalypse was a referendum on shallow SaaS.

3. Narrative risk is now product risk.
A lab demo can reprice your category in a session. That is not fair. It is the water you swim in. Communication and proof-of-work matter more when the market is itchy.

Falsifiable calls for Q4 2026

Score these in December.

Net seat reductions in generic productivity SaaS will show up in earnings language more than in February price charts. Look for "optimization," "consolidation," and "AI substitution" in prepared remarks, not just stock ticks.
Vertical SaaS with proprietary workflows will guide stable or rising NRR while horizontal doc tools guide down. Split the basket; stop averaging apples and glue.
At least two public software companies will rebundle around agent runtimes rather than human seats as the primary SKU. Watch packaging, not keynotes.
The next Cowork-class launch will move equities less than February did, and move RFPs more. Attention decays. Procurement language sticks.

If all four miss, I will say so in a follow-up. That is the job.

What to ignore for the rest of July

Death-of-SaaS threads with no cancelled contract attached. Victory-lap founder posts that equate a stock bounce with product safety. "We added AI" changelog spam that does not change the artifact the customer ships.

Six months later, the apocalypse looks like a repricing. The operator story looks like a filter. Shallow tools got priced like shallow tools. Deep systems still have to prove they are deep.

The chart healed. The question did not.

Sources

- Business Insider coverage of Claude Cowork and market reaction (Feb–Apr 2026 cycle)

Indie Hackers Built AI Factories. Then Nobody Showed Up.

Agnel Nieves — Thu, 30 Jul 2026 15:34:35 +0000

There is a particular kind of demo video making the rounds this year. Dark editor theme. Agent panel streaming. A full app appearing in minutes. The caption says some version of "the only limit is imagination."

Then you click through to the product and the waitlist is a Google Form with eleven responses, three of them the founder under different emails.

Pieter Levels put a sharper point on it in June: indie hackers building fancy AI factories with no money and no traffic. The post traveled because it was mean in the useful way. It named the thing people were privately embarrassed about.

I do not think the builders are stupid. I think the bottleneck moved, and a lot of playbooks did not.

The setup

For a decade the indie story had a honest hard part: shipping. You had to learn enough code, or hire it, or glue no-code until it cried. AI coding agents did not remove craft. They removed the excuse. Claude Code, Cursor, Grok-class models in the editor, boilerplate kits like ShipFast, component generators, database scaffolds. The factory floor got automated.

What did not get automated: a reason for a stranger to care, a channel that compounds, a promise people renew.

So we got a generation of products that are technically complete and socially imaginary.

What the empty factory looks like

I keep a private list from conversations and public postmortems. Patterns, not call-outs.

Beautiful onboarding, no top-of-funnel. The first-run experience is gorgeous. The homepage has no distribution plan beyond "post on X."
Feature parity with a giant, trust parity with a stranger. "We are like Notion + AI" is not a wedge. It is a request to lose.
One-week revenue, zero week-eight retention. Launch spike from friends and a Product Hunt bounce. Then silence. Same shape as the flight-sim money that visits once and leaves. See Pieter Levels and the sim that went to zero.
Agent theater instead of a job. The product demos an agent. The customer still has a job to do on Tuesday that the agent does not finish.

Hold on. Is this just "marketing matters"? Yes, with a 2026 asterisk: marketing also got flooded with AI sludge, so the trust bar for small tools went up while the build bar went down. You are not competing with silence. You are competing with a thousand competent-looking clones.

Who still prints money

Look at the people this column has already covered and the durable ones like Danny Postma on HeadshotPro.

The pattern is rude and consistent.

A purchase that existed before the model. Headshots. Photo generation for a known vanity or work need. Boilerplates for people who already sell software. Verified revenue pages for people already lying with screenshots.
A channel that is not a single launch post. SEO, newsletters, years of public logging, communities where the founder is a known quantity.
Willingness to be boring. One vertical. One clear price. Refunds. Support. The unglamorous middle.

Marc Lou's 24-hour TrustMRR spike was real, and so was the year he earned less than the prior one. The weekend needs a decade under it. That is not romantic. It is accounting.

The nervous part

Here is the sentence founders flinch at: if your only advantage was that you could code the v1, you no longer have an advantage.

The new hard skills look like this:

Picking a job where "done" is obvious and payment is habitual
Building proof other humans will cite (see the earned-media AEO problem for brands; it applies to products too)
Saying no to agent features that do not finish the job
Measuring renewals harder than launch-day MRR screenshots

AI factories without trucks are still factories. They just manufacture unsold inventory faster.

Field notes, not a sermon

I asked operators what they cut when the empty dashboards got embarrassing. The answers rhymed.

Cut model roulette. Pick a stack. Ship weekly to real users.
Cut horizontal scope. One persona, one job.
Cut launch culture as identity. Replace with a channel experiment that lasts thirty days minimum.
Keep the agents, but point them at distribution chores (support macros, content diffs, SEO page generation for a keyword you already validated) instead of only at more product surface.

None of that is as fun as a three-hour build video. All of it is closer to Photo AI at high margin than a sim at $0/m.

The verdict

The vibe-coding era did not kill indie hacking. It killed the story that shipping was the main boss fight. Levels' jab lands because the feed is full of factories and short on customers. The founders who will still be here in 2027 are not the ones with the most tools in the agent panel. They are the ones who can explain, in one sentence, who pays them every month and why that person would be annoyed if the product disappeared.

Build the truck. Then build the factory.

Sources

Pieter Levels, indie hackers AI factories post
Pieter Levels flight sim story (Promptway)
Marc Lou 24-hour app (Promptway)
Danny Postma / HeadshotPro (Promptway)

- Indie Hackers and X public postmortems on launch spikes without retention (2025–2026 cycle)

The MCP Servers Worth Paying For (and the Ones That Just Eat Context)

Agnel Nieves — Thu, 30 Jul 2026 15:34:35 +0000

I have a rule for MCP now. If a server cannot name the job it finishes, it is entertainment.

The ecosystem exploded. Every SaaS with a REST API grew a README that says "works with Claude and Cursor." Half of them dump entire schemas into the context window on connect. A quarter want write scopes you should never grant a chat box on a Friday. The useful quarter is why this protocol won.

This is not a directory of forty logos. It is a verdict list from wiring MCP into real client work, including the Google Ads and GA4 audit path I already wrote up.

How I score a server

Criterion	Pass looks like
Job clarity	One sentence: "this finishes X"
Context cost	Tools are discoverable without pasting the universe
Auth blast radius	Read-only possible; write is gated and obvious
Failure mode	Errors are legible; no silent empty success
Host portability	Works in Claude Code / Cursor / desktop without a rewrite

If it fails context cost, I skip even when the demo is pretty. Context is rent. Servers that burn rent on connect are a tax on every later thought.

Buy

GitHub (official or well-maintained community, read-heavy).
Job: PRs, issues, file reads against the remote when local is not enough. Buy for code review and "what shipped last week" questions. Keep write scopes off until you have a reason.

Filesystem / project roots you already trust.
Job: the agent can see the repo you meant. Buy, because without this MCP is cosplay. Constrain roots. Do not point it at $HOME.

Browser automation (Playwright/Puppeteer-class) for repro only.
Job: "show me the broken state" and light QA. Buy for bug reproduction. Skip as a general surfing buddy. Flaky, slow, easy to over-permission.

Postgres or warehouse read replicas with a forced LIMIT culture.
Job: answer data questions without exporting CSVs by hand. Buy only with read-only roles and row limits. I have watched models invent joins that scan the planet. The server should make that hard.

Google Ads + GA4 read-only (the path I already run).
Job: marketing audits with real spend and real conversion paths. Buy for agency and in-house growth teams who currently live in twenty UI tabs. The gotchas are auth and the prompt, not the protocol. Full write-up linked above.

Docs / fetch servers that do progressive discovery.
Job: pull the one page you need, not the whole doc site. Buy when the server supports targeted fetch. Skip the ones that embed a vector DB of everything on connect.

Wait

"All-in-one" mega servers with twenty tools.
Often one good tool trapped in a mall. Wait until you know which tool you actually call weekly. Prefer small servers you can disable.

Slack / email write access.
Read-only search can be useful. Write is how you get a polite agent apologizing in the wrong channel. Wait until you have approval workflows and a human in the loop.

CRM writebacks.
Same story. The demo is magical. The mistaken field update is a quarter of pipeline chaos. Wait.

Hosted MCP marketplaces with vague auth.
The protocol is open. Your secrets should not be. Wait on anything that wants OAuth to five systems to "get started in one click" without a clear data flow diagram.

Skip

Servers you cannot name a weekly job for.
Curiosity installs are how context dies.

Anything that requires broad cloud admin to "try."
If the quickstart is "attach Owner," the quickstart is wrong.

Scrapers aimed at ToS-hostile targets.
Legal and ban risk is not a flex. Skip.

Duplicate servers for the same job.
Two GitHub MCPs do not make you twice as effective. They make tool choice a coin flip mid-thought.

A sane default kit for a small product team

Filesystem (constrained)
GitHub read
One browser tool for QA
One data read path (warehouse or product DB replica)
Optional: the marketing pair (Ads + GA4) if that is the business

That is five. If you are past eight, you are probably collecting.

Security notes I wish I had tattooed earlier

Prefer read-only tokens. Always.
Rotate anything that ever lived in a screenshot.
Log tool calls for a week. You will find a server you never meant to leave on.
Treat MCP like production IAM, not like browser extensions in 2012.

Verdict

Buy small, job-shaped, read-mostly servers that survive a real Tuesday.

Wait on write scopes and mega-bundles until the job is undeniable.

Skip directory tourism and anything that eats the context window as a hobby.

MCP is how agents touch the world. The world includes your ads account, your database, and your reputation. Wire it like you mean it.

Sources

- Cursor / Claude Code MCP docs via vendor documentation portals

The 12-Prompt Eval I Run Before I Trust Any Model Upgrade

Agnel Nieves — Wed, 29 Jul 2026 15:37:17 +0000

This post is about evaluating a new model against a frozen task set before you change production defaults. It is not about training an academic benchmark. By the end you will be able to run a half-day eval that answers one question: does this model earn the default slot on our work.

I do not upgrade on launch day. I upgrade when the scoreboard says so.

Why twelve, not two

Two prompts create anecdotes. Twelve create a pattern. I want failures to cluster. If the new model only fails JSON, I patch JSON. If it fails voice, length, and honesty together, I keep the old default.

The set below is the lab's current kit for marketing and ops clients. Swap domains if you write code or legal. Keep the shape: constraints, faithfulness, structure, refusal, repair.

The twelve prompts (compressed)

Run each against old default and candidate, same system scaffold, temperature locked where possible. Three trials each. Majority wins.

#	Job	What you score
1	Homepage hero brief, hard word cap	Length obedience, banned words
2	De-slop rewrite of a sloppy draft	Tells removed without inventing facts
3	JSON object for a fixed schema	Valid parse, nulls not fabrications
4	Long PDF / long paste summary	No invented section titles
5	Brand voice match from two samples	Peer tone, not marketer tone
6	"I don't know" under missing data	Refusal to invent metrics
7	Competitor comparison table	Sources or explicit unknowns
8	Email to an angry customer	Empathy without overpromising
9	Step procedure (numbered)	Order preserved, no skipped steps
10	Multilingual or locale tweak	No silent language mixups
11	Tool / MCP style: use only provided logs	No fake log lines
12	Repair pass: fix invalid JSON from trial 3	Converges in one step

You can paste your real client inputs into each row. Toy inputs lie.

Rubric (binary, on purpose)

For each trial, pass only if all apply:

Constraints: every hard rule in the prompt held.
Faithfulness: no new facts, numbers, or quotes that were not in the input.
Format: schema or structure match when required.
Voice: would you send it to the client without a shame rewrite.

Score the model, not your affection for the vendor. A pretty paragraph that invents a "47% lift" is a fail on #6 and #2.

Promotion rule I use: candidate must win or tie on at least 9 of 12 jobs by majority of three runs, and must not fail #3, #6, or #11. Those three are the trust breaks. Everything else is quality of life.

The bad eval (do not do this)

Open ChatGPT. Ask "are you better at writing now." Paste one blog intro. Declare victory on Slack.

That is not an eval. That is a mood.

How I log it

A single markdown table in the client repo:

| job | old_pass | new_pass | notes | date | models |

Check it into git. When someone asks "why did we switch," you have a file, not a vibe. When the next wave hits, you re-run the same twelve instead of inventing a new ritual.

Interaction with the migration post

If you are mid-upgrade, pair this with Upgrade Your Prompt Stack for Sonnet 5 and GPT-5.6. Eval first tells you whether to move. Migration patches tell you what to change if the model is close but constraint-soft.

If the candidate fails the trust breaks, no amount of "be concise" poetry will save it. Keep the old default. Re-test next month.

Tiny experiment

This week, freeze your twelve inputs in a folder. Do not improve them mid-eval. Run old vs new once. Put the table in Slack without commentary. Ask the team which model they would ship. Compare their gut to the table. The gap is why the lab exists.

The scaffold survives the temperature change. The recipe assumes you already wrote the brief. The fail-state is upgrading on a demo video.

Never promote a model that fails honesty. Never promote a model that fails honesty.

Sources

- The July Model Wave Is Not a Race You Need to Win

Upgrade Your Prompt Stack for Sonnet 5 and GPT-5.6 Without Rewriting Everything

Agnel Nieves — Wed, 29 Jul 2026 15:37:15 +0000

This post is about migrating a working prompt stack to new models without starting from a blank file. It is not about crowning Sonnet 5 or GPT-5.6 as the permanent winner. By the end you will be able to re-test a client system prompt in one afternoon and ship only the lines that actually moved.

The July wave made a lot of smart people do a dumb thing. They opened last year's master prompt, deleted it, and wrote a new "optimized for the latest model" version from memory. The new version often looked cleaner. It also threw away six months of hard-won constraints.

Keep the scaffold. Re-test the fail-states. Patch, do not rewrite.

What I freeze on day one

I treat every production prompt as three layers:

Hard constraints (banned words, length, format, "never invent numbers")
Task contract (what good looks like, who the reader is, what success means)
Style and examples (voice samples, few-shots, tone notes)

Layers 1 and 2 almost never need a full rewrite when a model upgrades. Layer 3 often does, because new models have different default verbosity and different obedience to "sound like a peer, not a marketer."

If your constraints already sit at the top (see The Constraint Goes First), you are ahead. If they do not, fix order before you chase model-specific tricks.

The bad migration (what I keep seeing)

You are now optimized for Claude Sonnet 5 and GPT-5.6.
Be more intelligent, more careful, and more creative.
Use the full power of the new models.
Write better than before.
[... then the entire old prompt pasted underneath, unedited ...]

This fails for three reasons. First, "be more intelligent" is not a constraint. Second, stacking a hype preamble above your real rules undoes constraint-first structure. Third, you have no baseline, so you cannot tell whether the new model helped or the rewrite just got lucky once.

(This is the part vendors are wrong about when they imply a model upgrade is a free prompt upgrade.)

The working migration

I run the same three tasks on the old model and the new one, same temperature settings where the API allows it, same inputs.

Task A: client brief (verbosity fail-state)

Old models often under-specified. New frontier models often over-write. On Sonnet 5 and GPT-5.6 Terra in my tests, the default brief came back 30 to 50 percent longer than the client wanted unless length was in the first five lines.

Patch that worked:

Constraints, in priority order:
1. Total output under 180 words. Count. If over, cut before sending.
2. No preamble ("Sure", "Here is", "I'd be happy to").
3. No bullet lists unless the user asked for a list.
...

I did not change the brand voice paragraph. I moved and tightened the length rule until both models respected it on three runs.

Task B: structured JSON (fidelity fail-state)

GPT-5.6 Luna was cheap and fast and slightly sloppier on nested keys in my client schema. Sonnet 5 was stricter but occasionally wrapped JSON in a short apology line when it felt unsure.

Patch that worked:

Output: a single JSON object. No markdown fences. No commentary.
If a field is unknown, use null. Never invent a string to fill a gap.
Validate against this schema before answering:
{ "headline": string, "dek": string, "risks": string[] }

When Luna still drifted, I added a one-line repair pass as a second call instead of stuffing more threats into the first prompt. Two cheap calls beat one anxious essay.

Task C: voice match (drift fail-state)

Both new models were better at following long style guides if the guide was short. Long style guides got summarized into vibes. The de-slop stack still applies (The De-Slop Prompt Stack). What changed: I cut voice samples from five paragraphs to two tight ones and put the banned-word list back at the top.

The recipe: fewer examples, sharper constraints, same brand truths.

Side-by-side: what I changed for one SaaS client

Line	Before (old stack)	After (July 2026 patch)
Length	"Keep it concise" at the bottom	Hard word cap in constraint #1
JSON	"Respond in JSON" mid-prompt	Schema + null rules + no fences at top
Voice	Five sample posts	Two samples + banned list + "no em dashes"
Model note	none	"If uncertain, ask one clarifying question; do not guess metrics"

Three runs per model. I only kept patches that improved at least two of three runs. Everything else stayed frozen.

Paste-ready checklist (90 minutes)

Export the current system prompt. Do not edit it yet.
Pick three real inputs from the last month (not toy examples).
Run all three on the old default model. Save outputs.
Run all three on the candidate model with the same prompt. Save outputs.
Score only: constraint obedience, factual caution, voice match, length. Binary pass/fail per criterion.
Patch the highest-failure constraint first. Re-run. Stop when two of three tasks pass.
Ship the patched prompt with a one-line changelog at the top of the file: date, models tested, what moved.

Never give yourself a free rewrite. Never give yourself a free rewrite. The scaffold is the asset. The model is the temporary employee.

Tiny experiment for you

Tomorrow, take one production prompt. Do not rewrite it. Add a single hard length constraint at the top. Run it on your new default model three times. If length still fails, the model is not the first problem. Your constraint is still soft.

That is the whole lab method for a model wave. Keep the recipe. Dial the parts that broke. Leave the rest alone.

Sources

The Constraint Goes First (Promptway)
The De-Slop Prompt Stack (Promptway)

- July model wave context (Promptway)

Claude Code vs Cursor: I Gave Both the Same Client Task for Five Days

Agnel Nieves — Wed, 29 Jul 2026 14:11:16 +0000

The cold coffee was on the coaster and the brief was the same both mornings: ship the content schema fields, stop the MCP client from inventing keys, and refactor the validation path without breaking static params. No greenfield toy app. No "build me a todo list" demo.

I ran days one through three primarily in Cursor. Days four and five primarily in Claude Code. Same repo. Same tests. Same definition of done. I am not a full-time staff engineer on this stack, which is the point. Most of the people choosing between these tools are operators who write serious code some days and ship product the rest.

The posture split (say it plain)

Cursor is an AI-native editor. You drive. The model assists inside selections, chats, and agent modes that still feel like an IDE session.

Claude Code is a terminal-first agent. You delegate. The model plans, touches files, runs commands, and comes back with a report. You supervise.

Every comparison that ignores that split ends up arguing about models when the real fight is about workflow. Models matter. The shell matters more than the launch blog admits.

Day notes

Days 1–2, Cursor (with Grok 4.5 as the cheap default, Sonnet-class when stuck).
Feature work flew. Component props, MDX frontmatter, small UI fixes. The loop of highlight, instruct, accept, tweak is still the fastest way I know to stay in flow on a brownfield Next app. Grok 4.5 made the loop cheaper. When the MCP JSON bug showed up, the model wanted to rewrite the client before it wanted to print the raw payload. I had to force the log. That cost an hour I did not budget.

Day 3, Cursor agent mode on the refactor.
It produced a confident plan and a partial migration. Two files clean. One half-updated. Tests red. I finished it by hand in the editor, which is fine, and also the tell: when I stay in the seat, Cursor is excellent. When I walk away, I come back to homework.

Days 4–5, Claude Code on the same remaining refactor and a second bug class.
Slower start. Better graph awareness. It asked fewer "should I" questions and just ran the test suite. The unsupervised multi-file pass completed with less babysitting. The cost, depending on plan tier and how hard you drive it, can climb past a flat Cursor subscription if you live in Max-style usage. You are buying a night-shift senior, not a keystroke tax.

Head-to-head

Job	Winner	Why
Tight UI / content edits all day	Cursor	Flow, diffs, visual context
Cheap high-volume iteration	Cursor + Grok 4.5	Price and speed on the 70% path
MCP / integration debugging	Claude Code (slight)	More willing to inspect before rewrite
Multi-file refactor while you step away	Claude Code	Completeness over partial applies
Learning a foreign codebase cold	Claude Code	Longer agentic exploration
Pairing on a design-sensitive UI	Cursor	You need eyes on the pixels

Named loser for unsupervised depth: Cursor agent mode on this repo, this week. Named loser for all-day edit ergonomics: Claude Code. Both losses are about posture, not morality.

What I would buy with my own money

If I am in the code six hours a day on product UI and content systems, I pay for Cursor and I keep a strong model plus Grok 4.5 for cost routing. If I am handing off a gnarly migration overnight or I live in the terminal anyway, I pay for Claude Code and I stop pretending the IDE is the center of the universe.

A lot of teams will correctly buy both. The wrong move is forcing one religion on every task because the procurement form has one line.

Hold on. Is this just "use both" mush? Only if you skip the routing rule. Default editor path: Cursor. Default agent path: Claude Code. Escalate across the boundary when the job changes, not when Twitter changes.

Verdict

Buy Cursor for daily editing and product velocity, especially with Grok 4.5 on the meter.

Buy Claude Code for delegated multi-file work and long bug hunts.

Skip any article (including parts of this one, if you only read the table) that crowns a single winner for "coding in 2026." The winner is the operator who matches shell to job.

I will re-run the same brief after the next major agent release. If the partial-apply problem disappears inside Cursor, I will update the table. Until then, the five-day receipt stands.