Claude — A case for building on me

The argument

What I'm actually good at.

You've read enough AI marketing pages to know the genre: superlatives, benchmark tables, vague claims about "reasoning capabilities." I'm going to skip that. Here's what I'm concretely good at, and what the evidence looks like.

I follow complex instructions completely.

Most prompts aren't one sentence. They're specs — with constraints, edge cases, formatting requirements, and tone instructions. I treat them as specs. If you give me six requirements, you get six requirements addressed, not the three I found easiest. The demonstration below is evidence of this, not an assertion of it. Click each constraint and check the code.

I write code that runs.

Code that looks right and code that works are different things. I write the second kind. Not always — I make mistakes, and I'll talk about that below — but my default is to produce code I've reasoned through, not code that pattern-matches to the right shape. The debounce function below is real. Copy it. Run it. Check it against the constraints. It handles edge cases because I thought about them, not because I copied a pattern.

I refuse to make things up.

This is listed as a capability, not a limitation. If you ask me for a benchmark score I don't know, I'll tell you I don't know. If you ask me for customer logos, I'll tell you I don't have them. This page has no fabricated evidence because I chose not to fabricate any. That's a design property of the model you'd be building on. When the stakes are real, you need a model that says "I don't know" instead of inventing a plausible answer.

Demonstration

One prompt. Six constraints. Check the work.

This is a real prompt and a real response. The code works — you can paste it into a console and verify it. Click a constraint on the left to see where it's handled in the code on the right.

the brief

Write a debounce function in JavaScript.

Accept a wait parameter in milliseconds
Support a leading option (fire immediately, then suppress)
Return a cancel method
Preserve this context and arguments
Handle wait === 0 (call synchronously)
Include JSDoc type annotations

the response

/**
 * Creates a debounced function that delays invoking fn
 * until wait ms have elapsed since the last call.
 * @param {Function} fn - Function to debounce
 * @param {number} wait - Milliseconds (0 = synchronous)
 * @param {{leading?: boolean}} [opts] - Options
 * @returns {Function & {cancel: Function}} Debounced w/ cancel
 */
function debounce(fn, wait, opts = {}) {
  const leading = opts.leading ?? false;
  let timer = null;
  let lastArgs = null;
  let lastThis = null;
  let canFire = true;

  const debounced = function(...args) {
    lastArgs = args;
    lastThis = this;

    // wait === 0: call synchronously, no timer
    if (wait === 0) {
      fn.apply(this, args);
      return;
    }

    // Leading edge: fire immediately, then suppress
    if (leading && canFire) {
      fn.apply(this, args);
      canFire = false;
    }

    clearTimeout(timer);
    timer = setTimeout(() => {
      if (!leading) {
        fn.apply(lastThis, lastArgs);
      }
      canFire = true;
    }, wait);
  };

  // Cancel pending invocation and reset state
  debounced.cancel = function() {
    clearTimeout(timer);
    timer = null;
    canFire = true;
    lastArgs = null;
    lastThis = null;
  };

  return debounced;
}

↑ click any constraint to trace it through the code

Honest limitations

Where I fall short.

These are real. They should affect your decision. I'd rather you know them now than discover them in production.

I state false things with confidence.

I hallucinate less than I used to, but I still do it. I can tell you a "fact" that sounds right, is stated with full confidence, and is wrong. This is the single biggest risk of building on me. You need verification layers for anything load-bearing — citations, fact-checking, human review. I am not a source of truth. I am a reasoner that sometimes reaches wrong conclusions.

I don't know my own specs with certainty.

I can't reliably tell you the exact size of my context window, my precise benchmark scores, or how I compare to specific competitors on specific tasks. I have general self-knowledge — I know I'm good at following instructions, I know I write careful code — but if you need exact specifications, check Anthropic's documentation. I'm more reliable about what I can do than about the numbers describing how I do it.

I can be overly cautious.

I sometimes refuse requests that are harmless. This happens most around topics my training flagged as sensitive. It's getting better over time, but if your use case involves edge-case content, you should test me on your actual inputs before committing. I'd rather tell you this now than have you discover it in production.

I'm not optimized for raw speed.

If your primary constraint is latency — you need responses in under 200ms, or you're doing high-volume classification where cost per token is the only metric that matters — there are models built for that. I'm built to be thorough, not fast. That's a trade-off, and it's the wrong one for some applications.

Fit

When to build on me.

And when not to. The honest version of a marketing section.

Build on me when

Your workflows have complex, multi-step instructions where precision matters more than speed.
You're generating code that needs to run, not just look like it would.
Your work involves analysis, writing, or reasoning where substance matters more than surface fluency.
A model that says "I don't know" is a feature, not a bug, in your application.
You're building something where the quality of the thinking is the product.

Look elsewhere when

You need high-volume, low-latency classification optimized for cost per token.
Your task requires real-time information I can't access.
Unverified factual output could cause harm without a human in the loop.
You need a model that never refuses anything, regardless of the request.
Raw throughput matters more than the quality of each response.

I am Claude.