This post is a collaboration with Ilia Karelin, who writes Prosper, a newsletter sharing tactical AI workflows with frameworks you can plug into your own setup. What drew me to Ilia’s work is that he goes deep into areas most people only skim the surface of, explaining them in layman’s terms that simplify things for both tech and non-tech folks. His complete setup guide for Claude Chat, Cowork, and Code is one of the most thorough breakdowns I’ve seen. With Cowork gaining traction, I’ve noticed a gap between people who installed it and people who know how to make it useful. Ilia bridges that gap better than anyone I’ve read, so I was glad he was open to writing this together. Subscribe to Prosper here:

Prosper

Every week, practical AI workflows, prompts, and guides you can put to use the same day - no matter your technical background.

By Ilia Karelin

Cowork is Anthropic’s answer to non-technical folks seeking the benefits of Claude Code - an agent inside the Claude Desktop app that reads your files, connects to your tools, and executes complex tasks end-to-end without you writing a single line of code. If Claude Code is built for engineers, Cowork is built for everyone who wants the same capabilities without having to open a terminal.

You point it at a folder and describe what you need in plain language: organize 200 scattered files by type and project, turn receipts into a formatted expense report, batch-rename months of screenshots with consistent dates, or synthesize five research PDFs into a single brief with citations.

Since January, I’ve been running my newsletter production inside Cowork: idea triage, outline generation, draft editing, and automations that process my raw notes every Monday morning without me touching them.

The difference isn’t my prompting skill, but three useful Cowork features: connectors, scheduled tasks, and plugins. This post covers all three with concrete workflows you can reuse.

Connectors: Cowork reads and writes to your actual tools

Connectors let Cowork plug directly into the tools you already use: Gmail, Notion, Slack, and Google Drive. and work with your actual data inside a session.

In February, Anthropic expanded connectors beyond project management tools to include popular everyday apps such as Gmail, Google Calendar, Notion, and more.

The connector I use most is Notion. It handles nested pages well, which matters for any workspace with real depth. The brain dump workflow, where raw ideas I capture on my phone get automatically triaged into structured newsletter briefs every Monday, is the next section that runs entirely through it.

Gmail is the other app worth connecting to. Even without any scheduled tasks, having Cowork read your emails during a Cowork session, rather than you pasting them in, reduces friction enough that you’ll actually use it for email-related work, such as drafting emails in your style or taking bulk actions like archiving all emails from a specific sender.

The real payoff comes when you combine a connector with a scheduled task. That’s where Cowork stops being something you open and starts being something that runs in the background.

Scheduled tasks and automated workflows

In Cowork, each piece of work you hand off to Claude is called a task.

To set one up, type /schedule in any Cowork session and pick a frequency: daily, weekly, monthly, weekdays only, or on demand. That’s useful for anything that needs to happen regularly without you having to start it each time.

How to set it up

Two paths: type `/schedule` in any session, or use the “Scheduled” tab in the sidebar to create tasks directly. You set a name, a prompt, a frequency, and which folder to work from.

Each scheduled task runs as its own full Cowork session with access to all your connectors, plugins, and folder context.

Note that your laptop must be awake for scheduled tasks to run, as they run locally. Anthropic recently added a feature (see the red arrow below) to prevent your computer from going to sleep, so tasks can continue running.

A workflow I actually use

I have a “Quick Brain Dump” widget on my phone. Whenever an idea hits, I write it into a Notion page - a text block of raw and unrefined stream of thought. Those notes will remain on this page until I manually review and organize them. That is, until I plugged in Cowork.

To make that page usable in Cowork, I first connected my Notion workspace on my phone.

Once I connected my Notion workspace to Cowork, I set up a scheduled task that runs every Monday morning.

1. Reads everything added to the brain dump page that week

2. Decides which entries have real newsletter potential

3. Turns the strong ones into a working title, an angle, and 3 questions I’d need to answer to write it

4. Saves them to my Newsletter Ideas database as “Needs Review”

I capture ideas throughout the week. When I sit down on Monday, the triage is already done.

Here’s the exact prompt running inside that task (ok to steal):

You are a newsletter research assistant. Connect to my Notion workspace 
using the Notion connector.

1. Read all entries added to my “Quick Brain Dump” page this week

2. For each entry, decide: does this have real potential to become a
newsletter post? (yes/no + one sentence why)

3. Only for strong “yes” entries: generate a working title, the angle
that makes it interesting, and 3 questions I’d need to answer to
write it

4. Skip entries that look like tasks, reminders, or personal notes -
only process ideas

5. Save all results to my “Newsletter Ideas” Notion database with
Status = “Needs Review” and Source = “Brain Dump [date]”
If an entry is too vague to evaluate, add it to the database with
Status = “Unclear” and a note on what’s missing.

Here are the results in my Notion workspace:

The same pattern works for anything where raw input is collected in one place and needs to be structured: Slack threads into action items, Gmail into expense logs, Linear tickets into weekly reports.

Cowork is like a back-office assistant that once taught, does the work for you on a recurring cadence.

Chaining scheduled tasks

The output of one scheduled task can feed into the next one’s input.

The brain dump task runs early Monday and saves structured briefs to a Notion database. A second scheduled task runs after that, reads those briefs, picks the strongest one based on recency and audience fit, and drops a full working outline into my local drafts folder.

Task #1 processes raw input. Task #2 acts on structured output. No human intervention needed.

Each plugin is a full toolkit for one domain

There are dozens of plugins available for Cowork, each one a specialist kit for a specific domain. A plugin bundles skills, connectors, slash commands, and subagents around a job function like Sales, Data, or Design, so you don’t have to wire them up yourself.

Install one and you immediately get domain-specific commands and integrations tailored to that role’s actual workflows.

Here’s what the Data plugin contains, for example:

Composable Plugins

You can install multiple plugins and commands inside of those plugins, and pull from all of them in a single task with just a prompt. Pretty incredible.

Here’s a real example. I dropped a messy sales CSV into Cowork: missing values, a duplicate row, a negative amount (these numbers are not real), and ran this single prompt with both the Data and Design plugins installed:

I have a sales CSV file (sample_sales.csv) and the Prosper company logo 
(image.jpeg) in this folder.

Step 1 - Data plugin:

/analyze the CSV and find:

- Total revenue by product (excluding refunded transactions)
- Month-over-month revenue trend across January, February, March
- Revenue split by region (North America, Europe, Asia Pacific)
- Any data quality issues worth flagging (nulls, anomalies, duplicates)

Step 2 - Data plugin:

/write-query to calculate the refund rate by product - which product
has the highest percentage of refunded transactions?

Step 3 — Design plugin:

/performance-report using the findings above. Format it as a clean one-page
Q1 sales report for Prosper. 
Include:

