DEV Community: Muhammad Tayyab

The most valuable part of an agent prompt is the list of things it refuses to do

Muhammad Tayyab — Tue, 22 Sep 2026 13:54:47 +0000

Anthropic open sourced its reference agents for investment banking, equity research and fund administration. Ten of them, Apache-2.0, sitting at 36,000 stars.

The agents are interesting. The thing I would actually steal is five lines near the top of the README.

Capability is the easy half

Anyone can write an agent prompt that says what to do. "You are an expert financial analyst. Build a DCF model." That takes a minute, and it is the part every agent repo shows you.

Here is what these prompts also say, verbatim:

They do not make investment recommendations, execute transactions, bind risk, post to a ledger, or approve onboarding; every output is staged for human sign-off.

Five refusals. Read them again and notice they are not generic safety hedging. Each one names a specific action in a specific workflow, and each one is the exact point where drafting becomes deciding.

The KYC agent parses onboarding documents and flags gaps. It does not approve onboarding. The reconciliation agent traces a break to its root cause. It does not post to the ledger. The model builder builds the DCF. It does not tell you the company is undervalued.

Each of those lines is a conversation somebody had

That list did not come from a prompt engineer being careful. It came from compliance officers at regulated firms drawing a line, and somebody writing the line down where the model can see it.

That is why it is worth reading even if you will never open a comps table. Most of us write agent prompts by accumulating capabilities until the demo works. Almost nobody writes the boundary first, because the boundary is invisible until the agent crosses it, and by then you are explaining an incident rather than a design.

The pattern generalises cleanly. A support agent that drafts refunds but does not issue them. A deploy agent that prepares the release but does not promote to production. An HR agent that screens applications but does not reject candidates. In every case the valuable sentence is the second half, and in every case it is the half that gets left out.

Try it on something you already built

Take an agent prompt you have shipped. Write down the five actions it must never take, phrased as concretely as the list above. Not "be careful with user data" but "does not delete records" and "does not send email to customers".

If that list is hard to write, that is the finding. It usually means the boundary was never decided, only assumed, and an assumed boundary is one the model has no way to respect.

Then keep the list under version control and diff it when you change the prompt, because refusals get quietly dropped during a rewrite far more often than capabilities do. A plain text diff between prompt versions catches it in seconds.

Fuller write-up of the repo, including what running these agents actually costs once you count the data subscriptions: Claude for Financial Services.

Free market data is not free, it is delayed by fifteen minutes

Muhammad Tayyab — Mon, 21 Sep 2026 14:25:53 +0000

Every developer builds a stock tracker eventually. It is the perfect side project: a clean API, obvious features, and a result you actually use.

Then you ship it, compare a number against your broker, and find you are fifteen minutes behind.

This trips up almost everyone the first time, because nothing about "free tier" prepares you for it. The tier is not rate-limited into uselessness. It is time-shifted.

The exchange owns the price, and it sells it

A stock price is not a public fact like the weather. It is proprietary data produced by an exchange, and exchanges license it. NYSE, Nasdaq and the rest run market data as a real revenue line, with per-user fees, redistribution agreements and audits attached.

So when an API offers a free tier, it cannot give you what it does not have the right to give you for free. What it can do is wait. Delay the quote past the licensing threshold, typically fifteen minutes, and it stops being the licensed real-time product.

That single constraint explains a pattern you have probably noticed without naming it: free finance APIs converge on the same shape. Delayed quotes, generous historical data, thin real-time. Historical data is cheap to license because it is no longer tradeable. The present is the expensive part.

Which is why the honest projects say so

I spent some time in OpenStock, a 17,000-star self-hosted market dashboard built on Next.js. What made it worth writing about is not the feature list. It is that the README says this out loud:

Market data may be delayed based on provider rules and your configuration.

And in the market support docs: non-US symbols delayed by fifteen minutes or more on free tiers, with some emerging markets unavailable on the free chart tier at all.

Compare that to the usual framing, where "real-time prices" sits in the headline and the asterisk lives somewhere you will find after you deploy it.

What you can still build

None of this makes the project pointless, and it should not stop you building yours. It just means being clear about which application you are building.

Delayed data is completely fine for a watchlist, for research, for fundamentals, for end-of-day summaries, for alerting on moves you are going to act on over days rather than seconds. That is most private investors, most of the time.

