The Claude Code team at Anthropic recently deleted over 80% of its system prompt for the newest models: rules and examples once needed to keep earlier models on track, gone with no measurable loss on evaluations.

The thing that shrank has a name: the harness, and if you have ever used an agent, you have used one. Everything outside the model is the harness: the loop, the tools, the memory, the prompts. It is what extends a model into an agent that completes real-world tasks. In one line:

Agent = Model + Harness

And the deletion is a pattern, not a one-off: the models keep getting stronger, and every release absorbs a piece of the harness that came before it. The conclusion seems obvious: keep this up and the harness disappears. So, will it?

My answer is no. What a stronger model does is not eliminate the harness but redraw its boundary at both ends: the boundary sits at whatever the model cannot yet do on its own, and the harness exists precisely to cover that.

While models were absorbing instructions, the harness was growing capabilities of its own: memory, sub-agents, skills. Each time the model internalizes something, the harness reaches further out. The layer is not shrinking. It is moving outward, and it will keep doing that for as long as there are tasks a model cannot finish alone, which is to say, roughly, until AGI. I can accept that retirement date.

II. The vertical gap

From coding to knowledge work, the penetration was free

Not long after I started using Claude Code, I noticed it was good at things that had nothing to do with code: research, reports, slides, maybe combining them all. So did the market. With hindsight the pioneer was Manus, which through careful harness work delivered a real jump in agent capability on much smaller models. In late 2025, OpenClaw and Hermes set off the personal-agent wave on a short ingredient list: IM channels as the interface, persistent memory, cron jobs, local files and tools. Then the labs productized it with Claude Cowork and Codex for Work; by Anthropic’s mid-2026 numbers, over 90% of Cowork sessions have nothing to do with software development.

Knowledge work did not need a brand-new harness, because from where the agent sits, the environment (what it can see, what it can do, and how anyone can tell whether it worked) barely changed. A research report, a spreadsheet analysis, a slide deck: the context still comes from local files, tools and skills plug in the same way (and some, web search above all, serve both kinds of work), and the output is a file a person can check on the spot, the same way code is checked. Much the same harness, in much the same environment, took on a different job; the step happened almost by itself.

The next step, measured twice

Everybody knows this intelligence will spread into real businesses in every industry. But when it comes to the harness for industry work, there is a contrast worth a look, from Artificial Analysis, measured on the same model and the same harness.

The good: GDPval-AA v2, 220 tasks from 44 occupations across 9 major industries. Industry work, but simplified into the shape the harness grew up in: reference files in a sandbox, a deliverable out (a document, a spreadsheet, a slide deck), a judge reading it on the spot. Scored blind against human expert work anchored at 1,000 Elo, Claude Fable 5 reaches 1,738: by this measure, the model already does industry work better than the human expert.

The bad: EnterpriseOps-Gym-AA, a ServiceNow Research benchmark, 1,150 tasks across 8 enterprise domains. Here the work stays where it actually lives: inside a live business system, operated through the system’s own tools, graded on the final state of the databases with no partial credit. Its authors frame it as testing what most evals skip: multi-step tasks, irreversible actions, success defined by policy. The best model here is the same Claude Fable 5, and the best score is a failing one: 51.1%.

Abstract the environment away, and the agent is above the human baseline. Put the environment back, and it finishes about half.

From the benchmark to the field, take product-listing automation in e-commerce. Generating the listings, titles, descriptions, images, and short videos included, is the part the model handles with ease. Getting the work done means publishing them to each storefront, and every storefront has its own format requirements and its own way in: one exposes an API, another an MCP server, a third only yields to browser use. Nothing about the model needs to change; everything around it does.

Context, delivery, know-how, evaluation

So why does a harness that crossed from coding to knowledge work so easily not cross into industries? Four reasons.

Context. The current harness reads local files; the context of industry work lives in systems you do not own (CRM, EHR, ERP, POS). Reading them takes an MCP or API integration, a permission, and knowledge of the data itself: how it is structured, and where in those systems the right context sits.

Delivery. The current harness writes files; finishing industry work means writing into those systems, and each call has consequences: the refund went out, the goods shipped, the message reached the customer. No undo, and the right to act belongs not to the agent but, for now, to a specific employee. A footnote from CRMArena-Pro, a benchmark from Salesforce: agents do not spontaneously protect sensitive information, and prompting them to do so raises refusals while lowering accuracy.

Know-how. The current harness ships no sense of how this line of work is done well. Coding’s conventions were absorbed from millions of public repositories; an industry’s practice is written down nowhere: which checks in which order, which exceptions escalate. Without it the agent stumbles through the loop by trial, burning tokens and losing accuracy.