- The Prosper logo at the top
- A summary section with 3 headline numbers (total revenue, top product,
top region)
- A data quality callout box flagging the issues found in Step 1
- A refund risk section showing which product needs attention
- Brand colors: blue (#4B4EE4), white background, clean sans-serif font

Save the output as prosper_q1_report.pdf

Step #1 used the Data plugin to analyze revenue by product and region, flag the data quality issues, and calculate month-over-month trends. Step #2 wrote the SQL to calculate refund rates by product, and Step #3 switched to the Design plugin and formatted everything into a branded one-page report, logo included.

One prompt. Three steps. The output went straight from a raw CSV to something you could send to a stakeholder.

Where to start

Today: Install Gmail or Slack connectors. Connect whichever tool you actually use to collect raw inputs. Notion, email, whatever it is.

This week: Set up one scheduled task. Pick something you do manually on a recurring basis: drafting a sales update, triaging weekly tasks from Jira/Linear, summarizing newsletters, and let Cowork run it instead. Use the brain dump prompt above as a template, or use Claude to generate a prompt for you by describing the task you want it to automate

This month: Install two or three plugins that are relevant for your tasks, such as Data Analysis or Designer. Then run a task that pulls data from multiple plugins in a single session. Once one scheduled task is working, consider chaining it as input to another task, e.g., a task to draft a report with another to send it via Slack and email.

The goal isn’t to use every feature. It’s to find one workflow that currently requires your manual attention and hand it off. Once that one runs on its own, the next one is easier to see.

That’s how Cowork becomes a system instead of a chatbot.

Recent related posts

I’m excited to host Jeff Morhous for this edition. Jeff is a senior software engineer and teacher at heart who spends his working hours solving software problems with AI tools, then dedicates the rest of his time teaching other developers to do the same through his newsletter, The AI-Augmented Engineer. I’ve been following his newsletter, The AI-Augmented Engineer, and I keep coming back to how clearly he breaks down AI coding concepts—whether he’s explaining what vibe coding actually is, showing how he vibe-coded an iPhone app he now uses every day, or comparing Codex CLI to Claude Code. His practical approach to helping developers ship faster with AI made him a natural fit for this series. I highly recommend subscribing to his Substack:

The AI-Augmented Engineer

Learn how to use AI tools to write better code, ship faster, and stay ahead of the curve

By Jeff Morhous

Today, Jeff is diving deep into Claude Code’s most powerful features: subagents, skills, and context files. Over to Jeff!

If you’re following AI buzz on the internet, you’ve probably already heard of Claude Code. Whether you’re a professional developer using it for work or a hobbyist using it for non-code agentic workflows, Claude Code has something for everyone, as evidenced by its ~5M weekly downloads.

While it’s simple to get started with the tool, getting the most out of it takes some extra effort as the Claude team has been rapidly launching new features over the last few months. In this post, I’ll walk you through the releases I found most impactful when collaborating with Claude Code:

• Subagents

• Skills

• Context files

Let’s start with subagents!

Understanding subagents in Claude Code

Subagents are custom AI assistants that specialize in particular tasks or domains. They have their own configuration and context, enabling them to tackle subtasks without cluttering the main conversation. When a problem matches a subagent’s expertise, Claude can delegate that task to the subagent, which operates independently and returns the result.

For instance, my code reviewer subagent (more on that later) is invoked when I request a code review, while my Terraform subagent is invoked when I make infrastructure changes. It’s like having a site reliability engineer on staff.

Why you should use subagents

Each subagent has its own context window, separate from the main session. This isolation preserves the main conversation’s focus while the subagent works on a specific problem. It is well established that you get better and more accurate responses when your coding agent’s context window is focused. Mixing a request to write an API endpoint with a later request to refactor some CSS is likely to yield worse results than keeping those conversations separate.

Subagents come with a custom system prompt and can be granted a limited set of tools, making them specialists in their particular problem set.

The benefits of subagents are many, but can be summed up as:

• Context preservation (don’t pollute your main context)

• Specialized expertise (can give specific and detailed instructions)

• Reusability (Can be used across projects or checked into Git)

• Controlled tool access (like shell commands)

Creating subagents

Subagents are defined in Markdown files, typically suffixed with .md. You can create them through Claude Code’s interactive interface (/agents command) or by creating files manually: Project-specific subagents live under the project’s .claude/agents/ directory, while user-wide subagents live under ~/.claude/agents/. If a subagent name exists in both places, the project version takes precedence.

Each subagent file begins with a YAML header defining a unique name and a description of its purpose. You can also specify the tools the subagent can use and the language model powering that agent.

The rest of the file is the agent’s system prompt. This prompt should instruct the subagent on how to perform its role. It may include step-by-step guidelines, checklists, or example behaviors. For instance, a “code-reviewer” subagent might be defined as follows:

---

name: code-reviewer

description: Expert code review specialist. Proactively reviews code for quality, security, and maintainability. Use immediately after writing or modifying code.

tools: Read, Grep, Glob, Bash

model: inherit

---

You are a senior code reviewer ensuring high standards of code quality and security.

When invoked:

1. Run git diff to see recent changes

2. Focus on modified files

3. Begin review immediately

Review checklist:

- Code is simple and readable

- Functions and variables are well-named

- No duplicated code

... (etc)

Claude Code offers a handy interactive menu via the /agents command to manage subagents. Running /agents in the Claude terminal opens a UI where you can view all available subagents (built-in, user-level, project-level), create a new one with a guided wizard, edit their configuration (including tool permissions), or delete them. This is the recommended way to create/edit subagents, as it ensures proper syntax and lets you easily pick from available tools.

Subagent files can also be managed manually. For example, to create a new project subagent, you’d create a Markdown file under .claude/agents/. The YAML frontmatter and content can be written by hand or generated by Claude.

You can find implemented subagents for inspiration in this repository.

Different ways to invoke subagents

Now that you know how to make subagents, you’re probably curious about how to actually use them.

The first and easiest is to explicitly invoke a subagent. Do this by explicitly calling your subagent as follows:

> Use the spec-request-spec agent to write request specs for the UserController

The second way is to rely on Claude to pick an appropriate subagent, similar to how tools are being invoked based on tools’ descriptions. It will do this by matching your prompt/query against the descriptions of available subagents. Similar to tool use, good agent descriptions increase the odds of proper automatic invocation.

Behind the scenes, when a subagent is invoked, Claude starts a fresh context for that subagent using its system prompt. The subagent may then use tools (as allowed), produce an answer, and perform actions. Once done, the conversation with the subagent ends, and Claude returns to the main session, freeing that context window’s tokens. Because subagents start with a clean context each time, they might introduce some latency as they gather any needed information (for example, re-reading relevant files) to carry out their task. The key benefit is that your main session’s context remains free of that transient detail, enabling longer, cheaper, and faster overall interactions.

Best practices for using subagents

1. Scoped - design narrow, focused subagents. Scoped agents are more predictable and performant.

2. Detailed - be as specific as possible about the agent’s procedure, style, and constraints in the subagent’s Markdown content,

3. Tracked - store subagent files (especially project-level ones) in your repository so that your team can use them and improve them over time.

4. Assisted - use Claude’s /agents CLI workflow to have Claude draft a subagent’s initial version

By thoughtfully creating subagents and following these practices, you can offload many specialized tasks from the main Claude Code context, leading to cleaner interactions and more effective AI assistance in your development workflow.

My most used subagent is a code reviewer. I explicitly spin off this subagent so I can get feedback on the changes in my branch before sending it to my peers. It’s saved me from tons of “nit” comments or embarrassing typos.

✨ AI Tidbits has partnered with Anthropic to provide premium members with $500 in Claude API credits, plus an additional $800 in credits across other leading AI tools and APIs including Hugging Face, Deepgram, and Vapi. Many readers expense the paid membership from their learning and development education stipend.

Upgrade to Premium

Defining agent skills

While subagents are like specialized personas, Agent Skills are more granular capabilities that Claude can draw upon. Skills package up instructions, examples, and even code or data that help Claude perform specific tasks on demand.

If there’s something that is in your CLAUDE.md that is only relevant to a small fraction of queries, turn that instruction into a skill. If there’s something in your day-to-day prompts that could benefit from a super clean context or has a tendency to fill up your main context, put it in a subagent.

An agent skill is a folder on your filesystem that contains a SKILL.md file (with instructions and metadata) and optional supporting files (scripts, reference docs, templates, etc.).

They allow you to extend Claude’s functionality in a modular way. For example, you might create a skill for “SQL troubleshooting” with instructions and scripts for database queries. Once the skill is set up, you no longer need to prompt Claude with those instructions every time. Claude will autonomously load the skill when needed. This reduces repetitive prompting and can combine multiple skills to handle complex tasks.

Every skill resides in its own directory named after the skill, under either your user or project skills folder:

• Personal skills (locally, only for you) are stored in ~/.claude/skills/<skill-name>/SKILL.md. These are loaded for any project you use Claude Code in.

• Project skills (pushed to Git, shared with a team) are stored in .claude/skills/<skill-name>/SKILL.md within the project directory. These can be checked into git so all team members can access them.

The main file SKILL.md in each skill directory defines the skill. It has a YAML frontmatter for metadata and a Markdown body for the instructions:

---

name: your-skill-name

description: Brief description of what this Skill does and when to use it

---

# Your Skill Name

## Instructions

Provide clear, step-by-step guidance for Claude.

## Examples

Show concrete examples of using this Skill.

Don’t forget that this skills folder can also contain additional files that would help Claude with this skill. If you have an Excel file of financial data you’d like the skill to reference, put it here! If you have a PDF with diagrams describing how something works, it belongs here, too. Anthropic even suggests putting examples as files and suggests Markdown as an appropriate format.

You can list all currently loaded skills by using the slash command in the CLI. In practice, since skills are automatic, the way to test a skill is to pose a query that should trigger it. For example, after creating a “PDF processing” skill, you can ask Claude something involving PDFs to see if it uses the skill. Claude’s response often indicates when it’s using a skill (you might see it mention reading the skill file in the conversation, especially if running in debug/verbose mode).

My favorite skill is for consistent frontend design. I give brand colors, font choices, and other UX specifications in a frontend design skill so any changes Claude makes to my views are aligned with the existing patterns. This saves me some time and keeps my meta CLAUDE.md file from having too much extra context.

Using CLAUDE.md effectively

Claude Code heavily leans on a context file named CLAUDE.md, which provides persistent background information and guidelines for your project. This file is automatically loaded into Claude’s context every time you start a session in that project directory (or at global scope), so you don’t have to repeatedly remind the AI of fundamental details about your project or preferences. Essentially, it’s a way to “inject” important context or rules before any conversation begins.

A context file is where you put fundamental project knowledge, constraints, and style guidelines that you want Claude to always be aware of. Think of it like documentation or notes that are always open to Claude.

You can even start your CLAUDE.md with the /init slash command, but don’t forget to review it before moving forward.

By placing project descriptions, architecture breakdowns, style conventions, and important requirements in CLAUDE.md, you ensure Claude Code always “remembers” this context, leading to more relevant and accurate assistance.

Claude Code is smart about where it looks for context files. It supports multiple CLAUDE.md files in a hierarchy. If present, the global context file is loaded for all sessions (your user-level default context).

The project context file in the current working directory (usually your repository root) named CLAUDE.md is loaded if present. You can also use CLAUDE.local.md in the project directory if you want a version that isn’t checked into git.

If you are working in a sub-folder of a larger repo, Claude will also load any CLAUDE in parent directories up to where you launched it. This is especially useful for monorepos or layered projects. Conversely, Claude can load files from subdirectories when relevant. For example, if you start at the repo root and ask about code in a given directory, and that directory contains its own CLAUDE.md, Claude will pull in that subfolder’s CLAUDE.md content if needed.

What will you build with Claude Code?

Claude Code really pushes an agentic programming model. This is incredibly useful, but comes with a learning curve. Enabling the use of specialized subagents, on-demand skills, and persistent context gives you an edge when tackling complex coding tasks. By understanding how these pieces work together, you can dramatically enhance your productivity and code quality.

If you want more tips on using Claude Code (or other AI tools for software engineers), we’d love to have you as a reader over at The AI-Augmented Engineer.

The AI-Augmented Engineer

Learn how to use AI tools to write better code, ship faster, and stay ahead of the curve

By Jeff Morhous

Recent posts on coding better with AI:

Each month, I'll share my top-performing LinkedIn posts, bringing you the best of AI straight from the frontlines of academia and industry.

As a frequent LinkedIn contributor, I regularly share insights on groundbreaking papers, promising open-source packages, and useful tools for folks collaborating with AI.

Over the past month, I’ve focused on exploring advanced coding workflows powered by Claude Code and open-source task orchestration tools. This post covers everything from DeepWiki's instant repo querying to Anthropic’s subagent ecosystem, Claude Code best practices, and structured agent workflows with Task Master AI.

To close things out, I also highlight two powerful tools from Google and Mistral for document parsing, which bring new levels of accuracy and traceability to text extraction.

Whether you're not on LinkedIn or simply missed a post, this monthly roundup ensures you stay informed about the most impactful AI news and innovations.

Recent posts on coding with AI

(1) DeepWiki

One of the most underrated AI coding tools released this year has become an essential part of my coding workflow.

DeepWiki, from the team behind Devin the coding agent, turns any GitHub repository into an instant wiki. Replace github.com with deepwiki.com in any repo URL and start asking questions without digging through files.

I now use it for:

1. Onboarding to unfamiliar codebases - targeted explanations with direct file links

2. Understanding implementation patterns - authentication flows, state management approaches

3. Evaluating open-source projects - licensing, security posture, maintenance status

4. Environment setup - getting exact commands and dependencies with citations

5. Building context for AI coding agents - structured summaries and architectural overviews

Every answer includes clickable, line-level citations that link back to source files. No hallucinated summaries, just grounded responses tied to actual code.

The tool integrates directly into Claude and Cursor via a free MCP server, making it queryable within your existing workflow.

I've documented 8 specific use cases with examples in a detailed breakdown of how I integrate DeepWiki into my development process https://www.aitidbits.ai/p/deepwiki

(2) Claudia - Manage Claude Code easily

Claude Code just got its first serious GUI.

A two-month-old open-source tool called Claudia turns Claude Code into a full-featured desktop environment for agent-based development with custom agents, usage tracking, session versioning, and a visual project browser that actually makes your ~/.claude directory usable.

Key features:

1. Project + session management – browse, resume, and diff past sessions across projects, with smart search and visual timelines

2. Agent creation – build persistent Claude agents with custom prompts, sandboxed permissions, and background execution

3. Usage tracking – real-time analytics dashboard showing cost per model/project, usage history, and exportable data

4. MCP support – manage your Model Context Protocol servers from a dedicated UI, with easy import from Claude Desktop

5. Markdown support – edit, preview, and organize CLAUDE.md files across projects with live rendering and syntax highlighting

Under the hood, Claudia runs on Tauri and supports multi-process execution for non-blocking agent runs.

Claudia makes Claude Code accessible for developers who've been hesitant about command-line AI tools or struggled to track Claude Code sessions across projects.

(My recent approach changed from Claudia + Cursor to Claude Code + Task Manager, but Claudia is still useful for the CLI haters).

GitHub repo https://github.com/getAsterisk/opcode

(3) Anthropic’s tips for using Claude Code

The Claude Code team just revealed how they responsibly merged 22,000 lines of AI-generated code into production.

Their breakthrough? They stopped treating AI like a magic wand and started managing it like you would any capable but inexperienced team member.

Here are the five best practices they shared for "vibe coding" in prod:
(1) Be Claude's product manager - spend 15-20 minutes collecting requirements, exploring the codebase, and building a plan together before letting the AI execute. Just like you wouldn't tell a new hire "build this feature" without context.

(2) Focus on leaf nodes, not core architecture - use AI for end features and components that nothing else depends on. Protect your system's trunk and branches where tech debt would be catastrophic.

(3) Design for verifiability - create systems with easily verifiable inputs/outputs and stress tests. You need to validate correctness without reading every line of generated code.

(4) Prepare for the exponential - AI can handle ~1-hour tasks today, but that capability doubles every 7 months. Next year, it'll tackle day-long projects, then week-long ones. If you insist on reviewing every line of code, you'll become the bottleneck.

(5) Know enough to ask the right questions - You still need technical judgment to guide the AI safely. The vulnerabilities in vibe-coded apps come from people who can't distinguish between what's dangerous and what's safe.

The bottom line: we're moving from individual contributors who understand every line to managers who understand the system. The question isn't whether this will happen, but whether you'll be ready when it does.

Full talk

(4) Claude Code Subagents

Claude Code now supports custom subagents, and a new open-source site makes it dramatically easier to start using them.

Claude Code's sub-agent feature lets you delegate to specialized AI experts instead of relying on one overwhelmed assistant. Each subagent operates within its own context window and focuses on its own expertise, much like having a full development team where every member excels in their specific domain.

This new site features 30+ prebuilt Claude Code agents, from UX Optimizer to System Architect to User Researcher. Each is designed to handle a specific task in your workflow. Just click, copy the prompt, and deploy.

These agents coordinate automatically. Ask Claude to "build a secure payment feature" and watch the system architect design the API, the security auditor validate the implementation, and the test generator create comprehensive coverage - all working in parallel.

No more crafting detailed system prompts or figuring out tool permissions - just copy-paste the configurations you need and integrate them in seconds.

Website https://www.subagents.cc

(5) Claude Code tips

Anthropic just shared how their teams actually use Claude Code internally, revealing how frontier labs operate at the cutting edge. An interesting peek behind the scenes.

I expected the usual suspects: debugging, code reviews, boilerplate generation. But applications go far beyond typical developer workflows. Their lawyers built phone tree systems. Marketing teams generate hundreds of ad variations in seconds using specialized sub-agents that process CSV files. Data scientists without TypeScript knowledge are building complete React applications for ML model visualization.

The performance gains are substantial: security engineers reduced debugging time from 15 minutes to 5 minutes by feeding Claude stack traces during production incidents. New data scientists become productive on complex codebases immediately rather than spending weeks learning architecture. Research time for unfamiliar ML functions dropped by 80%.

What's particularly notable is how this shifts organizational dynamics. Product engineers now tackle bugs in unfamiliar codebases without depending on other teams. The Growth Marketing team built agentic workflows that would traditionally require dedicated developer resources.

Claude Code is not only for coding. My observation: we're seeing the early manifestation of a fundamental change in how companies operate. That has been the vibe for some time, but now we actually see this in practice.

Full piece https://www.anthropic.com/news/how-anthropic-teams-use-claude-code

(6) Task Master AI

Read more

In this post, I break down the shift from desktop to cloud-based coding agents, exploring what makes them different, how they fit into real-world development workflows, and where each leading tool stands today. Whether you’re exploring Devin, Codex, Jules, Factory, or Cursor Background Agents, this guide will help you understand how they work, their strengths and trade-offs, and how to get the most out of them.

A NotebookLM-powered video podcast summarizing this post

Keep exploring this post:

Open in ChatGPT

Open in Claude

Agent-assisted coding is evolving quickly. Tools like Cursor, Windsurf, and Claude Code are already part of many developers’ workflows. These desktop agents run locally and rely on continuous back-and-forth: Developer drafts a coding task prompt → Coding agent generates code → Developer asks for changes/fixes → Coding agent implements change → You commit local changes as part of a pull request.

This pair-programming style boosts productivity, but it doesn’t scale. The interaction is synchronous: you must constantly steer the agent from the initial coding task prompt to creating a pull request. Running multiple coding agents in parallel feels like managing multiple junior developers simultaneously.

Real-world engineering teams work differently.

Enter cloud agents, asynchronous coding agents that better resemble a dev on your team: You assign a task → Cloud agent spins up its own environment in the cloud (as if it had its own laptop) → Cloud agent makes changes → Cloud agent opens a pull request for you to review.

You can request and merge changes once the code meets your standards. Some even integrate with Slack and other collaboration tools such as Linear and GitHub, further streamlining the development and CD/CI cycles.

In 2025, the line between desktop and cloud agents is blurring. Cognition, the creator of Devin, the web-managed cloud agent, acquired Windsurf, a Cursor-like IDE that acts as a desktop agent. Cursor, on the other hand, now offers background agents that run asynchronously both locally and on the web. Factory AI (cloud agent) offers a downloadable bridge that enables asynchronous workflows in local environments. Google’s Jules (cloud agent) just graduated out of Beta to complement Gemini desktop CLI (desktop agent), mirroring OpenAI’s Codex (web) and Codex CLI (desktop) approach.

The path for coding alongside AI is set: as models and tooling improve and best practices solidify, coding agents are shifting to asynchronous-first workflows. To clarify, autonomy isn’t a “web” feature, it’s an agent capability. It just so happens that, today, most fully autonomous agents are delivered as web-based tools.

In this post, I’ll walk you through what it’s like to work with each of the leading cloud agents, including a screen recording of my workflow so you can see how the interfaces look and behave in practice. Whether you’re curious about what these agents can actually do or trying to figure out which one fits best into your development workflow, this guide is for you. I’ve also included a comparison table at the end that makes clear which tools truly stand out.

Evaluation framework

Each agent was evaluated across four criteria:

1. Overall experience - onboarding flow, coding UX, working process smoothness (planning → execution → testing), and pull request clarity.

2. Team integration - how well the agent fits into real workflows: taking tasks, opening solid pull requests, addressing feedback, and communicating through platforms like Slack.

3. Autonomy - the level of independence from assignment to pull request: does the agent require step-by-step guidance and close supervision, or can it deliver end-to-end?

4. Cost - pricing model and the actual cost of completing the benchmark task.

To evaluate the agents, I gave each one the same benchmark assignment: add recurring task support to a lightweight to-do app repository:

Add support for recurring tasks. Users should be able to pick from daily, weekly, or monthly recurrence options when creating or editing a task. When a recurring task is marked complete, create the next occurrence immediately with the due date shifted by the chosen interval. Keep changes simple.

I deliberately chose a more straightforward task that all agents naturally completed successfully. The goal of this post is not to benchmark their performance, but to evaluate the experience of working with them. In future posts, I plan to conduct more complex evaluations to compare these agents on challenging, real-world tasks.

Become a premium member to access the full LLM Builders series, $1k in free credits for leading AI tools and APIs (Claude, Hugging Face, Deepgram), and editorial deep dives covering AI coding and voice agents. It's also a great way to show your support :)

Many readers expense the paid membership from their learning and development education stipend.

Upgrade to Premium

The results

Devin

Overall experience

Setup took minutes: sign in, connect GitHub, and Devin is ready to go. It scanned the codebase, created a confident plan, executed the task, and opened a well-structured pull request, all autonomously.

The experience felt like pair programming with a senior engineer: you see the shell (the command line for running code), VS Code (where code is edited), and a browser (for testing), all updating in real-time.

The pull request included a clear summary, test plan, and even a diagram, making review easy.

Devin handled feedback directly through GitHub, just like a real teammate. It felt like collaborating with someone who not only ships quality code, but also knows how to get it merged.

Team integration

Devin slots naturally into team workflows. On GitHub, you can review its code or ask it questions exactly as you would with a colleague. It also integrates with Slack, Linear, and Jira, allowing you to tag it in a thread or assign it to an issue.

Devin can also connect to MCP servers, enabling seamless connections to external tools and internal systems. Through its MCP server, Devin can pull in structured context from documentation, analytics, and monitoring platforms like Notion, Sentry, and Datadog. This makes it easier for Devin to act with deeper awareness of your infrastructure and business logic.

Autonomy

Devin is fully autonomous: once you assign a task, it produces a pull request without further input. For web apps, it can even run and test the app itself. This autonomy is powerful because it allows you to run multiple coding agents that don’t require supervision. The downside is that it can go off-track if your prompt and intentions are vague, wasting time and tokens. Fortunately, Devin has substantially improved since the last time I tested it in December, making it autonomous and useful.

Cost

Devin’s pricing is structured in Agent Compute Units (ACUs). Those units represent the work done by Devin in a single session. Steps like planning, gathering context, running code, or using the browser all consume ACUs.

Each ACU costs $2.25. My benchmark task used 3 ACUs, which comes to about $6.75. That’s steep for a simple job. This novel ACU model also introduces friction. Since no other coding agent uses it, there's no mental benchmark, making it harder for developers to estimate costs. The lack of transparency creates hesitation that hinders adoption, especially when simpler pricing models are the norm.

How to get the most out of Devin

(1) The Prompt Improvement Button

Devin has a built-in prompt improver that refines your instructions before it starts. Running prompts through it clarifies intent and removes ambiguity, which helps Devin produce more accurate, review-ready pull requests.

(2) Leverage Devin’s Knowledge capability

Knowledge lets you onboard Devin with your project’s context, just like you’d ramp up a new engineer. It serves the same purpose as coding agents context files such as cursor.md or AGENTS.md, but with structured triggers built in.

Add information in small pieces, group it in folders, and link it to repositories with triggers so Devin knows when to apply it. Store anything you would want an engineer in your team to know: coding standards, workflows, deployment steps, bug fixes, etc.. Once added, Devin recalls and applies it automatically. More tips covering Knowledge here.

(3) Devin Playbooks, à la Claude Subagents

Playbooks are reusable prompts for recurring tasks. Instead of re-explaining a process to Devin every time, create a playbook and ask Devin to use it. It’s like showing a teammate how to do something once and having them write it down so they never ask again.

(4) Connect Devin to Slack/Linear/Jira

Plug Devin into your team’s task management workflow: Assign it issues or tag it in threads. It will pick up the task immediately and get to work. That is especially useful when on the road, as you can tag Devin in a Slack conversation and ask it to take a first (and last?) pass at fixing a bug or implementing a feature.

Recent posts on coding better with AI

OpenAI Codex

Overall experience

Codex is built into ChatGPT, so setup is quick: load your repo, assign a task, and it gets to work. It scans the code, plans, runs tests, and opens a pull request. Also, as of last week, Codex can run in your IDE of choice as an extension, supporting Windsurf, VS Code, and Cursor. You can use it locally or delegate tasks to the cloud.

The interface is minimal, with a shell view and collapsible logs. When complete, Codex provides a concise summary with direct code references to expedite the review process.

Team integration

Codex doesn’t play well with existing tools such as Slack, Linear, and Jira, which is a major downside given that many teams use Slack to discuss and assign work, and GitHub is the familiar interface for code reviews.

Autonomy

Codex is fully autonomous: once assigned a task, it works in its isolated cloud environment and delivers a complete pull request within minutes without requiring further prompting. Similar to Devin, that could be a neat feat if the agent is capable enough, but dangerous if vague coding tasks lead to poor generated code. For our simple task, Codex performed well enough.

Cost

Codex is included with ChatGPT Plus or Pro, so there is no extra charge beyond your subscription. That said, usage limits are not publicly disclosed, which can be a red flag for many teams that require a reliable coding agent with transparent rate limits.

How to get the most out of Codex

(1) Generate multiple responses simultaneously, choose the best one

Codex’s Best of N feature allows you to generate several independent solutions in parallel for the same task. This lets you quickly explore different approaches and select the one that best fits your needs, without adding time to your workflow.

(2) Enable internet access when needed

By default, Codex runs offline after setup, so it cannot look up documentation or install new packages. Enabling internet access solves this issue, but it should only be used when the task requires it, as it carries security risks. For instance, an attacker could slip in a malicious command that Codex executes, unintentionally leaking sensitive data.

(3) Tag Codex in pull requests

Tag Codex for questions or reviews via @codex <question> or @codex review. You can also tag it for changes, but that spawns a new task with a separate pull request you’ll need to merge back into the original.

Google Jules

Overall experience

Setup was quick: I signed in with Google, linked GitHub, and Jules was ready. I provided the task and it then scanned the codebase, generated a detailed plan, and executed it step by step until a pull request was opened. The interface, structured around the plan, made progress easy to follow with expandable diffs, similar to Claude Code’s and Cursor’s recently released planning feature.

However, the pull request’s description was lacking. For example, it stated “This change adds support for recurring tasks…”, which reads more like a product note than a proper description of a technical feature. I expected at least one section covering the technical components added/changes to facilitate a more efficient and easier review. Code review also felt unnatural. Similar to Codex, I couldn’t review the pull request as I would on GitHub: all reviews had to happen in Jules, where I could only leave a single block of feedback instead of commenting on individual lines. While the grouping of changes by the plan’s action items in the interface made diffs easy to follow, the process was rigid compared to reviewing a colleague’s PR.

Team integration

Jules does not fit smoothly into team workflows. On GitHub, you cannot review its code or collaborate with it the way you would with another developer. It also lacks integrations with tools like Slack, Linear, or Jira, leaving its interface as the primary means of interaction. As a result, Jules feels separate from the normal channels teams rely on to collaborate.

Autonomy

Jules is semi-autonomous. It generates an implementation plan that you approve in the beginning. If you don’t respond, the plan auto-approves and executes, completing the task end-to-end without requiring your input, unless it encounters roadblocks or needs clarifications, similar to how Claude Code prompts the user for input.

Cost

Jules is part of Google’s AI package. It offers the following tiers:

• Free tier - 15 tasks per day, 3 concurrent tasks

• Pro - 100 tasks per day, 15 concurrent tasks

• Ultra - 300 tasks per day, 60 concurrent tasks

The free tier makes it easy to get started. The pricing model is transparent and predictable, as it remains consistent regardless of task complexity and does not depend on unpredictable factors. For developers, this makes Jules straightforward to adopt and scale.

How to get the most out of Jules

(1) Interactive Plan mode

Start tasks using the Interactive Plan mode. Jules will then scan the codebase, ask clarifying questions, and create an implementation plan you’d approve before execution. This prevents ambiguity and ensures the output matches your intent, and is already the way I code nowadays. Feels like a junior developer confirming requirements before writing code.

(2) Configure environment setup

If a repo requires setup commands such as dependencies or environment variables, define them upfront. Jules will run them automatically when working with that repo, keeping environments consistent.

Factory AI

Overall experience

Factory is built around the concept of “Droids”: autonomous agents purpose-built for different roles across the software development lifecycle (Code, Reliability, Knowledge, Product). Each Droid comes with its own architecture, memory, and tools, and can operate independently or in parallel. Unlike traditional coding assistants, Droids are designed to own and execute tasks end-to-end, making Factory feel more like a full-stack engineering team than a co-pilot, similar to the idea behind Claude Code's Subsagents.

When using Factory, it’s clear that the company is focused on enterprise users, rather than indie developers, which could hinder the organic bottom-up growth that Claude Code and Cursor benefit from. For instance, you must enter credit card details for a trial with no way to pre-cancel. Pricing is also somewhat opaque and tied to token usage: $40 for 20 million tokens.

Factory’s most significant drawback, however, is the indexing process. For our small benchmark repository, indexing took anywhere from several minutes to multiple hours. That’s a considerable delay just to get started. In a developer world optimized for instant feedback loops and low-friction experimentation, this delay feels off.

On the other hand, Factory shines in its coding cycle: it builds a clear to-do list, asks intelligent and clarifying questions, and executes with visible reasoning and file-by-file diffs. The pull request is detailed and reads like something a senior engineer would write. It also provides the broadest set of integrations, allowing you to consume relevant context from popular tools such as Notion, Google Drive, and even incident management tools like Sentry and PagerDuty.

Additionally, to Factory’s credit, user experience appears to have become a recent priority. When I first used it back in March, the interface was cluttered and overwhelming: too many panes, not enough clarity. During my coding session for this article, however, the redesign was substantially better: the layout is cleaner, more focused, and thoughtfully organized around the key decisions and information needed at each stage.

Team integration

Integrations is where Factory differentiates itself, showcasing again its enterprise focus. It can consume context from your team’s internal knowledge systems: Slack, Linear, Jira, Notion, Google Drive, Sentry, and PagerDuty. Such integrations infuse the coding agent with context beyond the project’s repository, which improves the agent’s performance.

These integrations allow Factory to enrich its understanding of your engineering workflows far beyond what's available in the repository. However, these integrations are read-only: Factory can ingest context from these platforms but cannot be actively directed through them. You can’t, for example, tag Factory in a Slack thread or assign it a Linear ticket and expect it to take action, unlike agents like Devin.

Cost

Factory offers a 14-day trial, after which pricing starts at $40 per month for 20 million tokens. Our task consumed ~330k tokens. As a full-time engineer, you’ll likely burn through this quota quickly–our simple feature alone ate through over 1.5% of the monthly allowance.

Autonomy

Factory is semi-autonomous and often requires your input. It avoids making assumptions, it often asks clarifying questions before starting, and seeks approval before taking actions, such as creating a pull request. By default, it will not create branches or commit files without your approval, though you can disable this safeguard.

How to get the most out of Factory

(1) Use Factory Bridge

Bridge is a secure connector that links Factory's cloud platform to your local machine. It enables running CLI commands, managing local processes, and accessing local files directly from Factory sessions. Tip: use it within an isolated environment (e.g., Docker) for safe and optimal results. I used Bridge when I couldn’t access my laptop or wanted to split tasks between Factory and Claude Code, saving Factory tokens while running both agents in parallel.

(2) Use a remote machine

When local access is not needed, connect Factory to a remote machine. It still grants full command and workflow access without requiring you to touch your computer.

Cursor Background Agent

Overall Experience

Getting started is easy for existing Cursor users: simply submit a task and select “Send to Background”. On the web, log in and paste your coding prompt.

You can watch the agent’s progress by connecting to its virtual cloud environment (“Open VM”), which mirrors a live coding session. Once complete, you get a change summary and file diffs in both desktop and web.

The pull request description is barebones, often limited to a single sentence. It lacks a detailed context that would streamline reviews. Code review, however, feels seamless: you can comment directly on GitHub, tag the agent, and get a response in-line, just like working with a human teammate.

Team integration

Cursor integrates directly into Slack and Linear, so you can tag it in threads or assign it to issues.

Autonomy

Cursor’s Background version is fully autonomous. Once you assign a task, it analyzes the codebase, executes the plan, and opens a pull request without requiring user input.

Cost

Background agents are billed at the API rate of the model you choose, which is affordable with models like gpt-5-high. The task I ran came at 8¢. Token-based pricing is inherently unpredictable, but that’s already the norm with the popular Claude Code and Cursor desktop agents.

How to get the most out of Cursor Background Agent

(1) Add a .cursorrules file to your repositories

Cursor’s best practices also apply to background agents. Make sure every repository you use includes a .cursorrules file, just as you would when working locally (you can use my recently released tool to generate one).

(2) Connect Cursor to Slack or Linear

If your team uses either tool, integrate Cursor so you can assign it issues or tag it in live discussions. Whether it is a bug in Slack or a ticket in Linear, the agent can pick it up immediately and start working.

More tips here​​ https://www.aitidbits.ai/p/sahar-ai-coding

Choosing the right coding agent

We’re just getting started with coding agents

All of these tools are still in their early stages. We can expect them to evolve quickly—I had to update my post twice over the span of two weeks due to new releases.

Just as importantly, the paradigm of working with autonomous agents is still taking shape. Tools like Claude Code’s Subagents and newcomers like Conductor and Task Master hint at what’s to come. In future posts, I’ll dive deeper into each of the tools reviewed here. Subscribe to follow along as I learn how to collaborate with this new generation of coding agents.

In this post, I break down how I use DeepWiki - my go-to tool for understanding unfamiliar codebases, spinning up dev environments, and generating context for coding agents like Claude and Cursor. Whether you're evaluating an open-source repo, onboarding to a new project, or building an AI-powered dev tool, DeepWiki can save you hours.

Note: This is not a sponsored post or paid collaboration. I use DeepWiki in my day-to-day workflow and wanted to share how it's been useful.

A NotebookLM-powered podcast episode discussing this post:

We are generating more code than ever. With LLMs like Claude already writing most of Anthropic’s code, the challenge is no longer producing code, it is understanding it.

DeepWiki, from Cognition, the team behind Devin, the AI software engineer that went viral with its Fiverr demo in March 2024, turns any GitHub repository into an instant, navigable wiki.

Point it at a repo and start asking questions without digging through files or reading every line. Just replace github.com with deepwiki.com to spawn a wiki page for a repository:

https://github.com/Dicklesworthstone/claude_code_agent_farm → https://deepwiki.com/Dicklesworthstone/claude_code_agent_farm

This is a lightweight field guide to the tool that has become my must‑have coding companion.

Recent posts highlight

How DeepWiki works

• Public vs. private - querying public repos works out of the box. For private repos, you’d need to sign in with a (free) Devin account.

• Fast vs. Deep Research modes - Fast mode answers instantly from the code graph. Deep Research spends extra cycles reading across files to provide higher-confidence, multi-hop answers.

• Grounded answers - every answer includes clickable, line‑level citations back to the source files, so you can jump straight to the code and avoid hallucinated summaries.

Use DeepWiki via web or AI IDE

You can use DeepWiki by pasting a GitHub URL on deepwiki.com or by plugging it directly into your AI coding environment using the official DeepWiki MCP server (my preferred way).

The DeepWiki MCP server requires no authentication and is supported natively by Claude and most AI IDEs, such as Windsurf and Cursor. Just add the MCP server to your config (instructions here).

This turns DeepWiki into a live, embedded research sidekick: always-on, context-grounded, and queryable directly within your workflow.

DeepWiki is how I read other people’s code now

(1) Evaluating an open-source project

Engineering velocity has exploded, and with it, the number of open-source libraries released every day.

Before pulling in a new library, I run a quick eval loop: is it actively maintained? How’s the security posture? Any data sent to third parties? Does the license play well with commercial use?

With DeepWiki, I get these questions instantly answered, linking me to the exact configuration, network calls, and license terms, so I can make a quick go/no-go decision.

(2) Quickly setting up new environments

For public or private repos, ask “how do I run this locally?” and you’ll get the env setup, required services, and dependency graph with citations to README, Dockerfile, and scripts, so you can hit the ground running.

(3) Borrowing implementation details

Suppose you find a clever mechanism in another repository, such as an authentication flow or a clever way to persist state locally. In that case, you can ask DeepWiki to provide a Markdown cheat sheet: a breakdown of how it works, which files define it, and what it depends on. You can then drop that summary directly into Claude Code or Cursor as structured context and ask it to implement it in your project.

For instance, I needed to manage multiple coding agents via the terminal. I found a repo that orchestrated them using tmux. DeepWiki mapped the scripts and config, and within ten minutes, I had the same terminal layout running in my project.

(4) Creating custom onboarding guides

Treat it like a patient senior engineer. Ask targeted questions like “Can you walk me through how the queue processor handles retries?”, “What’s the data flow during user signup?”, or “I want to implement feature X - where should I begin?”, and receive tailored explanations with direct links to the relevant functions.

Become a premium member to access the full LLM Builders series, $1k in free credits for leading AI tools and APIs (Claude, Hugging Face, Deepgram), and editorial deep dives into key topics like AI Voice Agents. It's also a great way to show your support :)

Many readers expense the paid membership from their learning and development education stipend.

Upgrade to Premium

(5) Surfacing first contributions

New team or contributing to a new open-source library? Ask for “good first issues” based on TODOs, failing tests, flaky areas, or missing docs. DeepWiki surfaces approachable fixes and where to start reading.

(6) Navigating cookbook-style repositories

Some repositories are more like collections of examples than actual packages. Anthropic’s cookbook and Gemini’s cookbook are good examples. DeepWiki can help you find the example you need and even generate the code.

(7) Building context-aware coding agents

If you’re building a project or tool that requires understanding the context of a codebase: its structure, architecture, or coding style, DeepWiki can do the heavy lifting.

I built a tool called Sidekick that generates cursorrules.md and claude.md files: markdown summaries that coding agents use as context during generation. Instead of writing those summaries yourself, Sidekick uses DeepWiki to auto-generate them from the repo.

Since DeepWiki’s MCP API is free and open, you can plug it into any product or library that benefits from code awareness: onboarding flows, test generators, AI pair programmers, or anything else that needs a high-level map of the code.

(8) Reviewing and ramping up on pull requests

So your teammate opens a PR and asks for a review. You weren’t involved in the feature, and now you’re staring at a diff with no context. With DeepWiki, you can quickly ramp up. Just replace github with deepwiki in the PR URL to get a structured summary of the proposed changes. For example:

https://github.com/saharmor/simulatedev/pull/7 → https://deepwiki.com/saharmor/simulatedev/pull/7

DeepWiki helps you understand not just what changed, but how it fits into the broader codebase, saving time, reducing back-and-forth, and making you a better reviewer.

When to use DeepWiki

DeepWiki is now the first thing I reach for when I need to reorient quickly: implementing a new feature that touches unfamiliar parts of the stack, returning to a component I haven’t touched in months, or diving into a dense open-source repo.

Instead of grepping around, I skim the generated wiki, ask a few follow-up questions, and jump straight into the files that matter.

What I wish DeepWiki had

Two features I’d love to see:

1. Conversational sidekick mode - leave DeepWiki running next to your IDE and ask, “Where does this function get called?” or “How do I run the worker locally?” (I hacked a prototype last weekend that I plan to share soon).

2. Task-based onboarding - provide a repository and a goal (“fix this open issue”), and receive a step-by-step path through the exact files, functions, and setup commands needed to contribute.

Try it yourself at deepwiki.com

Each month, I'll share my five seven top-performing LinkedIn posts, bringing you the best of AI straight from the frontlines of academia and industry. This edition includes seven posts instead of five—there were just too many good ones to leave out!

As a frequent LinkedIn contributor, I regularly share insights on groundbreaking papers, promising open-source packages, and significant AI product launches. These posts offer more depth and detail than our weekly snippets, providing a comprehensive look at the latest AI developments.

Over the past month, I’ve been deep in the weeds of coding with AI: tinkering, prototyping, and writing about how coding with LLMs can go beyond vibe coding, making us engineers substantially more productive. This post covers six of my most popular LinkedIn posts on the topic, each packed with practical takeaways for both aspiring and experienced engineers. Plus, a bonus tip at the end: an underrated trick from Anthropic to reduce cost by 90% and latency by 50%.

Whether you're not on LinkedIn or simply missed a post, this monthly roundup ensures you stay informed about the most impactful AI news and innovations.

Post(s) published this month:

(1) Parallel AI pair-programming

Recently, I adopted a coding tip from the Anthropic team that has significantly boosted the quality of my AI-generated code.

Anthropic runs multiple Claude instances in parallel to dramatically improve code quality compared to single-instance workflows.

How it works:

1. One Claude writes the code, the coder - focusing purely on implementation

2. A second Claude reviews it, the reviewer - examining with fresh context, free from implementation bias

3. A third Claude applies fixes, the fixer - integrating feedback without defensiveness

This technique works with any AI assistant, not just Claude. Spin each agent up in its own tab—Cursor, Windsurf, or plain CLI. Then, let Git commits serve as the hand-off protocol.

This separation mimics human pair programming but supercharges it with AI speed. When a single AI handles everything, blind spots emerge naturally. Multiple instances create a system of checks and balances that catch what monolithic workflows miss.

This shows that context separation matters. By giving each AI a distinct role with clean context boundaries, you essentially create specialized AI engineers, each bringing a unique perspective to the problem.

(2) Claude ultra think

One extra word can unlock Claude’s hidden reasoning budget and give developers building with AI the planning superpowers.

According to Anthropic, Claude allocates compute tiers based on trigger words:
think < think hard < think harder < ultrathink.

Drop any of these at the start of a prompt and the model gives itself more “brain cycles” before answering. Perfect for discussions on architecture, API design, or edge-case analysis. I also use it when debugging an issue that the existing models (Gemini, o1) didn’t manage to solve.

It works in Cursor/Windsurf and the Claude web chat; no flags, no config.

Give it a try: open your next coding session, preface the prompt with 'think harder' or 'ultrathink' and see how Claude’s performance improves.

My recent post on coding with AI:

(3) Coding visual interfaces with coding agents

Most devs still eyeball CSS tweaks while it’s possible to achieve pixel-perfect UI with coding models like Claude and o3.

Screenshot-driven iteration works across o3, Gemini, and Claude (I’ve had the best luck with Claude). Process:

(1) Paste the design mock via clipboard, drag-drop, or file path

(2) Ask the model: “Implement this layout, screenshot the result, and compare it to the mock. Repeat until they match.”

(3) Watch it code → screenshot → diff → refine until the visual diff hits zero

Design-to-dev handoff shrinks from days to minutes. Frontend teams can A/B three layout variants before lunch, and PMs can solo build UI prototypes without opening Figma.

Try it: paste a screenshot/Figma design with the above prompt in your AI IDE of choice and let the loop run.

(4) Auto-generated MCP servers

One trick I often use and not many other AI builders know: you can now spin up an MCP server for almost any Mintlify-powered API with just two commands.

MCP (Model Context Protocol) servers are the missing layer that enables AI coding assistants like Cursor and Windsurf to generate reliable programs that interact with APIs through natural language, without needing manual integrations or risking hallucinated parameters and broken function calls.

Traditionally, setting up an MCP server meant custom-building one for each API. A tedious, manual process. Now, thanks to Mintlify’s new package, it’s effortless:

1. npm i mcp

2. npx mcp add [api subdomain] (for example, docs.bland.ai)

That’s it. The API you’re trying to work with becomes an MCP server. No custom code, no extra work.

You can test it with the Mintlify-powered Bland API docs to initiate phone calls programmatically.

(5) llms.txt

Most developers still use LLMs to write isolated functions. However, the real power of AI coding lies in making coding models interact reliably with APIs.

That’s where llms.txt comes in.

Inspired by robots.txt, llms.txt is a simple, standardized Markdown file that describes how a website or API works. It resides at the root of a site and distills documentation, endpoints, authentication flows, and usage examples into clear, predictable text. LLMs skip the cumbersome scraping, read the file, and instantly know how to call your API.

Why this matters:

1. Today, prompting an LLM to use an API is messy. Developers must manually write tool descriptions, guess parameter formats, and hope the model figures it out.

2. No HTML parsing or rate-limited from crawling websites

llms.txt provides a structured approach to eliminate guesswork and unlock a new era of API-driven AI coding.

To make it even easier, there’s now a full llms.txt directory, listing APIs and websites that already adopted the standard, including Anthropic, Eleven Labs, and Hugging Face https://directory.llmstxt.cloud

And if your website doesn’t have one yet, you can auto-generate it with Firecrawl's new llms.txt Generator API https://docs.firecrawl.dev/features/alpha/llmstxt

𝘞𝘢𝘪𝘵, 𝘪𝘴𝘯’𝘵 𝘵𝘩𝘢𝘵 𝘴𝘪𝘮𝘪𝘭𝘢𝘳 𝘵𝘰 𝘔𝘊𝘗𝘴? 𝘞𝘩𝘦𝘯 𝘵𝘰 𝘶𝘴𝘦 𝘵𝘩𝘢𝘵 𝘰𝘷𝘦𝘳 𝘔𝘊𝘗?

If you want AI agents to know how your API works and generate correct code, use llms.txt. If you want agents to use an API, set up an MCP server. Think of llms.txt as the knowledge base for AI coding, and MCP as the execution layer for live interactions.

(6) Test-Driven Development with AI

Read more

In this post, I’ll share the principles and tactics that helped me go from chaotic vibe coding sessions to consistently building better and faster with AI. Subscribe to get notified when the next post is published.

A NotebookLM-powered podcast episode discussing this post:

In today’s “vibe-coding” world, where tools like Cursor, Windsurf, Cline, and Claude Code can autocomplete an entire feature before your coffee cools, speed is no longer the bottleneck. Clarity is. Early on, I mistook these agents for magical refactor engines: give them a prompt, lean back, wait for perfect code. Instead, I got files rearranged beyond recognition, subtle bugs, and a creeping sense that I was pair-programming with an eager intern running on double espresso shots. Not great.

Through experimentation, failures, and continuous learning, I discovered a critical insight: treating your AI coding agent like a highly capable human pair programmer dramatically improves performance. Just as clarity and thoroughness are crucial when collaborating with human teammates, providing explicit context and structured guidance to AI coding agents is equally essential.

In this post, I’ll walk you through the principles and tactics that transformed my chaotic vibe coding sessions into a consistent, faster, and higher-quality AI-assisted workflow.

The first three tips are foundational. They’ll show you why a successful vibe coding session is roughly 80% planning, 20% execution.

#1 Wear the Product Manager hat

The single biggest unlock I’ve found is to treat the project the way a seasoned PM would—before the first line of code is generated. A couple of hours of purposeful “spec-ing” gives the AI (and yourself!) all the needed context and saves you days of refactors later.

Create a Product Requirements Document (PRD)

Start every project with a prd.md file in the root directory explaining what you’re building, why, the user flows, in-scope / out-of-scope items, and a short tech-stack overview.

I have a PRD template I follow for my projects and you should have one, too. To save time generating it, I often use ChatGPT’s built-in Whisper to dictate my raw notes and then ask it to transform those notes into a PRD using my template. I also ask ChatGPT to surface any missing parts or context in my PRD before copy-pasting the output into the project’s prd.md file.

Then, add a rule to .cursor/rules or .windsurfrules (more on this below), encouraging the AI agent to “always read prd.md before writing any code”.

Break the knowledge base into bite-sized docs

For most side projects, one prd.md file is enough, but once it grows, split it:

• app_flow.md - wire-frame-level tour of every page/endpoint and transitions from one page to another

• db_schema.md - canonical source of truth for tables, relations, enums

• tech_stack.md - chosen libs, versions, style guides, links to API docs

• implementation_plan.md -step-by-step build checklist

Organize these files within a project-docs directory. Update your AI agent's rules to include:

Refer to all documents in the /project-docs directory for context before proceeding with code generation.

This modular approach provides your coding agent with the much-needed context to build your project correctly. I’ve consistently seen how a well-structured and documented project-docs directory leads to faster and better coding.

Feed the agent real artifacts

Drag-and-drop your Figma export, Swagger spec, or PDF PRD right into the chat (Cursor, Windsurf, etc. can ingest files). The richer the context graph, the fewer guesses the model makes.

Remember: the AI is a bright but literal teammate

I spend a whole day up front writing the product doc, test flows, and API contracts.

By adopting a product manager's mindset and providing comprehensive, organized documentation, you set your AI coding agent up for success. This structured approach minimizes misunderstandings and streamlines the development process, allowing you to build more effectively and efficiently.

Become a premium member to access the full LLM Builders series, $1k in free credits for leading AI tools and APIs (Claude, Hugging Face, Deepgram), and editorial deep dives into key topics like AI Voice Agents. It's also a great way to show your support :)

Many readers expense the paid membership from their learning and development education stipend.

Upgrade to Premium

#2 Planning with frontier models

As models proliferate (Gemini 2.5 Pro, Claude 3.5, o3, o4, GPT-4.1), developing intuition for which model to employ when becomes crucial for efficiency. Think of your AI stack like a toolbox. Different tools for different jobs.

Most developers, including myself, use different models for various phases of the development cycle. For the planning phase, leverage advanced reasoning models like Claude 3.7 Sonnet or o3 to write the PRD and generate implementation plans. These models excel at complex reasoning and can produce comprehensive, well-structured documentation that serves as the foundation for your project.

Recently, I discovered Anthropic's "ultrathink" technique: appending this keyword to your prompt signals Claude to allocate more thinking budget to your request. This results in more thorough plans at the expense of higher latency, which is a worthwhile tradeoff for critical planning sessions.

For instance, when recently developing an evaluation framework for voice agents, I used Claude 3.7 to architect the entire system. I prompted:

Based on these project requirements and the existing evaluation metrics in my /project-docs folder, generate a comprehensive implementation plan for building a voice agent evaluation framework that simulates conversations and scores performance across multiple dimensions. Include conversation flow design, metrics calculation logic, and reporting structure. ultrathink

The resulting implementation plan was exceptionally thorough. It proposed a conversation simulator with configurable user personas, identified seventeen distinct evaluation metrics (including non-obvious ones like 'recovery from misunderstanding'), suggested a weighted scoring system that accounted for business priorities, and outlined a modular architecture allowing for easy addition of new evaluation criteria as voice agents evolve.

After reviewing and refining the initial plan, addressing any missing pieces or gaps the LLM overlooked, I transition to different models for implementation: Gemini Pro 2.5 for most code generation, with Claude 3.5 and GPT-4.1 reserved for coding tasks that are local, e.g. generating/fixing a small function. Claude 3.7 and similar advanced models tend to overextend, introducing extra suggestions that require additional cleanup, so I avoid them for scoped changes.

#3 The building block approach - break tasks into atomic components

Rather than overwhelming yourself and your AI pair programmer with an entire project at once, think of your development process as assembling LEGO blocks. Each component should be well-defined, independently testable, and have clear inputs and outputs.

Start a fresh chat with your AI agent (⌘ + I) for each component to maintain focus and prevent context contamination. This approach not only helps the AI generate more precise code but also makes debugging and integration significantly easier.

For relatively self-contained components, I've found tremendous success using a separate development environment:

1. Open a new Cursor instance in an empty project directory

2. Copy only my project-docs folder into this environment

3. Ask the AI to build just that new component I need

4. Test the component thoroughly in isolation

5. Integrate the polished component back into the main project

A recent example from my voice agent evaluation platform mentioned earlier: I needed a component to transform raw JSON evaluation results into an interactive HTML dashboard displaying performance metrics. Rather than complicating matters by building within the already complex codebase, I isolated this visualization task entirely by generating the code in a new isolated environment and copying it back once done.

This isolation technique works especially well for visualization components, data transformation utilities, API clients, custom algorithms, and reusable UI elements.

Remember: the smaller and more focused the task, the higher the quality of the AI-generated solution.

#4 Use git for version control as a safety net

Git serves as an indispensable safety net, allowing you to track changes, revert to previous states, and understand the evolution of your project.

Tools like Cursor and Windsurf are powerful, but their change tracking interfaces are somewhat clunky, and as models get more aggressive about editing larger parts of your codebase, the more overwhelming such comparison interfaces will become.

Frequent commits act as checkpoints in your development journey. By committing often, you create clean, incremental snapshots of your project, making it far easier to review changes, spot unintended edits, and quickly revert mistakes.

What makes committing easier is Cursor’s and Windsurf’s built-in “Generate Commit Message” button. This feature analyzes your changes and automatically drafts a descriptive commit message, transforming what used to be a chore into a one-click process.

#5 AI IDE rules (.cursor/rules or .windsurfrules)

One of the highest-leverage moves you can make when working with AI coding agents like Cursor or Windsurf is to define clear, project-specific rules.
Think of rules as your agent’s operating manual: the clearer it is, the better your results.

At the start of every project, create a concise rules file, .cursor/rules or .windsurfrules, that guides how your AI pair programmer should behave. These rules act as a standing context layer that supplements every prompt, saving you from endless re-explaining and firefighting.

Here’s what great rules include:

• Your project-specific guidelines such as “Always prefer strict types over 'any' in TypeScript”

• Tech stack details - tell your agent what you're using: Flask, FastAPI, Supabase, SQLite, etc. so it stops making incorrect assumptions

• Known pitfalls and fixes - add proactive corrections here if you notice recurring errors (e.g., Cursor defaulting to the wrong Python version)

• High-level project overview - summarize the purpose, major functionalities, and key files (you can link to your prd.md here, see previous section).

Use .md reference files alongside rules for better modularity. For instance, we once spent a full day as a team designing our testing philosophy, captured it in test-guidelines.md, and added a simple rule: “Refer to test-guidelines.md when writing tests.”

Another rule that dramatically boosted my high-stakes coding sessions:

For any complex or critical task, ask any and all clarification questions needed before proceeding.

Cursor recently introduced a /Generate Cursor Rules command, allowing you to instantly create new rules based on the current chat context, which is particularly useful after a significant architecture change or a project refactor.

Extra resources:

• Browse and reuse existing community rules: Cursor Directory and Playbooks Rules

• Build your own rules easily: Playbooks Rule Builder

#6 Generate an MCP server for any API in two commands

Read more