Delayed data is useless for anything where the fifteen minutes is the whole point. If your idea only works with live quotes, the software was never the hard part. The data licence is, and it is priced accordingly.

The practical move when you are evaluating any market API: pull one symbol, write down the timestamp the payload carries, and compare it to the wall clock. Dumping a few responses through a JSON to CSV converter and eyeballing the timestamp column tells you in about two minutes what the pricing page will not.

Fuller write-up of OpenStock, including why AGPL-3.0 matters much more for a web app than a desktop one: OpenStock.

Your agent should not be clicking buttons in an app you wrote

Muhammad Tayyab — Sun, 20 Sep 2026 12:39:33 +0000

A few days ago I wrote about a tool that lets agents drive your real browser. It is a good tool. Browser automation exists because most software does not expose an API you are allowed to use, so teaching an agent to click is the only way in.

Then people take that pattern and point it at their own application. That is where it stops making sense.

You are making the agent reverse-engineer your own server

Think about what happens when an agent clicks a button in an app you built.

Your server has the record. Structured, typed, validated. It serialises it to JSON, ships it to the browser, React turns it into DOM nodes, and then the agent reads those DOM nodes and tries to reconstruct the object your server had in the first place.

Every layout change breaks it. Every loading state is a race. You pay tokens for a screenshot or an accessibility tree to recover data you already had in the right shape one hop earlier.

You did not need an agent that can use your interface. You needed an interface and an agent that call the same thing.

One schema, six callers

Builder.io's Agent-Native is built on that. You define a capability once as an action: a zod schema and a run function. Then the agent gets it as a tool, React calls it with a hook, and it is simultaneously an HTTP endpoint, an MCP tool, an A2A endpoint and a CLI command.

The detail I like most is where the prompt engineering lives. The action's description, and .describe() on each schema field, become the tool description and parameter docs the model reads. They sit in the same file as the implementation, so they cannot drift from it. Anyone who has maintained a tool manifest in a second file knows exactly how that drift goes.

The schema is doing triple duty: generating the JSON Schema the model sees, validating what the UI sends, and validating what the agent sends. If you are hand-writing tool definitions today, a JSON Schema generator makes it obvious how much boilerplate that single declaration is replacing.

Where this does not apply

Say the limit plainly. This only works for software you build this way. It has nothing to offer for the SaaS tools you do not control, and there the browser-driving approach is still correct.

It is also not generative UI, which is a different thing that keeps getting conflated with it. Generative UI means the model produces the interface at runtime. Here the interface is hand-authored and the agent gets the same actions, not the ability to invent screens.

The rule I would take away: drive the browser for other people's software, share the action layer for your own. If you are doing the first for the second, you built an API and then decided to consume it through a picture of itself.

Fuller write-up, including the nine open-source reference apps and a licensing footnote worth knowing: Agent-Native.

Your self-hosted AI stack probably needs one process, not six

Muhammad Tayyab — Sat, 19 Sep 2026 12:03:01 +0000

Open the compose file for almost any self-hosted AI assistant. You will find an app container, Redis for the queue, Postgres for state, a worker, usually a vector database, often a reverse proxy.

Six services. For a household of five.

Then ask what that architecture is actually buying you at that scale. The queue exists so work survives a restart and so you can scale workers horizontally. You are not scaling workers horizontally. You have one box under a desk.

The queue is solving a problem you do not have

A broker earns its place when producers and consumers scale independently, when work must survive the process that accepted it, or when several services need the same event. Those are real problems at real scale.

At five users, none of them apply, and you have paid for all of them anyway. Six services is six things that can fail, six sets of logs, six version upgrades, and a debugging experience where a symptom in the UI has its cause three hops away in a container you were not looking at.

TencentCloud's Octop takes the other branch. One process serves the web dashboard, the CLI backend, every chat channel and the cron scheduler. No broker. Every surface routes through one in-process handler, and the entire runtime state is rebuilt from a SQLite control-plane database on boot.

That last clause is the part doing the work. Restart-safety usually comes from durable queues plus careful shutdown handling. Here it comes from the process holding no authoritative state at all. Kill it however you like. On boot it reads the database and reconstructs itself. There is nothing in memory worth preserving, which is a much stronger property than preserving it well.

SQLite in WAL mode is not the compromise here

The reflex is that SQLite is the starter option you outgrow. For a concurrent-reader, low-concurrent-writer workload on one machine, it is simply the correct choice. No connection pool, no second daemon, no tuning, and your backup is a file copy.