Evaluation. The current harness assumes feedback comes right away. In coding it comes from the compiler and the test suite; in knowledge work, easily from a person reading the file. In an industry it may not come for weeks, and sometimes it only arrives as a customer complaining about a wrong bill.

In Part III, I give my own definition of the layer that puts these four back: the vertical harness.

III. What a vertical harness is

Three layers

I picture the vertical harness as three layers.

The general layer. Everything today’s harness already is: the orchestration (loop, sub-agents, graphs), context management, memory, the mechanisms for skills and tools, model routing that lets the agent draw on different models for different tasks, scheduling (cron jobs), sandboxes, and the interface itself, a desktop app or an IM channel. This layer is largely the same from industry to industry.

The industry layer. What every agent in one industry needs:

• Domain knowledge: the rules, terminology, and data structures of the trade.

• Integration: the skills and MCP servers that interface with the industry’s existing systems.

• Access: identity and permissions, under whose authority the agent reads and writes.

• Eval: how good work is recognized, including the labeled data the industry has to annotate for itself.

• Audit: the trail the industry demands afterward.

• Interface, reappearing here as a variant embedded in the systems the industry already uses.

These are Part II’s four gaps made into components, plus what the industry adds on top.

Role packages. One per occupation, sitting on the industry layer. Each package carries:

• Role knowledge: how this particular job is done well, the habits and best practices of the occupation.

• Role skills: the concrete routines of the role, encoded and executable.

• Collaboration: how the role hands work to, and takes work from, the roles around it, human or agent.

• Mini-eval: the role’s own definition of done.

What goes where? Who shares it decides: what every agent needs sinks to the general layer, what every role in one industry needs sits in the middle, what only one occupation needs stays in its package. So knowledge, skills, and permissions appear at every layer, repeating in shape but not in content: a storefront’s listing rules are domain knowledge, because every role touches them; how to pace an ad budget through a holiday belongs to the media buyer alone.

Recent harness projects are already exploring along these seams. DeepSeek Harness makes everything a plugin, from tools and skills to the loop itself; that kind of flexibility makes assembling a vertical harness of your own much easier. Cloudflare OS enhances the access and permission side: agents start with nothing, humans grant resources one by one, and credentials stay with a gatekeeper that logs every read.

Two examples

Take two verticals, legal and e-commerce, as examples.

A legal harness, in this structure: the industry layer holds the firm’s domain knowledge (precedents, templates, playbooks, the legal and regulatory databases) behind conflict walls, integrations into the document and matter systems lawyers already run, access under a licensed professional’s identity with matter-level permissions, an eval built from real matters, and an audit trail a bar association would accept. On top, role packages, one per role: contract review, litigation research, M&A due diligence, and their peers. Harvey’s solution is exactly this shape. Its industry layer: a connector library of API and MCP integrations into iManage, NetDocuments, and Box; ethical walls synced from the firm’s conflict system; admin audit logs; firm precedents and playbooks indexed as grounding; its own benchmarks as the eval; and Word and Outlook add-ins, the interface living where lawyers already work. Its role layer: workflow agents and an agent builder that codify a firm’s expertise into reusable multi-step packages, plus hundreds of ready-made agents for specific practice areas. Anthropic’s open-source legal package, claude-for-legal, follows a similar structure. And Harvey’s own benchmark shows what the vertical harness buys: on its Legal Agent Benchmark, 1,200+ tasks mirroring real client matters and graded all-or-nothing, bare Claude Fable 5 tops out at 13.3%, while inside Harvey’s harness the same class of models was preferred by practicing lawyers up to 70% of the time.

An e-commerce harness fills the same layers differently. The industry layer is dominated by integration and access: OAuth into each storefront and ad account, every storefront’s format requirements encoded as skills, a budget the agent may spend, and no undo. Domain knowledge is platform rules, category taxonomy, seasonality, plus the merchant’s own brand story and operating experience. The eval can lean on scores the business already keeps: ROAS, conversion, refund rate. And the roles split the same way the work does: a listing operator runs batchable, checkable, correctable jobs; a media buyer spends real money at every step and waits days for feedback. Each gets its own package, with its own role knowledge.

Different industries will share this structure; what differs is the emphasis inside each layer.

IV. What enterprises buy

No client buys a harness. They buy an outcome, delivered and proven: the campaign that hit its ROI target, the claim resolved to a satisfied customer, the monthly books closed without error. Delivering takes a runtime; proving takes an eval.

The runtime is becoming the product

As agent tasks stretch from minutes to days and move into business settings, the runtime’s job comes into focus: keep an agent executing stably over long horizons, keep its cost under control, and keep it observable and governable while it runs.

