How Engineers Are Actually Building with Claude Code

Cursor — Composer 2.5#

Source: https://cursor.com/changelog/composer-2-5 Credibility: High (first-party changelog, shipped today)

What happened: Cursor shipped Composer 2.5 today. The changelog describes it as "a substantial improvement in intelligence and behavior over Composer 2" — specifically better at "sustained work on long-running tasks," following complex instructions more reliably, and being "more pleasant to collaborate with." This isn't a new feature category; it's a meaningful capability upgrade to the core agent mode that already existed.

Key capabilities:

• Improved performance on long-running, multi-step tasks (not just single-shot completions)
• More reliable instruction-following on complex requests
• Better overall collaboration feel — the language in the changelog ("more pleasant to collaborate with") suggests improvements to things like when it asks clarifying questions versus just proceeding

Why it matters for PMs: The framing here is telling. "Sustained work on long-running tasks" is Cursor explicitly positioning Composer as something closer to a junior engineer you hand a ticket to, not a fast autocomplete engine. That's a different product promise and a different user mental model. If this actually holds up in practice, it changes how developers think about task scope — you'd start writing bigger, more ambiguous prompts instead of decomposing everything manually. For PMs evaluating AI coding tools, this is the capability threshold that separates "useful for individuals" from "potentially changes how teams allocate work."

Critical questions:

• "Sustained" is relative — what's the actual task complexity ceiling? Can it hold context across 50+ file edits, or does quality still degrade?
• "More pleasant to collaborate with" is vague. Does this mean fewer unnecessary interruptions, better turn-taking, or something else?
• How does this compare to Windsurf's Cascade or GitHub Copilot agent mode on the same kinds of tasks — is this a genuine capability lead or catching up?
• Does the improvement require any prompt changes from users, or is it transparent?

Action you could take today: Open Cursor, find a medium-complexity refactor or feature you've been breaking into small chunks, and hand it to Composer 2.5 as a single larger task. See if it stays coherent across the whole thing — that's the real test of the "sustained work" claim.

Lenny's Newsletter / Thariq Shihipar (Anthropic) — HTML Is the New Markdown#

Source: https://www.lennysnewsletter.com/p/html-is-the-new-markdown-how-anthropic Credibility: High (first-person account from a Claude Code engineer at Anthropic, published by Lenny)

What happened: Thariq Shihipar, an engineer on the Claude Code team at Anthropic, appeared on Lenny's podcast to talk about how they actually build with Claude Code internally. The headline finding: they stopped using markdown as the output format for Claude-generated specs and documents and switched to HTML. The reason is functional, not aesthetic — HTML lets them build interactive "micro-apps" for things like spec editing and living design systems, where the document itself becomes a working interface rather than a static file.

The other framing from the episode: Shihipar describes engineers increasingly becoming "compute allocators" — people who decide what tasks to hand to AI and how to structure the work, rather than doing the implementation themselves.

Key patterns:

• HTML as output format: when you ask Claude to generate a spec or document, outputting HTML lets you embed interactive elements — dropdowns, toggles, live previews — that markdown can't do. The document becomes a lightweight app.
• Micro-apps for spec editing: instead of a static PRD that gets stale, you generate a small interactive document that can be updated and interacted with
• Living design systems: design documentation that updates itself or has interactive examples, rather than a static Notion page
• "Compute allocator" framing: the engineer's job shifts toward task decomposition and judgment about what to delegate, not implementation

Why it matters for PMs: The HTML-over-markdown insight is immediately applicable to anyone using Claude Code or similar tools for documentation or spec work. If you're asking Claude to write a PRD or a design brief, asking for HTML output instead of markdown gives you something you can actually interact with and share as a lightweight web page. The "compute allocator" framing is worth sitting with — it's one of the cleaner descriptions of how the PM/engineer role is actually shifting. You're not writing less; you're writing differently. The inputs are task descriptions and judgment calls, not implementation details.

Critical questions:

• How does this workflow scale to teams? HTML micro-apps are great for individual use, but does it create versioning and collaboration problems when multiple people need to edit?
• Is "compute allocator" a durable job description or a transition state? If AI gets better at deciding what to delegate to itself, does that role shrink too?
• What's the failure mode here — when does the HTML micro-app approach produce something unmaintainable or inscrutable?
• This is Anthropic engineers building with their own tools. How much of this transfers to teams using Claude via API vs. Claude Code directly?

Action you could take today: Next time you ask Claude to write a spec, brief, or research doc, add "output as a self-contained HTML file with interactive elements where useful" and see what you get. It costs nothing to try and gives you a tangible feel for whether this workflow is worth adopting.

Amazon / AWS — Bedrock AgentCore Custom Evaluators#

Source: https://aws.amazon.com/blogs/machine-learning/build-custom-code-based-evaluators-in-amazon-bedrock-agentcore/ Credibility: High (first-party AWS engineering blog, tutorial with specifics)

What happened: AWS published a tutorial showing how to build custom code-based evaluators for AI agents inside Amazon Bedrock AgentCore. The example is a financial market-intelligence agent with four Lambda-based evaluators — registered with AgentCore and run in both on-demand and online modes. The post shows how to combine custom evaluators with Bedrock's built-in evaluators and call external services during evaluation.

Key capabilities:

• Lambda-based custom evaluators: you write evaluation logic as Lambda functions and register them with AgentCore
• On-demand and online modes: run evaluations as a one-off check or continuously in production
• Composable with built-in evaluators: mix custom logic with AWS's pre-built quality checks
• External service calls from evaluators: your evaluation code can call APIs, databases, or other services to verify agent outputs

Why it matters for PMs: Evaluation is the unsolved problem in production AI agents. Most teams either skip it (and find out from users when things go wrong) or build bespoke logging and checking systems that don't integrate with their deployment pipeline. AgentCore's approach — treat evaluators as first-class, deployable Lambda functions that run alongside your agent — is a concrete answer to "how do we know the agent is doing the right thing?" For PMs shipping agents on AWS infrastructure, this is worth understanding before you launch, not after.

Critical questions:

• What does "online mode" evaluation actually add to latency? Running Lambda evaluators in-line with every agent action could be slow.
• How do you handle evaluation failures in production — does AgentCore provide rollback, alerts, or just logging?
• The example is a financial agent, which is unusually high-stakes. Does this approach generalize to lower-stakes agents where the cost of Lambda-per-evaluation might not be justified?
• What's the relationship between AgentCore evaluators and LangSmith or other observability tools teams might already be using?

Action you could take today: If you're shipping or planning an agent on AWS, read this post and map the four Lambda evaluator examples to your own agent's failure modes. Even if you don't implement AgentCore evaluators now, the taxonomy of "what could go wrong and how would I check it" is worth having before launch.