Octop offers Postgres as an option rather than an assumption. That ordering is the tell that someone thought about the actual workload instead of copying a reference architecture.

Where this breaks

Say the limits out loud, because they are real. One process is one failure domain. You cannot put the chat gateway on one box and the agent runtime on another. There is a user count past which this stops being clever and starts being a bottleneck.

For a household or a team of five, that ceiling is theoretical and the operational simplicity is banked every single day. For fifty concurrent users it is the wrong shape.

The practical version: before you self-host anything with remote access, your upload bandwidth decides whether it is usable at all, and a speed test answers that faster than finding out later.

Fuller write-up, including two caveats worth knowing before you run the installer: Octop.

Your experiment tracker records metrics precisely and code approximately

Muhammad Tayyab — Fri, 18 Sep 2026 12:57:09 +0000

Try to reproduce a result you got six months ago. Not someone else's result. Yours.

The metrics are fine. Your tracker has the loss curve to four decimal places, the hyperparameters, the wall-clock time, a chart. What it has for the code is a commit hash. You paste it into git show and get unknown revision, because that branch was rebased in March.

This asymmetry is everywhere and almost nobody names it. Experiment trackers are precise about outputs and vague about inputs.

A commit hash is a pointer, not an archive

A hash only resolves if the object is still reachable. Rebase the branch, squash the PR, delete the fork, garbage-collect the repo, and the number in your tracker becomes a string that used to mean something.

Worse, it fails silently and asymmetrically. The metrics still render. The chart still draws. Nothing in the UI tells you the other half of the record has evaporated. You find out at the exact moment you need it, which is the moment you are trying to defend a number to someone.

And that is the happy path, where the code was committed at all. The real one is a tracker row pointing at a dirty working tree from a Tuesday afternoon.

alphaXiv's OpenResearch inverts the relationship

Most tools bolt a tracker alongside version control and have the tracker reference git. OpenResearch makes git the tracker. Experiment variants live in a git-native tree, and every run gets an immutable archive of the commit it was recorded against, not a pointer to one.

The consequence is small to state and large in practice: the lineage of an idea and the lineage of the code become the same graph. You stop maintaining two systems that agree with each other only as long as nobody rebases.

It pairs with the other thing it does, which is giving each research direction its own agent session and its own git worktree instead of its own clone. Isolation without duplication, and the worktree lives as long as the hypothesis rather than as long as the session.

The question worth stealing

You do not have to adopt anything to use this. Go to your tracker, pick a run from more than three months ago, and try to check out the code that produced it.

If the hash resolves, good, you have more discipline than most teams. If it does not, you have just learned that half of what you thought was recorded was never recorded, only referenced.

One small adjacent habit: the loss values and learning rates in these runs are far easier to compare as exponents than as long decimals, and a scientific notation converter beats counting zeros in a terminal.

Full write-up on how OpenResearch handles worktrees, parallel agents and a loopback caveat worth knowing before you run it on a shared cluster: OpenResearch.

A CLI flag is not a security boundary, and one browser tool just proved it

Muhammad Tayyab — Thu, 17 Sep 2026 13:03:27 +0000

Tencent released BrowserSkill, a tool that lets AI agents drive the browser you are already logged into. The obvious story is the capability. The interesting story is a breaking change buried in version 0.3.0.

Before 0.3.0 you could run an agent's browser session unattended by passing --unattended, or tab borrow --no-confirm, or setting BSK_REQUEST_HELP=off. Each one skipped the confirmation prompt that normally asks before the agent takes control of one of your tabs.

In 0.3.0, none of them work any more. They are still accepted, they are deprecated, and they cannot override anything. The only way to disable confirmation now is a toggle in the browser extension's popup.

The flag was being set by the wrong party

Think about who actually writes that flag.

You are not typing bsk tab borrow --no-confirm yourself. An autonomous agent is composing that command, because composing shell commands is the entire interface. So the safety check and the thing being checked were arriving from the same source. The agent asks for permission and, in the same breath, supplies the argument that waives it.

That is not a security boundary. That is a suggestion with extra steps.

Prompt injection makes it concrete. A page your agent reads can contain text aimed at the agent. If a flag can waive confirmation, then the payload only has to convince the model to add six characters to a command it was already going to run. No exploit, no privilege escalation, just a string in a command line.