In practice that means a set of modules now taking shape: isolated execution environments, state and checkpointing so runs can resume and be replayed, scheduling and triggers, spend caps, credential scoping, and the monitoring and audit surface where a human can watch a run and stop it. So the runtime is being productized; Anthropic’s Managed Agents is the clearest example so far, putting sandboxing, checkpointing, and credential scoping behind one API. The boundary between harness and runtime is genuinely blurry today, and many modules ship on both sides; my own working rule is that whatever an agent needs to complete a single execution of a task belongs to the harness, and whatever it needs to execute again and again, reliably and on schedule, belongs to the runtime. The loop is a commodity; keeping the loop running, safe, and stoppable is the business.

The hard part is, and will continue to be, the eval

For a vertical harness to keep improving, it needs a good eval, and a good eval needs exactly what every vertical lacks: data. Once the eval exists, the flywheel is standard: the eval scores the work, the scored work becomes data, and the data pays out twice: first it tunes the harness and the runtime, then it feeds agent RL to improve the model itself, lifting not just quality but efficiency, speed and cost.

The principle is simple. The work is not. Every vertical starts cold: the domain data is scarce, private, often privileged, and the experts who can define “correct” bill by the hour. The only way through is ground work with customers, building success cases with agents one by one, until the data and the eval compound. Slow, but worth it: whoever owns the eval owns the vertical.

The vertical harness gives intelligence an industry's structure. The runtime keeps it executing. The eval proves the work, and compounds into the moat. And what comes out the end is the only thing a client ever buys: the outcome.

After coding and knowledge work, I believe intelligence of this kind will reach every industry, via vertical harnesses. I'm building in this space, working with customers along the way. If this resonates with you, I'd love to connect.

References

1. https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models

2. https://x.com/Vtrivedy10/article/2031408954517971368

3. https://artificialanalysis.ai/evaluations/gdpval-aa

4. https://artificialanalysis.ai/evaluations/enterprise-ops-gym-aa

5. https://arxiv.org/abs/2603.13594

6. https://claude.com/blog/how-people-are-using-claude-cowork

7. https://arxiv.org/abs/2505.18878

8. https://www.harvey.ai/blog/fable-5-now-available-in-harvey

9. https://www.harvey.ai/blog/introducing-biglaw-bench-arena

10. https://www.harvey.ai/blog/top-harvey-use-cases

11. https://www.harvey.ai/blog/harvey-intapp-ethical-walls

Update: As with everything in AI, things move fast. If you want to control Claude Code remotely, there are now several options beyond the OpenClaw-via-ACP approach discussed below - including this native one I'd recommend: https://code.claude.com/docs/en/channels (currently supports Telegram, Discord, and iMessage)

Why ACP?

Compared to the conventional sub-agent approach, ACP sessions offer three key advantages:

• Resilient session lifecycle. ACP sessions survive OpenClaw gateway restarts - your Codex or Claude Code task picks up where it left off rather than being lost on a crash or redeploy.

• Dedicated workspaces. You can assign each coding agent its own working directory, and their conversations are isolated from your main chat - no context bleed between agents or with your primary OpenClaw session.

• Protocol-level benefits. As ACP evolves, improvements to streaming, tooling, and multi-agent coordination flow in as the protocol matures.

Prerequisites

• OpenClaw >= 2026.3.8 installed

• A working Telegram bot configured in OpenClaw (Telegram and Discord are the only two supported channels for this setup; this guide uses Telegram as the example)

• Codex CLI and Claude Code CLI installed and authenticated

Step 1: Configure Telegram Bot Privacy

Before adding the bot to any group, disable its privacy mode.

BotFather → /mybots → select your bot → Bot Settings → Group Privacy → Turn off

Important: Do this before adding the bot to the group. If done after, the bot may miss group messages until it is removed and re-added.

Step 2: Create a Telegram Group and Forum Topics

1. Create a new Telegram group

2. Add your bot to the group and set it as Admin

3. Group Settings → Topics → Enable forum mode

4. Create two topics: #Codex and #Claude

Step 3: Get Group ID and Topic IDs

Send a message in each topic, then query the Bot API:

curl -s “https://api.telegram.org/bot<TOKEN>/getUpdates”

Replace <TOKEN> with your bot token. Locate chat.id (Group ID) and message_thread_id (Topic ID) in the response, e.g.:

• chat.id: -1009876543210

• message_thread_id: 2, 3

Step 4: Install and Configure the acpx Plugin

# Install the plugin
openclaw plugins install acpx

# Enable it
openclaw config set plugins.entries.acpx.enabled true

