DEV Community: Taimoor khan

LLM vs Agent vs Harness, Explained by a Caveman

Taimoor khan — Fri, 25 Sep 2026 14:04:23 +0000

LLM vs Agent vs Harness, Explained by a Caveman

Everyone argues about AI agents. Half the people arguing can't say where the LLM ends and the agent begins.

So here's the whole thing, explained by a caveman.

The LLM: a big brain in a jar

The LLM is a brain. A very big, very well-read brain. It knows many words. It can finish your sentences, write your emails, and explain recursion five different ways.

It has no hands.

You give it a question, it gives you an answer. That's the entire product: text in, text out. It doesn't remember yesterday unless you hand it the notes. It can't open a browser, run your tests, or move your money.

The agent: a brain with hands

Give that brain hands, a goal, and permission to keep going.

An agent takes "book me the cheapest flight to Dubai next month," breaks it into steps, searches flights, compares prices, hits a dead end, tries different dates, and comes back with a booking. Nobody held its hand between steps. The loop did that: think, act, look at what happened, think again.

The LLM is the part that reasons. The agent is the loop around it: tools it can call, memory of what it already tried, and the stubbornness to keep going until the job is done.

The harness: the leash

The harness is everything around the agent that keeps it from running off a cliff. Which tools it's allowed to touch. How many times it may retry. What it must never do. Where it writes logs. How you score its work.

Skip the harness and your agent is a toddler with a credit card. It will do something. It won't be what you wanted.

Building agents for production taught me this split: the model is maybe 10% of the work. The harness is the other 90%. Anyone can call an API. The work is guardrails, evals, retry budgets, and permissions.

The mammoth stew test

The village wants mammoth stew.

The LLM hands you five recipes and wishes you luck.

The agent goes out, hunts the mammoth, and brings back meat.

The harness says no baby mammoths, home before dark, max three spears.

Same goal. Three very different cavemen.

When to use which

Need text, a summary, or an answer? A single LLM call is enough. Don't build an agent because it's fashionable.

Need a multi-step job done with tools? That's an agent.

Letting it touch anything real? Build the harness first. Permissions before autonomy.

The short version

LLM = brain. Agent = brain + hands. Harness = leash.

Next time someone says "we built an AI agent," ask what the harness looks like. The answer tells you whether it's a demo or a product.

Which one are you building right now?

I Built a Claude Code Plugin That Audits Vibe-Coded Apps for Production Readiness

Taimoor khan — Thu, 24 Sep 2026 10:16:13 +0000

I Built a Claude Code Plugin That Audits Vibe-Coded Apps for Production Readiness

Vibe coding got us shipping in hours. Then the launches started breaking.

AI coding assistants are incredible at getting a working prototype on screen. What they're terrible at is the part that comes after: the quiet, boring, unglamorous work of making sure the thing is safe to put in front of real users. I've watched the same failure patterns repeat across AI-generated apps — broken Supabase RLS policies that leak one tenant's data to another, API keys committed straight into the repo, Stripe integrations that handle the happy path and fall over on webhooks and refunds, auth that lives in the frontend while the API trusts everyone, and public endpoints with no rate limiting at all.

The prototype works. Nobody checked whether it's safe to launch. That's the gap I built prod-readiness to fill.

What it is

prod-readiness is a Claude Code plugin that runs a read-only, whole-repository production-readiness audit. It answers one question: is this app safe to launch?

It works in three stages:

One shared evidence pass over the repo, so every finding is grounded in actual code, not vibes.
Eight specialist lenses — security, backend, database, DevOps, QA, frontend, AI security, and runtime — each writing evidence-tagged findings from that shared pass.
A verdict: SHIP, FIX THEN SHIP, or HOLD. CTO-readable, backed by an absence ledger that distinguishes controls that are confirmed, not found, or unverified.

It's deliberately read-only. It never touches your code — it produces the audit trail under .readiness-audit/ and tells you what's wrong and where. There's also an optional local dashboard if you want to watch the audit run in your browser.

Why a plugin, not another scanner