Authority has to live where the attacker cannot reach

The fix is not a better flag. It is moving the decision out of the channel the attacker can influence.

A browser extension setting is a decision a human made once, deliberately, in a UI no agent can type into. The agent can request; it cannot grant. The asymmetry is the whole point, and it is the same reason sudo prompts on a terminal rather than reading a variable your script set.

The docs are blunt about the cost, too: scripts that relied on those flags alone will now sit waiting for a confirmation nobody answers. They broke working setups on purpose rather than leave a bypass that looked like a feature.

The question to ask of your own agent tooling

Every agent integration eventually grows a "skip the prompt" path, because somebody needs it for CI. Worth asking: can the agent itself set that flag? If yes, it is decoration.

There is a related habit worth keeping. Before pointing an agent at a browser profile, check what that profile actually exposes to a site with the IP checker and decide whether you want an autonomous process acting from it. Most people should use a second profile.

I wrote up the rest of BrowserSkill, including the architecture and how it differs from browser-use and Claude in Chrome, here: BrowserSkill: letting agents use your real browser.

A local ElevenLabs alternative with 30k stars, and the licence trap in its default engine

Muhammad Tayyab — Thu, 17 Sep 2026 07:49:48 +0000

VoiceStudio does voice cloning, video dubbing, dictation, transcription and audiobook production, all on hardware you already own. No account, no API key, no usage meter. Tauri v2 shell, React interface, FastAPI backend, past 30,000 stars since April 2026.

It is good. The part most coverage skips is the part that can actually bite you.

Two licences, and the permissive one is not the one that matters

The application is AGPL-3.0. Run it, modify it, use it internally, all fine. Offer a modified version as a network service and you owe your source under the same licence.

The default engine is the one to watch. OmniVoice ships as Apache-2.0 code with CC-BY-NC weights. Non-commercial. So the out-of-the-box configuration, the one you get if you install it and start generating, produces audio from non-commercially-licensed weights.

If you are making anything commercial, switch engines deliberately. Several are Apache-2.0 end to end:

Engine	Languages	Clones	Licence
OmniVoice (default)	600+	Yes	Apache-2.0 code, CC-BY-NC weights
CosyVoice 3	9 + 18 dialects	Yes	Apache-2.0
VoxCPM2	30	Yes	Apache-2.0
MOSS-TTS-v1.5	31	Yes	Apache-2.0

The project documents this. The write-ups are what gloss over it.

646 languages is a catalogue size, not a promise

The headline number comes from the default engine covering 600 or more. The other fifteen engines are nowhere near it: CosyVoice 3 handles 9 plus 18 dialects, VoxCPM2 covers 30, dots.tts 24, Supertonic 31.

So "646 languages" really means one engine has a very large catalogue. Pick the engine for your language and check that one specifically.

Cloning is zero-shot, which saves you effort

The reference clip is a prompt, not training data. Nothing is fine-tuned on your voice. The model listens to a short sample and conditions on the timbre it hears, which is why it finishes in seconds.

Three seconds of audio is enough to work
Five to fifteen seconds sounds noticeably better
A cleaner clip beats a longer one, every time

If you were planning to record twenty minutes of reference audio, you do not need to.

The bit developers will care about

The backend exposes an OpenAI-compatible audio API. Migrating is one line:

- base_url="https://api.openai.com/v1"
+ base_url="http://localhost:3900/v1"

Anything written against OpenAI's speech endpoints keeps working, now against local compute at no per-request cost.

One ask: it embeds AudioSeal watermarking by default. Leaving it on costs you nothing, so leave it on, and clone a voice only with the consent of the person it belongs to.

Full write-up with all sixteen engines, the dubbing pipeline, hardware requirements and the hosted comparison: VoiceStudio: local voice cloning and dubbing in 646 languages.

For audiobook work I run scripts through a word counter to estimate runtime first, and an AI proofreader to catch typos that TTS will otherwise read aloud with total confidence.

Anthropic publishes Claude's system prompt. The captured version is 13 times longer.

Muhammad Tayyab — Thu, 17 Sep 2026 07:48:39 +0000

Every AI product reads a block of instructions before it ever sees your message. Who it is, what it refuses, how it formats answers, what it must never say. You do not write it and you are not shown it.

One repo has captured 430 of them, organised by vendor. The leak angle is the boring part. Here is what is actually useful.