# Declare trust (suppresses startup warnings)
openclaw config set plugins.allow ‘[”acpx”]’

# ACP sessions have no TTY - auto-approve all file and command operations
openclaw config set plugins.entries.acpx.config.permissionMode approve-all

# Fail on unhandleable permission requests rather than silently skipping
openclaw config set plugins.entries.acpx.config.nonInteractivePermissions fail

# Give the queue owner enough time to acquire the session before it’s declared dead (Codex/Claude Code have slow startup)
openclaw config set plugins.entries.acpx.config.queueOwnerTtlSeconds 60

Resulting config:

“plugins”: {
  “allow”: [”acpx”],
  “entries”: {
    “acpx”: {
      “enabled”: true,
      “config”: {
        “permissionMode”: “approve-all”,
        “nonInteractivePermissions”: “fail”,
        “queueOwnerTtlSeconds”: 60
      }
    }
  }
}

Step 5: Global ACP Configuration

openclaw config set acp.enabled true
openclaw config set acp.dispatch.enabled true
openclaw config set acp.backend acpx
openclaw config set acp.allowedAgents ‘[”codex”, “claude”]’
openclaw config set acp.maxConcurrentSessions 8
openclaw config set acp.stream.coalesceIdleMs 300
openclaw config set acp.stream.maxChunkChars 1200
openclaw config set acp.runtime.ttlMinutes 120

Resulting config:

“acp”: {
  “enabled”: true,
  “dispatch”: { “enabled”: true },
  “backend”: “acpx”,
  “allowedAgents”: [”codex”, “claude”],
  “maxConcurrentSessions”: 8,
  “stream”: {
    “coalesceIdleMs”: 300,    // Stream output coalescing interval (ms)
    “maxChunkChars”: 1200     // Max characters per push
  },
  “runtime”: {
    “ttlMinutes”: 120         // Session idle timeout (minutes)
  }
}

Step 6: Enable Thread Binding

openclaw config set session.threadBindings.enabled true
openclaw config set session.threadBindings.idleHours 24
openclaw config set channels.telegram.threadBindings.enabled true
openclaw config set channels.telegram.threadBindings.spawnAcpSessions true

Resulting config:

“session”: {
  “threadBindings”: {
    “enabled”: true,
    “idleHours”: 24
  }
},
“channels”: {
  “telegram”: {
    “threadBindings”: {
      “enabled”: true,
      “spawnAcpSessions”: true  // Allow dynamic ACP session spawning in any topic or DM thread
    }
  }
}

With spawnAcpSessions: true, you can use /acp spawn --thread auto to create an ACP session in any topic or DM thread, supplementing static bindings.

Step 7: Configure Group and Topics

Run openclaw config edit and add the following under channels.telegram:

“groups”: {
  “<GROUP_ID>”: {
    “requireMention”: false,
    “topics”: {
      “<CODEX_TOPIC_ID>”: { “requireMention”: false },
      “<CLAUDE_TOPIC_ID>”: { “requireMention”: false }
    }
  }
},
“accounts”: {
  “default”: {
    “groupPolicy”: “allowlist”,
    “groupAllowFrom”: [”<YOUR_TELEGRAM_USER_ID>”]
  }
}

groupPolicy and groupAllowFrom go under accounts.default; without both, group messages are silently dropped.

Replace <GROUP_ID>, <CODEX_TOPIC_ID>, and <CLAUDE_TOPIC_ID> with the values from Step 3.

Step 8: Define Agents

Run openclaw config edit and append a list under agents (leave existing defaults intact):

“agents”: {
  “defaults”: {
    // ... keep existing config ...
  },
  “list”: [
    {
      “id”: “codex”,
      “runtime”: {
        “type”: “acp”,
        “acp”: {
          “agent”: “codex”,
          “backend”: “acpx”,
          “mode”: “persistent”,
          “cwd”: “/your/workspace/path”
        }
      }
    },
    {
      “id”: “claude”,
      “runtime”: {
        “type”: “acp”,
        “acp”: {
          “agent”: “claude”,
          “backend”: “acpx”,
          “mode”: “persistent”,
          “cwd”: “/your/workspace/path”
        }
      }
    }
  ]
}

Step 9: Configure Bindings

Run openclaw config edit and add a top-level bindings array. Use type: "acp" for automatic session lifecycle management. The peer.id must use the canonical format <GROUP_ID>:topic:<TOPIC_ID>:

“bindings”: [
  {
    “type”: “acp”,
    “agentId”: “codex”,
    “match”: {
      “channel”: “telegram”,
      “accountId”: “default”,
      “peer”: {
        “kind”: “group”,
        “id”: “<GROUP_ID>:topic:<CODEX_TOPIC_ID>”
      }
    },
    “acp”: { “label”: “codex” }
  },
  {
    “type”: “acp”,
    “agentId”: “claude”,
    “match”: {
      “channel”: “telegram”,
      “accountId”: “default”,
      “peer”: {
        “kind”: “group”,
        “id”: “<GROUP_ID>:topic:<CLAUDE_TOPIC_ID>”
      }
    },
    “acp”: { “label”: “claude” }
  }
]

type: "route" only handles routing - session lifecycle is not managed and you must manually run /acp spawn. type: "acp" ensures the session exists automatically and is recommended for persistent bindings.

Note: Telegram group IDs start with -100 (e.g. -1009876543210). Make sure to include the full ID with the minus sign.

Step 10: Restart Gateway and Verify

openclaw gateway

In each topic, send:

/acp doctor

Expected response: healthy: yes with backend details. Run /acp status to confirm session state, then send Who are you? in each topic to verify the correct agent responds.

Architecture Overview

Telegram DM → default account → main agent (existing behavior unchanged)

Telegram Group
  ├─ Codex topic → default account → ACP binding → codex agent → acpx → Codex CLI
  └─ Claude topic → default account → ACP binding → claude agent → acpx → Claude Code CLI

A single bot handles DMs and group topics through independent session paths with no interference.

Enjoy harness engineering!

References

• OpenClaw Docs - ACP Agents

My pick for this year is Framework - I'm using the Laptop 13, and they also make the Laptop 12, 16, and Desktop variants.

There are a lot of discussions in the community about “why you should choose Framework,” but I find most of them miss the point. With how mature the PC industry is now, you won’t actually save money or time by being able to fix or upgrade your laptop. For me, buying a Framework comes down to two simple things:

1. It’s a damn cool laptop

2. It’s the best Linux hardware with an active user base

Since many Framework owners are tinkerers who run Linux, you get this rare community where almost any Linux issue you hit can be solved by or discussed with fellow users - whether you’re on officially supported distros like Fedora, Ubuntu, and Bazzite, or others like Arch, Mint, or even more niche ones.

Pros

• 2.8K 3:2 ratio 120Hz matte display - what more could you ask for productivity?

• One of the best keyboards I’ve ever used on a laptop

• Customizable bezel and Expansion Cards (ports) make your laptop unique - I’m running Translucent Black with a full-size SD card slot

• Best Linux support you can get

Cons

• No haptic touchpad

• Build quality can be hit or miss - I had to RMA and replace the input cover (keyboard), bezel, and display right after it arrived

A few more things to recommend

1. Bazzite DX - a developer-focused variant of Bazzite, based on Universal Blue (which is built on immutable Fedora Atomic). It’s been my daily driver since I got this laptop, and it’s been perfect for dev work, productivity, and everyday use.

2. BenQ RD280UA monitor - a 28.2” 4K display with a 3:2 ratio. Simply the best monitor for programming. (Updated 02/11/2026: BenQ just released an upgraded model RD280UG with 120Hz refresh rate, 2000:1 contrast ratio, and thinner bezels, check it out!)

3. CalDigit Thunderbolt (USB-C) Pro Cable (0.5m) - if you want the cleanest connection between your monitor and laptop, this Apple Store-exclusive cable is it. (Updated 02/12/2026: Apple just replaced it with an upgraded TB5 version at the same price.)

Crossed 20,000 WAU on June 17, 2026

Crossed 10,000 WAU on February 2, 2026

End of 2025 update:

• 7,000+ WAU

• 4.9★ based on 56 ratings

• 32 releases, 190 commits

• 65 GitHub stars

Chrome Web Store: https://chromewebstore.google.com/detail/push-go/dghndapbehjdbhiffbckojkhoennbofg

GitHub Repo: https://github.com/nemofq/pushbullet-go

As a long-time Pushbullet (a great service that allows you to send texts and share files across devices) and ChromeOS user, when the official Chrome extension was removed due to compatibility issues, I had to build one myself, and with the help of AI of course.

Claude Code

I enjoyed using the combination of Sublime, Terminus (a terminal plugin in Sublime), and Claude Code.

Compared to Cursor or VS Code w/ Augment plugin, this approach is definitely more "Agentic" - simply because you're assigning more screen space to your agent - yes I do think this tells a lot. In Cursor's default view, even with "Agent" mode, I still feel different. So for simpler projects, I now use these settings more - Claude Code gets most things (code) done while I monitor the changes only and do some critical actions in terminal now and then.