Keyword scanners catch secrets in code. They don't catch the structural stuff that actually kills launches: missing recovery paths, unsafe trust boundaries, untested webhook handlers, operational blind spots. The eight-lens design exists because production readiness is a systems question, not a grep question. Each lens looks at the same evidence from a different angle, the way a real review team would.

Try it on your own app

You only need Claude Code installed. Three commands:

/plugin marketplace add Taimoorkhan1122/prod-readiness

/plugin install prod-readiness@prod-readiness-marketplace

/reload-plugins

Then point it at any repo and run:

/prod-readiness:production-readiness-audit

If the idea of running a full multi-agent audit makes your laptop fans spin up, there's a sequential mode too:

/prod-readiness:production-readiness-audit sequential

What I'm looking for

This is early and I'm actively improving it. If you vibe-code apps — especially ones heading toward real users and real payments — run it and tell me what it missed. The findings that matter most are the ones I haven't thought of yet.

Repo: https://github.com/Taimoorkhan1122/prod-readiness — stars and issues both welcome.

Navigate Github repos as in VS code

Taimoor khan — Thu, 11 Feb 2021 18:49:39 +0000

you can navigate github repos just like in VS Code by adding 1s in githubs domain name like www.github.com/some-repo will become www.github1s.com/some-repo

Source

How to add dynamic colors in Chartjs

Taimoor khan — Wed, 23 Dec 2020 08:40:45 +0000

If you are stuck in hardcoding color values for each dataset and whenever there is new entry in a dataset your code broke, if yes this article is for you...

Recently I was working with chartjs in React. Every time a new data was populated I had to add new color values for that label and data manually, after spending about 1.5 hours on the internet, I finally found a solution to dynamically add colors in chartJS.

Setting up project

You can use this replit for your reference, just start the project and start playing.

Explanation

Following this amazing article, using D3's Chromatic color scale, we will be creating dynamic color ranges for our charts, D3's Scale Chromatic library provides many color scales, we have used their interpolate color scales. All of the interpolate color scales have a domain of [0, 1]. If you want to get deeper check out this amazing article. To simplify, I have created a function chartData()

chartData() returns data object which we can then pass to any Chart component. This function accepts a data object which contains labels, colorRangeInfo, scale and dataLabel

chartData({
    labels: ["China", "UAE", "Yemen", "Pakistan", "Saudia"],
    colorRangeInfo: {
    colorStart: 0,
    colorEnd: 1,
    useEndAsStart: false,
    },
    scale: d3.interpolateBlues,
    dataLabel: "data for doughnut chart",
})

Labels : accepts list of data labels which will be displayed as labels.

colorRangeInfo() : accepts object containing d3 chromatic color range (0,1) useEndAsStart : true will reverse the color range.

const colorRangeInfo = {
    colorStart: 0,
    colorEnd: 1,
    useEndAsStart: false,
};

The scale property accepts d3.interpolate which gives you various combinations such:
interpolateIferno

interpolateCool

You can play around with different variation by using different interpolate color scales.

Please share your thoughts if this article was useful for you. I would love hear back from you guys if you have any better solution for this.

The Rust

Taimoor khan — Fri, 04 Dec 2020 07:26:36 +0000

According to StackOverflow's Developer Survey Rust is most loved programming language for developers for past consecutive 5 years.

Rust is a statically typed programming language that promises Safety and Performance. It has modern yet hard to digest syntax and provides low level control (such as memory usage, pointers etc).
Rust is statically typed compiled language without anything like Garbage Collectors.

Question: How does Rust guarantee memory memory safety?
Answer: Rust manages memory through a system of Ownership with a set of rules that the compiler checks at compile time.

Hello World

Let's write our first program in Rust.

fn main(){
  println!("Hello World");
}

User Input In Rust

Some types are not included in prelude so we need to explicitly call them into the scope by using use keyword. The std::io library provides number of useful features, including the ability to accept user input.

use std::io;

fn main(){
  println!("Your good name?:");

  let mut user_in = String::new();
  io::stdin()
      .readline(&mut user_in)
      .expect("something happened!");

  println!("Happy coding {}", user_in); 


}

Do you think rust will dominate other statically typed languages?