The 13x gap

Anthropic publishes its Claude system prompts. Openly, on purpose, in the release notes. The repo stores those too, so you can put the published version next to the captured one.

They are not the same size:

Official, published by Anthropic: 4,269 words
Captured from the running product: 56,148 words

Roughly 13 times larger.

That gap is not a scandal. Published prompts legitimately exclude tool definitions, per-surface instructions and operational scaffolding. But if you were studying the published version to learn how a frontier team writes prompts, you were reading a summary and did not know it.

Dropping both into a text diff is the fastest way to see what the published version leaves out. That is the exercise I would actually recommend from this repo.

What the prompts reveal

Read enough and patterns show up that no marketing page would state.

Enormous effort goes into tone, not capability. Large fractions of every prompt are spent on how to sound. Do not open with flattery. Do not pad with caveats. Do not moralise. Vary sentence length. Providers clearly treat default LLM voice as a serious product problem and spend real prompt budget on it.

Refusals are far more specific than public policy. Published safety policies are broad and principled. The prompts contain concrete enumerated categories. If a model ever refused something oddly specific, this is where that lives.

If you write system prompts for your own product, this is the closest thing to watching how the best-funded teams in the industry solve your exact problem. The formatting rules alone will improve your output.

Stay sceptical

The repo says prompts are captured verbatim. Treat that carefully.

These are extracted by asking the model to repeat its instructions. It works because the prompt genuinely is in context and the model can read it back. But a model reproducing text from its context is not a guaranteed faithful copy. It can paraphrase, skip, smooth a section, or in the worst case confabulate something plausible.

Treat them as high quality evidence, not primary source documents. Patterns across many files are trustworthy. Any single exact sentence is less so.

Longer version covering what a system prompt is from scratch, the full vendor breakdown, and whether any of this is legal: What is a system prompt? 430 real ones, captured from every major AI.

Why there are almost no open source WhatsApp CRMs

Muhammad Tayyab — Thu, 17 Sep 2026 07:47:06 +0000

Search for a self-hosted WhatsApp CRM and you find almost nothing. Plenty of email CRMs, plenty of open source helpdesks, close to zero for the channel a huge share of the world actually sells on.

That is not an accident, and the reason explains every design decision in DeskcommCRM, the most complete attempt I have seen.

The structural problem

WhatsApp has no open protocol. There are exactly two ways to send a message programmatically, and both are uncomfortable for an open source project.

1. The official Meta Cloud API. Legitimate, stable, what Meta wants you to use. It also requires business verification, charges per conversation, and restricts you to pre-approved templates outside a 24-hour service window.

2. Unofficial libraries driving a real WhatsApp Web session. No verification, no per-conversation fee, full freedom. Also against WhatsApp's terms, and the account can be banned.

Now think like a maintainer. Option one means every user needs a verified Meta business account and a billing relationship before your software does anything, which kills casual adoption. Option two means shipping something that can get your users banned.

Most projects look at that fork and go build an email CRM. That is why the category is empty.

What makes this one different

MIT licensed, TypeScript on Next.js 16, self-hosted, database on your own infrastructure. Pitched as the open alternative to Kommo, Octadesk and Intercom.

Plenty of CRMs bolted an AI panel on in the last two years. The distinction here is that the agent has hands. It can operate the CRM, not just draft replies.

Per-tenant RAG. Each organisation gets its own knowledge base, embedded with pgvector in Postgres. The agent answers from your documents, your pricing, your policies, rather than a general model's guesses about your business.

Skills it runs on its own. Mid-conversation it can execute a defined action instead of asking a human to go do it. That is the line between a chatbot that suggests and an agent that acts, and it is the part to evaluate carefully before letting it near real customers.

What you are signing up to operate

A Next.js app, Postgres with pgvector, a WhatsApp connection that must stay authenticated, and an LLM provider with per-token billing.

The WhatsApp session is the piece that will page you. Sessions drop, and a dropped session means your sales channel is silently down. The costs not in the README are the tokens and your own time keeping that connection alive. Neither is huge, both are non-zero, and per-seat SaaS pricing starts looking reasonable after the second page.

Worth it if you sell over WhatsApp at real volume and someone on the team can own a Postgres app. Not worth it if WhatsApp is a side channel.