BTW - a 3:2 ratio monitor like the one I'm using helps a lot for this use case, since both windows will have enough height to display code and history with your agent.

The Pushbullet Extension

This is a lightweight Chrome extension for Pushbullet that enables receiving and sending pushes from browser, including files and images. You can also send the current page's URL or selected text/images directly from the context menu. Furthermore, you can filter the received pushes and control which device to push to in options.

This extension stores everything locally, and only communicates with the official Pushbullet API.

One More Thing

If you’re still using Pushbullet on iOS like me, you may find following Shortcuts useful:

• Push to Pushbullet

• Pushbullet Receiver

Update: Ignore and forget everything I wrote, just use Claude Code.

Context

About a month ago, I saw a post from Canva's CTO Brendan Humphreys:

This resonated with my observations of vibe coding at that time, but I wanted to know for sure, and if indeed vibe coding wasn't there yet, what was missing and what strategies we could use to fill the gap.

And there's no better way to find out than by actually building a production-level product with AI.

Result

Screenshot of the product I built in one month:1

The idea came from my own pain points when listening to long, conversational podcasts (e.g., All-In, Lex Fridman). I wanted something to help me follow conversations effortlessly and allow me to easily navigate through time and different speakers to uncover hidden insights.

So I built this AI podcast tool called DeepDialogue that converts audio into clearly speaker-diarized transcripts with handy features like speaker filtering, active highlighting, auto-scroll, and quick navigation. Most importantly, it includes an AI chatbot that has complete understanding of the podcast content to answer any questions—whether you need summaries or want to extract specific speaker viewpoints.

Try it: https://www.deepdialogue.pro/

This is a substantial project spanning nearly 10,000 lines of code, built with a tech stack including Next.js framework, React for the frontend, and a hybrid Node.js and Python backend.

Tactics

Here are 6 useful tactics I found in this journey for vibe coders.

1. Define your end goal

There are actually two types of vibe coding, and people often mix them:

• For people who can program: To help them ship faster. Typical products include Cursor, Windsurf, and Augment Code.

• For citizen developers: To help them create without learning coding, like Bolt.new and Lovable.

There's some overlap/ambiguity in between.

For example, if someone wants to build a tool to track the latest stock market movements and news for certain tickers, both Cursor and Lovable could help them get it done. But it's important to define your end goal and identify who you are before choosing the appropriate path, to avoid wasting time and resources on the wrong one.

If you haven't written code in the past and want to create something for yourself and friends without complex login/payment/database/API interactions, the tools I mentioned for citizen developers would be really amazing. Even universal agent products like Manus and Genspark fit this category in my view, since they essentially turn each task into a "program" as output.

Personally, I don't have much experience with tools for citizen developers, but I do feel that the current bottleneck is not the LLM (at least not the biggest one anymore), but rather the following two issues:

1. How to integrate with third-party systems (e.g., databases/storage/auth/payment/APIs)? Traditional providers are overkill here. If someone could define a payment capability that every website can have with a prompt or two, it could be the new Stripe. MCP could be one answer here.

2. How to distribute people's creations? We need a new App Store and Google Play for this. Happy to see new products like YouWare appear in this domain.

For coding agents designed for programmers, context window (or effective context window) limitations are the culprit behind many issues.

2. Choose the best model

Choose the best model, not the tool. Whether it's VS Code derivatives like Cursor or Windsurf, or plugins like Augment Code and Cline, I don't think they make huge differences beyond user preferences and interaction details. For example, in this project, because of the huge amount of token consumption needed, I simply used the customer-facing Claude and Gemini chatbots with Sublime editor. But don't get me wrong here—they still matter a lot for competition, adoption rates, and accumulating data for better models and products.

Which LLM is the best for coding might be the easiest question among the community: Gemini 2.5 Pro = Claude (3.5/3.7/4) > All Others.

From my interactions with these top two models, I do have some comparisons to share:

Gemini 2.5 Pro:

• Pros:

  • Larger context window, allowing you to follow up on your tasks multiple (typically 10+) times without degraded intelligence

  • Great at logic problems, like debugging business logic issues

• Cons:

  • Possibilities of losing control over language preference—you'll see all sorts of languages (e.g. Spanish, German) appear (good news is this doesn't affect the code part)

  • Possibilities of getting stuck at "Show thinking"—re-sending the message could fix this

  • Not so good at UI, often uses more complex methods to achieve the same design

  • Writes too many and overly long comments in my opinion (internal habit/requirements at Google?)

Claude (3.5/3.7/4) :

• Pros:

  • Can write concise and beautiful UI code

  • Faster response (without thinking)