Full breakdown with the stack, install path, the real costs and the comparison against Chatwoot and Kommo: DeskcommCRM: an open source WhatsApp CRM with AI agents built in.

Migrating contacts in? Exports almost always arrive as spreadsheets, so CSV to JSON and JSON to CSV cover most of the reshaping before import.

Running a 744B parameter model on a desktop, and why the trick is placement rather than compression

Muhammad Tayyab — Thu, 17 Sep 2026 07:46:02 +0000

Most "run a big model at home" projects are really compression projects. Quantize harder, prune, distill, and eventually a smaller model wearing a big model's name fits in your VRAM.

Colibri does something else, and the idea is worth understanding even if you never run it. It is an inference engine in pure C. One file. No BLAS, no Python at runtime, no GPU required. It runs Mixture-of-Experts models from 744 billion to 2.8 trillion parameters on hardware you already own.

Don't fit the model, place it

A 744B MoE model does not use 744B parameters per token. It activates roughly 40B, about 5.4%, and of those only around 11 GB actually change from one token to the next.

So the model never needed to fit in fast memory. It needed to be placed:

The dense part, attention and shared experts and embeddings, about 17B parameters, stays resident in RAM at int4. Roughly 9.9 GB.
The 19,456 routed experts, about 19 MB each, live on disk at around 372 GB and get streamed on demand, with a per-layer LRU cache and a learned hot-store of pinned experts.

The project's own analogy is the one that makes it click: a JIT, but for weights.

A compiler JIT never compiles the whole program. It watches what actually runs and compiles hot paths just in time. Colibri makes the same bet about a 744B parameter space. Parameters are not resident state to be held, they are data to be staged, exactly when needed. The router runs a layer ahead so prefetch hides the latency, and routing heat decides which experts earn which tier.

It works because expert routing has measurable structure, and structure is cacheable.

The numbers, which are the honest part

Hardware	Decode speed
6x RTX 5090, full residency	5.8 to 6.8 tok/s
128 GB CPU-only desktop	~1.8 tok/s warm
Single RTX 5070 Ti, laptop class	1.07 tok/s
25 GB dev box	0.05 to 0.1 tok/s cold

That is the real answer to "can I run a 744B model at home?" Yes, at roughly one to two tokens per second.

Not a gotcha, just the trade. Interactive chat, unusable. Batch analysis, overnight jobs, or privacy-critical work where the alternative is shipping data to an API, entirely fine.

The barrier most people hit is not the GPU, which is optional. It is 372 GB of fast NVMe, because expert streaming is read-bound.

Full breakdown with the placement mechanics, the comparison against llama.cpp and Ollama, and the caveats worth knowing before you clear that much disk: Colibri: self-host a 744B LLM on hardware you already own.

If you are cleaning up model output afterwards, a Markdown converter saves hand-fixing every code fence.

Cloudflare open sourced a security auditor, and its best idea has nothing to do with security

Muhammad Tayyab — Thu, 17 Sep 2026 07:41:45 +0000

Cloudflare has open sourced the security audit skill that seeded its internal vulnerability discovery harness. MIT licensed, past 5,500 stars in about three months.

It is not a scanner. It is a skill, a folder of structured instructions a coding agent loads and follows. You point Claude Code, Codex or Cursor at a repo, ask for a security audit, and it runs a fleet of isolated sub-agents through six phases.

The security part is good. The part worth stealing is one line in the design principles.

The agent that checks is never the agent that found it

Anyone who has asked a model to review its own output knows why this matters.

A model that just spent 4,000 tokens arguing a piece of code is vulnerable is primed to keep agreeing with itself. Ask it to double check and it checks in a way that confirms. You do not get verification, you get a second draft of the same opinion, written with more confidence because now it has "checked".

Most projects paper over this with a prompt that says "be critical". This one removes the option. The verifier is a separate agent, spawned fresh, with no memory of the hunt that produced the candidate. It cannot be primed by reasoning it never saw.

That is architecture instead of instruction, and it is the difference between hoping for rigour and enforcing it. If you build agent pipelines of any kind, copy this. Whenever one agent produces a judgement and another validates it, the validator should start cold.

Three verdicts, and the middle one earns its place

Most scanners give you a finding or silence. This gives three states:

Verdict	Meaning
`confirmed`	Complete source trace, bounded observed result
`needs_validation`	Real lead, one exact unresolved fact, no severity
`rejected`	Disproved by a verifier, kept on the record

needs_validation is where an honest system puts work it could not finish. A tool that only emits confirmed or nothing has to make a silent call on every borderline case, and you never learn which ones it dropped. Here the unfinished work is visible and carries no severity, so it cannot inflate a report beyond what the evidence supports.

Keeping rejected matters too. Re-runs do not burn another fleet of agents rediscovering the same dead end.

I wrote up the full thing, all six phases, the coverage ledger, the attack class library, and the OS-level sandbox requirement most people will skip: Cloudflare's Security Audit Skill: an AI auditor built to disprove itself.

Two things I keep open while reading agent output: a JWT decoder for auth findings, and JSON compare for diffing findings between runs, which is how you see what a second audit actually added.

I Built a Free Code Sharing Tool Because Pastebin Has Too Many Ads

Muhammad Tayyab — Wed, 01 Apr 2026 17:03:28 +0000

Every developer shares code snippets. Daily.

During code reviews, pair programming, debugging sessions, Slack conversations, Stack Overflow questions — we're constantly copying and pasting code between places.

And yet the tools we have for this are either:

GitHub Gist — great, but requires login. Too much friction for a 15-line snippet you'll forget about tomorrow.
Pastebin — been around forever, but the ads have gotten unbearable. Also no real syntax highlighting.
Hastebin — was perfect. Minimalist, fast. But it's been unreliable lately.
Pasting into Slack/Discord — formatting gets destroyed. Anything over 10 lines becomes unreadable.

So I built my own: Code Share on DevPik

What It Does

Exactly what you'd expect, nothing more:

Paste your code
Pick a language (20+ supported)
Optionally add a title and expiry time
Click "Share Code"
Get a short URL — send it to anyone

That's it. The person who opens the link sees your code with syntax highlighting, a copy button, and the language badge. No login wall. No ads. No cookie banners.

The Expiry Feature

This is the one thing I wanted that most paste tools don't offer well. Not every snippet needs to live forever.

You can set expiry to:

1 hour — for "hey look at this real quick" moments
24 hours — for code review discussions that'll be done by tomorrow
7 days — for sprint-length collaboration
30 days — for longer projects
Never — for permanent reference snippets

Expired links return a clean 404 instead of stale code floating around forever.

How I Built It

Frontend: Next.js (App Router) + TypeScript + Tailwind CSS

Backend: Supabase (PostgreSQL)

How it works:

When you click "Share Code", the frontend sends a POST request to a Next.js API route. The route generates a random 8-character alphanumeric short code, inserts the snippet into a pastes table in Supabase, and returns the shareable URL.

When someone opens a shared link (devpik.com/p/abc12345), a server component fetches the paste by short code, checks if it's expired, increments the view count, and renders the code with syntax highlighting.

The database schema is simple:

CREATE TABLE pastes (
  id UUID DEFAULT gen_random_uuid() PRIMARY KEY,
  short_code TEXT UNIQUE NOT NULL,
  title TEXT DEFAULT 'Untitled',
  content TEXT NOT NULL,
  language TEXT DEFAULT 'plaintext',
  view_count INTEGER DEFAULT 0,
  expires_at TIMESTAMPTZ,
  created_at TIMESTAMPTZ DEFAULT now()
);

Row Level Security is enabled — anyone can insert and read pastes, but nobody can update or delete them (except through the admin dashboard).

Supported Languages

JavaScript, TypeScript, Python, HTML, CSS, JSON, SQL, Bash, Go, Rust, Java, C, C++, PHP, Ruby, Swift, Kotlin, YAML, XML, Markdown, and Plaintext.

Syntax highlighting is handled client-side so the code never needs to be processed by any external service.

What I'd Like to Add Next

A few things I'm considering:

Password-protected snippets — for sharing sensitive code privately
Fork/edit — click a button to create a new snippet based on an existing one
Raw text endpoint — devpik.com/p/abc12345/raw for piping into curl
CLI tool — cat file.js | dpk to create a paste from terminal

Try It

👉 devpik.com/developer-tools/code-share

No login. No ads. No tracking. Just paste code, get a link.

If you share code snippets regularly, give it a try and let me know what's missing. I'm building this based on what developers actually need, so feedback goes directly into the next update.

I'm Tayyab — I build free developer tools at devpik.com. This is one of 24 tools on the site, all free, most running 100% in the browser. Follow me for more.