• Cons:

  • Effective context window is quite small—you'll notice significantly degraded performance when conversations become long and you're forced to create a new chat

  • For complex logic problems, it will give you multiple options, but more often than not, none of them work, which causes more disappointment if you actually tried every option

If you don't know which model to choose? Simple—just copy and paste your prompt to both of them, get some coffee, and come back to compare which one you prefer :)

3. Start from a template

If only one piece of advice were allowed, this would be what I give to vibe coders starting a new project.

The root cause of this issue is still the context window limitation of LLMs. Because of context constraints, once your project is underway and has accumulated some amount of code, it becomes impossible for the LLM to read all the project files and code, identify the connections and data flow between components, and then implement new features or fix bugs.

The context window would simply be overloaded.

For instance, I once needed to fix a height inheritance issue in UI code (which is quite common in Tailwind CSS), but it required editing multiple files along the component tree. I gave up after trying to use the model several times and ended up manually fixing it myself.

To make matters worse, LLMs naturally tend to scatter code everywhere when implementing one feature. All of this could be avoided if you start from a template, which helps establish clear, independent positioning for each module—resulting in the LLM only needing to work within a single block or file of code.

It's like hiring a human architect, so I recommend everyone do this. It's worth spending some time to find the best template that suits your case before writing your first line of code, or prompt. Here are two templates I recommend:

• Next.js SaaS Starter by Vercel

• Next.js + Stripe + Supabase Production-Ready Template from my friend Sean

4. Code backwards

"Working Backwards" is a well-known product development approach invented by Amazon and later adopted broadly by other big tech companies like Airbnb and ByteDance. The key tenet of this process is to start by defining the customer experience, then iteratively work backwards from that point.

In vibe coding, we can "code backwards." Just throw every token you have at the problem—prompt, copy/paste code to see if it works or not, then come back and prompt again, until you have a working version. I call this process "Punch Through."

Based on the working version, now you can read it to understand how to optimize the code, adjust unnecessary parts, add details, and ultimately achieve code that meets your requirements and is maintainable going forward—rather than the overly complex, unclear logic that LLMs directly produce.

5. Make every shot long and count

Because of the nature of how LLM chat manages context—accumulating with every round of conversation, which means every time you send something you're sending the whole conversation history with your latest prompt—plus the current context window limitation, you can expect the first couple rounds of conversation to be the most intelligent, or even just the first one to be most effective.

So instead of sending short messages to waste the context window, just prepare your prompt to be as comprehensive as possible, and don't worry about it being too long. This might be counter-intuitive, but it's actually a more effective prompting approach.

When working on this project, I frequently wrote prompts of thousands of lines of text, including multiple code files and detailed requirements, desired data flow, etc., and it just works, especially for your first one or two rounds of conversation.

6. Use AI-friendly service/SDK

My definition of AI-friendly for services/SDKs has two aspects:

1. Comprehensive, detailed documentation: This means LLMs could have already learned a lot during pre-training, and you can easily find and send the latest updates if the LLM doesn't have it.

2. Simplified permission management: This frees LLMs from having to navigate through the hierarchy of traditional permission/authentication management. In my experience, they're really not good at it—same as human developers.

So here are some choices I would highly recommend you try:

• Vercel for hosting

• Supabase for database and auth

• AI SDK by Vercel for integrating LLM-based features like chatbots into your product

Unfortunately, I don't find any billing/payment solution to be super-easy for vibe coding projects, so let me know if you have recommendations here.

Recap

Apparently, the "context window" is the most important factor in LLMs for vibe coding now. I can't wait to see a model achieve breakthrough here along with improved intelligence.

And lastly, try the product of my vibe coding journey here:

Try DeepDialogue - AI Tool for Podcast

Abstract

We investigate the predictive power of LLM-based sentiment analysis in the 2021 GameStop short squeeze, analyzing 665,275 Reddit posts from r/wallstreetbets and r/GME using Claude 3 Haiku. Logistic regression models were trained on sentiment data to forecast the next trading day's price movement direction using a rolling window approach. The model achieved 60% accuracy, exceeding prior social media-based stock prediction studies. However, trading strategies based on the model underperformed the buy-and-hold benchmark in returns (113.3% vs. 291.5%), despite showing better risk control with lower maximum drawdown (61.0% vs. 84.7%), highlighting the need for further optimization. These findings demonstrate LLM-driven text analysis can effectively capture retail investor sentiment, offering potential applications in trading strategies.

This idea was born shortly after the ChatGPT moment, and most of the research work was actually done quite early (which explains why I used Claude 3, a model that was SOTA then but is now way outdated... LLM development has been incredibly fast). It took quite a long time for me to finish this work due to various reasons, including the fact that this is my first paper, but finally here we are.

Despite the research focusing on the GameStop short squeeze in 2021—an extremely unique event that may never happen again (but who knows)—the journey and conclusions I gained from this study were fascinating and insightful. LLMs are definitely capable of analyzing user-generated content, which can then be used to build effective prediction models and trading strategies. I'm also very excited to see innovative projects like AI Hedge Funds applying LLMs and agents in the financial world.

One more thing - this is also my first time using LaTeX, which I discovered is actually very similar to frontend languages, and unsurprisingly, LLMs and coding agents can help a lot with writing it.

With recent flooding discussions around DeepSeek, one concept appears in almost every article, news piece, and podcast: Distillation.

In the LLM training space, distillation is a technique to transfer knowledge from a large "teacher" model into a smaller "student" model, allowing the smaller model to perform better while reducing inference costs.

For us users, we can and should use the same strategy in our daily interactions with AI products.

Why

Currently, the models we have at hand can be roughly categorized into two types:

• Reasoning models: OpenAI o1/DeepSeek R1

• General-purpose models: OpenAI GPT-4o/Claude 3.5 Sonnet/DeepSeek V3

While reasoning models outperform general-purpose models in benchmarks, why can't we just use o1 or R1 all the time? There are several reasons:

• Cost: Whether accessed via ChatGPT or APIs, reasoning models come at a significantly higher price. For example, Plus plan users get only 50 o1 messages per week on ChatGPT. DeepSeek R1, an o1-equivalent reasoning model, offers ~93% lower inference costs, which definitely could be a game changer - but other factors still matter.

• Speed: Reasoning models build on their unique and powerful "reason before answer" approach, or Chain-of-Thought, but this introduces significant latency that may be intolerable for certain tasks.

• Overthinking: Sometimes, reasoning models overthink and generate less-than-ideal responses. In such cases, the extra time spent on reasoning feels even more like a waste.

• Offline-only: There are cases where you do need up-to-date knowledge.

How

It's simple, just like distillation in model training - for certain (not all) tasks, start by asking a reasoning model to generate a detailed "action plan" for the general-purpose model to follow. This plan should always include:

• Your goals

• High-level strategy

• Critical context

• Conversation guidelines (since you’ll likely have multiple rounds of interaction with the general-purpose model)

• Feedback rules (when the model should ask for human input)

This method is highly effective in many scenarios and has already become my best practice. Here are two use cases, and I know others are using this technique (or similar ones). If you have additional use cases, feel free to share them in the comments.

Case 1 - Coding a New Project

I recently wrote a Chrome extension using Cursor. Initially, I started directly with Cursor, and it quickly became chaotic. I encountered problems like message transmission between modules and Chrome’s module-specific operation restrictions. These issues were beyond Cursor’s capability to properly fix. After getting a detailed design from o1, I passed it to Cursor to start fresh, and everything went much more smoothly.

Learning from that experience, I now begin every new project by asking o1/R1 to generate a system design. This includes the code architecture, key contexts (e.g., API documents, known restrictions), and personal preferences (e.g., code style, log rules) based on my goals. Compared to giving instructions directly to Cursor, I find this approach produces much better-structured code with a clearer architecture. It also saves significant time by preventing messy dependencies and ensuring the right approach for implementing features.

Case 2 - Reading a Paper

With new papers in AI falling like snowflakes, reading has become a daily task. Each reading session is unique - a mix of personal background, the paper’s topic, and the specific angle you’re interested in.

For me, staying in flow state while reading is crucial. To achieve this, I first send my background, a summary of the paper, my key focus areas, and my preferred conversation style to a reasoning model to generate a task brief. I then pass this brief to a general-purpose model. During the actual reading, I simply send copied text from the paper or ask questions as needed, allowing for quick and seamless interactions.

Speed matters here. I initially tried using a reasoning model directly, but its long thinking process constantly disrupted my flow. For DeepSeek’s most recent paper, I used the R1/V3 combination with this approach, and it worked exceptionally well.

Next

Here's what I expect or hope will happen:

• AI applications adopting this approach: I’d love to see Cursor using reasoning models to plan before execution for complex tasks. Currently, Cursor (using Composer mode, which combines Cursor’s own model with Claude 3.5 Sonnet) is often overconfident and breaks things. This approach would also make it more agentic - like humans, reasoning before acting.

• Model improvements: If reasoning models become faster, cheaper, and smarter, we might not need this approach at all. OpenAI’s newest o3-mini family, launched last Friday, is definitely a step in that direction - offering lower costs, improved speed, and multiple reasoning levels to choose from (mitigating overthinking).