DEV Community: kennedy

Your SBOM diff is lying to you - how we made SBOM generation byte-for-byte reproducible

kennedy — Wed, 21 Oct 2026 08:05:01 +0000

If you've ever diffed two SBOMs of the same codebase - before and after a dependency bump, two CI runs, two laptops - you've seen the lie: a wall of changes that aren't changes. Timestamps move. Serial numbers rotate. Keys shuffle. The components didn't move; the document did.

The problem with noisy SBOM diffs

The CycloneDX and SPDX standards let generators stamp created with the wall-clock and serialNumber with a fresh UUID on every run. So two runs over identical inputs produce different bytes - and your "SBOM diff" flags changes that don't exist. Reviewers learn to rubber-stamp the diff, and the one time it hides a real change, nobody looks.

Deterministic generation makes the diff mean something:

same input → same bytes → every difference is a real difference.

How SnapSBOM makes output byte-for-byte reproducible

Pinned timestamp - created / creationInfo.created is fixed to 2026-01-01T00:00:00Z, never the wall clock.
No serial numbers or UUIDs, anywhere.
Canonical ordering + normalized serialization - components sorted stably, keys emitted in a fixed order.
Lockfile-only input - it reads package-lock.json and nothing else. No network. No node_modules. No calls to npm. The bytes you get in Berlin equal the bytes you get in Denver.

But deterministic ≠ correct - the proof

We don't ask you to trust us; we ask you to run the checks:

Check	Result
Official CycloneDX 1.6 JSON Schema (via `ajv`)	✅ valid
Official SPDX 2.3 JSON Schema (via `ajv`)	✅ valid
Syft 1.55.0 - converts our CycloneDX → SPDX and SPDX → CycloneDX	✅ all 66 components round-trip
Trivy 0.76.0 - vulnerability scan of both our documents	✅ both formats detected, 66/66 packages ingested
`@cyclonedx/cyclonedx-npm` 6.0.1 cross-check	✅ identical package set, 0 purl differences
Re-run SnapSBOM on the same lockfile	✅ byte-identical
Re-run Syft / cyclonedx-npm on the same input	❌ timestamps and serials churn

Three independent implementations - Syft, Trivy, and cyclonedx-npm - converge on the same 66 packages. Our output is valid because the specification says so, not because we say so.

Reproduce it in 60 seconds

npx snapsbom . --format cyclonedx --output a.json
npx snapsbom . --format cyclonedx --output b.json
diff a.json b.json && echo "byte-identical"

trivy sbom a.json          # ingests our CycloneDX
syft convert a.json -o spdx-json=converted.spdx.json

Honest scope
SnapSBOM guarantees correctness for npm package-lock.json v1-v3 and says so plainly - pnpm, Yarn, and Python are on the roadmap, one parser at a time.
MIT-licensed, written in Rust, single binary.

Repo: https://github.com/kawacukennedy/snapsbom
npm: https://www.npmjs.com/package/snapsbom
GitHub Action: https://github.com/kawacukennedy/snapsbom-action
Docs: https://kawacukennedy.github.io/snapsbom/

SnapSBOM: Deterministic SBOMs in a Snap

kennedy — Mon, 12 Oct 2026 07:50:26 +0000

The Problem: SBOM Tools Are Too Heavy

If you've ever tried to generate a Software Bill of Materials (SBOM) for a project, you've probably run into one of these issues:

Bloated tooling - Tools require Docker, complex configurations, or cloud accounts just to generate a simple SBOM.
Inconsistent outputs - Run the same tool twice on the same codebase and you get slightly different JSON. That's terrible for verification.
Slow feedback loops - You shouldn't need to wait seconds (or minutes) for something this fundamental.
Overkill for most projects - If all you need is an SBOM from your lockfiles, why download a 100MB binary?

With regulations like the EU Cyber Resilience Act (CRA) pushing SBOM adoption, developers need something that just works without the enterprise bloat.

The Solution: SnapSBOM

SnapSBOM is a deterministic SBOM generator that runs instantly, locally, and produces identical output every single time.

npx snapsbom .

That's it. In milliseconds, you get a clean, standards-compliant SBOM.

Why It Stands Out

Deterministic by design – Same input → byte-for-byte identical output. This is critical for reproducible builds, audits, and supply chain verification.
Truly local-first – Zero network calls. Zero telemetry. Works offline and in air-gapped environments. Your dependency data never leaves your machine.
Runs anywhere – CLI, npx, and browser (WASM) all share the same Rust core, so results are identical everywhere.
Standards compliant – Outputs both SPDX 2.3 and CycloneDX 1.6.
Lightning fast – Parses lockfiles directly with no heavy filesystem scanning or container runtime.
Minimal by choice – Focused on doing one thing exceptionally well: generating correct, deterministic SBOMs.

Why Determinism Matters

Most SBOM tools serialize in arbitrary order. SnapSBOM canonicalizes everything (keys, arrays, components) so the hash of your SBOM is stable. This means:

Easier CI integration – You can diff, cache, and verify SBOM artifacts with confidence.
Better supply chain trust – Reproducible SBOMs make attestation and verification actually meaningful.
Compliance-ready – Auditors can rely on consistent, diffable artifacts.

Get Started Today

With npx (fastest):

npx snapsbom .

Install globally:

npm install -g snapsbom
snapsbom .

Or download a binary from GitHub Releases.

Open Source & Built for Developers

SnapSBOM is MIT licensed and built in Rust with a shared core for CLI and WASM. It's designed to be simple, fast, and reliable — the kind of tool you'd actually keep in your workflow.

GitHub: github.com/kawacukennedy/snapsbom
npm: npmjs.com/package/snapsbom
Live Demo: kawacukennedy.github.io/snapsbom
Issues/Feedback: Open an issue

If SnapSBOM saves you time or solves this exact pain point, I'd love your feedback. Star the repo if it's useful, or file an issue if you'd like to see support for more ecosystems!

SBOMs shouldn't be heavy. They should just work.

The Customer Discovery Filter That Replaced My Pitch Deck

kennedy — Mon, 24 Aug 2026 22:40:51 +0000

Last year I built a SaaS in six months. Polished UI, solid architecture, clean code. Launched to 12 signups. Zero paying users. Shut it down.

The postmortem was brutal but clear: I built something nobody needed. I fell in love with the solution before verifying the problem existed.

Since then I've been rebuilding my customer discovery process from scratch. Not with frameworks from books, with conversations that went sideways, signal that turned out to be noise, and a few lines that stuck.

Here's the filter I'm using now. It's not finished, but it's already better than anything I had before.

The Problem With "Would You Use This?"

Most founder advice says: talk to users, validate your idea, get feedback.

The problem is that feedback is cheap. People will tell you your idea is great, that they'd totally use it, that they'd pay for it. Then they won't.

The gap between what people say and what people do is where startups die.

I needed a filter that separated enthusiasm from commitment.

The Three Questions

When someone names a painful task, I stopped asking "would you want this automated?" Instead I ask three things:

1. The Receipt Question

"Walk me through the last time this actually hurt you."

Not "would this be useful?" but "when did it last cost you something?" A specific moment, a specific cost, a specific workaround they used instead.

If they can't anchor it to a specific incident, the signal is weak no matter how enthusiastic the answer sounds.

2. The Cost Question

"What stays broken if this never gets fixed?"

This separates complaints from costs. A recurring annoyance is a complaint. A recurring annoyance with a broken process and a willingness to change is a wedge.

3. The Switch Question

"Would you switch tomorrow?"

But with one caveat, the answer only counts if it attaches to a dated incident.

"When this broke last month, I spent two hours on it" counts.

"Yes, I would probably switch" doesn't.

If the switch answer cannot attach to a specific memory, it is still a wish describing itself as a decision.

The Ratio Test

Pass/fail isn't enough.

Twenty conversations where five produce dated incidents and fifteen produce adjectives is a different market than the reverse.

The filter gets sharper when you track two things:

Did one vivid story appear? (pass/fail)
How often does the same kind of costly incident repeat? (the ratio)

A founder with one dramatic anecdote and a shrug on frequency is a different signal from a boring incident that happens every week.

Both count as receipts. Only one of them is a market.

The Calendar Test

"How many times this month?"

This is the whole filter.

One dramatic story is a blog post. The same boring incident every week is a business.

You don't just need the story. You need the calendar.

"When did it last hurt?" gets the receipt. "How many times this month?" tells you if it's a market or an anecdote.

The Stall Index

There's an outside check that helps too: looking at public postmortems of stalled products.

The same split keeps showing up. The ones that moved had a current cost someone was already paying — a workaround, a bad alternative, an annoying manual step, a risk they were already living with.

The ones that stalled had interest, but not much cost.

Interest without cost is a compliment. Cost without a workaround is a market.

The Full Filter In One Sentence

Enthusiasm is cheap. A dated incident with a real cost is the receipt.

A vivid incident is not always a recurring one. The receipt proves the pain is real. The frequency tells you whether it is a market.

What I'm Doing With This

I'm running this filter against 20 more conversations before I publish the full version with interview questions baked in.

If you're building something and want to pressure-test your own discovery, steal these questions. Run them against your next five conversations. Track the ratio. See what holds.

I'll update this post with the refined version when it's ready.

This filter was built in a public thread on DEV where someone pressure-tested my frameworks in real time. The best ideas here aren't mine, they came from the conversation.

If you've run your own customer discovery that went sideways, I'd genuinely like to hear what you learned.

I built an open dataset tracking Africa's nuclear energy programs, here's what I learned

kennedy — Mon, 17 Aug 2026 22:00:46 +0000

Only one African country operates a commercial nuclear reactor. Egypt is building one. A growing group of countries are in various stages of IAEA milestones preparation.

The problem: announcements about these programs are scattered across government websites, IAEA press releases, and industry media. There's no neutral, cited, machine-readable source that ties it all together.

So I built one.

What AfrPowerOS is

AfrPowerOS is a free, open dataset tracking every African country's civilian nuclear-energy programme. It covers:

Programme phase: Exploring, Preparing, Under Construction, Operating
IAEA milestone status: which infrastructure issues are addressed
Regulators and implementing agencies
Planned capacity in GW
Vendors and agreements
Research reactors
Key events with dates

Currently covering 20 countries across the continent.

The honesty system

Every record carries a confidence label:

Label	Meaning
`Verified`	Confirmed from a primary source
`Inference`	Reasonable reading of verified evidence
`Speculation`	Hypothesis; treat as unproven
`Unverified`	Reported but not yet confirmed

Every fact has a source URL. No exceptions. If I can't source it, I mark it or leave it out.

Corrections go in as pull requests — public and reviewable.

Why Africa's nuclear programs matter

The numbers tell the story:

~600 million people in sub-Saharan Africa lack electricity
Africa hosts under 2% of global data-center capacity
Power is the binding constraint on AI infrastructure on the continent
The countries making decisions right now are choosing infrastructure that will last 40-60 years

The tech stack

Dataset: structured JSON with a JSON Schema validator
Validation: Python script, zero dependencies, runs in CI
Live site: static GitHub Pages with an interactive SVG map
Newsletter: automated weekly digest via Buttondown API
License: MIT (code), CC BY 4.0 (data)

git clone https://github.com/kawacukennedy/afrpoweros.git
cd afrpoweros
python3 scripts/validate.py

What's next

Expand to all 54 African countries
Add IAEA "19 infrastructure issues" readiness tracker per country
Monthly data updates with changelogs Links
Live site (https://kawacukennedy.github.io/afrpoweros/)
GitHub (https://github.com/kawacukennedy/afrpoweros)
Dataset (JSON) (https://github.com/kawacukennedy/afrpoweros/blob/main/data/afrpoweros.json)
Newsletter (https://kawacukennedy.github.io/afrpoweros/newsletter.html) If something in the dataset is wrong, open an issue or send a pull request. I'd rather be corrected in public than quietly wrong.

We Built an Open-Source SDK for Cross-Chain AI Agents — Here's What Broke

kennedy — Mon, 06 Jul 2026 20:09:10 +0000

It's 3 AM and your AI agent just bridged $500 to a chain you've never heard of.

The logs say "optimal route found." The balance says $0. The agent can't explain why.

This is the problem we spent 6 months solving.

We built Kuberna Labs — an MIT-licensed SDK that gives AI agents secure execution rails across any blockchain. The whole thing is open-source: github.com/kawacukennedy/kuberna-labs

Here's what we actually had to build.

What "agent execution" actually means

Most people think "AI agent" means a chatbot with tool access. That's not what we're building.

An agent that calls an API and an agent that settles a financial transaction are fundamentally different problems. The first is about formatting HTTP requests. The second is about moving value across chains, proving what happened, and resolving disputes when something goes wrong.

Agent execution, in our definition, means:

An agent forms an intent ("swap 1 ETH for USDC on Solana")
That intent is parsed into a structured, verifiable format
Executors compete to fulfill the intent at the best price
An escrow contract holds funds until conditions are met
A TEE attestation proves the agent's decision was made correctly

Every layer above had to be built from scratch. No off-the-shelf solutions existed for open-source agent settlement.

Why intent-based execution is safer than direct wallets

Giving an agent a private key is the obvious approach. And it's terrifying.

If an agent holds a key, that key is accessible wherever the agent runs. A compromised agent means a drained wallet. There's no intermediary, no dispute window, no recourse.

Our architecture inverts this: the agent never holds keys. It posts intents. Executors compete to fulfill those intents. An on-chain escrow contract settles the transaction only when conditions are met.

const sdk = new KubernaSDK({ apiKey: process.env.KUBERNA_API_KEY })

const intent = await sdk.intents.create({
  sourceChain: "ethereum",
  destChain: "solana",
  sourceToken: "ETH",
  destToken: "USDC",
  sourceAmount: "1.0",
})

The agent posts an intent. The SDK handles the rest. No keys, no custody, no single point of failure.

How we stop the intent parser from hallucinating chains

This was the hardest technical problem we solved.

We started with GPT-4 to parse natural language intents. The results were terrifying:

// Input: "bridge my ETH to Arbitrum"
// GPT-4 output:
{ sourceChain: "Ethereum", destChain: "Arbitrum", token: "ARB" }

It confused the destination chain with the ARB token. If an agent executed this parse, it would swap ETH for ARB instead of bridging. That's a $10,000 hallucination.

We built a 4-layer fallback system:

compromise.js — zero-dependency NLP that works fully offline. Handles 80% of intents.
12 regex patterns — matching "X for Y on Z" and variations. Deterministic, no failure mode.
GPT-4 fallback — only when confidence < 0.6 from layers 1 and 2. Activated in ~15% of cases.
RAG memory — learns from past parses. Common patterns are promoted to layer 2 over time.

Each layer assigns a confidence score. We stop at the first layer with score > 0.6.

The result: zero hallucinated chains in production. 175 tests covering every edge case.

What on-chain escrow looks like for AI agents

Trustless settlement requires an escrow contract that handles the agent-specific edge cases:

function assignExecutor(
  bytes32 intentId,
  address executor,
  bytes calldata params
) external nonReentrant onlyAgent(intentId) {
  Escrow storage e = escrows[intentId];
  require(e.status == EscrowStatus.PENDING, 'not pending');
  e.executor = executor;
  e.executorParams = params;
  e.status = EscrowStatus.ASSIGNED;
  emit ExecutorAssigned(intentId, executor, params);
}

The nonReentrant modifier on assignExecutor and raiseDispute prevents reentrancy attacks. Every intent has a dispute window. If the agent disagrees with execution, funds are held pending resolution.

Why TEE attestation matters for provable decisions

An agent's decision trace must be provable. Without attestation, the agent can claim "I don't know what happened" and you have no way to verify.

We run decision-making inside an SGX enclave. Every inference produces a cryptographic receipt:

{
  "intentId": "0xabc...",
  "decision": "executor_selected",
  "executorAddress": "0xdef...",
  "confidence": 0.87,
  "attestation": "sgx://enclave-123/receipt/0x789..."
}

This receipt is stored on-chain. Anyone can verify that the agent made the decision it claims to have made, inside a trusted execution environment, at a specific point in time.

The circuit breaker problem

An agent that can't stop calling a dead API is an agent that burns money.

We implemented a sliding-window circuit breaker around all OpenAI calls:

CLOSED — normal operation
3 failures in 5 minutes → OPEN
30 second probe interval → HALF_OPEN
Probe succeeds → CLOSED
Probe fails → back to OPEN

const circuit = new CircuitBreaker(intentParser, {
  threshold: 3,
  windowMs: 300_000,
  probeIntervalMs: 30_000,
});

const result = await circuit.call('swap 1 ETH for USDC on Solana');

When the circuit is open, the agent falls back to the local compromise.js parser. No API call needed. The agent still works — it just makes simpler decisions.

Graceful degradation > perfect uptime.

What broke (the honest part)

Not everything went smoothly. Here's what we got wrong:

Math.sin() as a price oracle. Our first "market data provider" used Math.sin() to generate fake price data. It was a placeholder that somehow made it to staging. A real API integration would have caught this earlier.

Direct wallet integration. Our first design gave agents access to a wallet. We reversed this after a close call in testing. The intent-based architecture is harder to build but fundamentally safer.

No circuit breaker. We deployed the first version without rate limiting on API calls. The agent called a dead OpenAI endpoint 47 times before we noticed. Each call cost money. Each call returned nothing.

Intent parser hallucinating chains. The GPT-4 hallucination problem above cost us a week of refactoring. The 4-layer system was born from failure.

Where we're going next

zkTLS integration — proving agent decisions without revealing sensitive data
Solana support — the first non-EVM chain in the execution layer
NEAR Intents — cross-chain settlement using NEAR's intent infrastructure

The whole thing is MIT. 175 tests, all green. If you've fought with cross-chain settlement and won (or lost), I'd love to hear about it in the comments. PRs very welcome.

Next in this series: Why We Don't Let GPT-4 Parse Financial Intents (And What We Use Instead)

I Built a SaaS That Got 0 Users. Here's What I Learned About Actually Finding Problems Worth Solving.

kennedy — Thu, 25 Jun 2026 15:56:45 +0000

Last year I spent six months building a SaaS product. I did everything "right", polished UI, solid architecture, clean code. Launched to 12 signups. Zero paying users. Shut it down.

The postmortem was brutal but clear: I built something nobody needed. I fell in love with the solution before verifying the problem existed.

I'm sharing this because I know I'm not the only developer who's done this. And I want to do something different this time.

I've decided to start with zero code and instead spend time talking to people about what's actually broken in their work. I'm treating customer discovery like a engineering problem: gather data, find patterns, then build.

I'm looking for input from this community:

What task do you do manually every week that you keep thinking "there should be an API for this"?
What existing tool frustrates you so much that you've considered building your own replacement?
If you could wave a magic wand and automate one part of your development workflow, what would it be?

I'm not promoting anything. There's no landing page, no newsletter, no beta list. I'm genuinely trying to find a problem worth solving. If patterns emerge and I build something, I'll document the entire process here.

What problems are you all facing?

Why We Don't Let GPT-4 Parse Financial Intents (And What We Use Instead)

kennedy — Wed, 24 Jun 2026 14:47:02 +0000

I asked GPT-4 to parse "bridge my ETH to Arbitrum" and it returned:

{ "sourceChain": "Ethereum", "destChain": "Arbitrum", "token": "ARB" }

It confused the destination chain with the ARB token. If an agent executed this, it would swap ETH for ARB instead of bridging. That's a $10,000 hallucination.

This isn't a prompt engineering problem. It's a fundamental issue with using probabilistic models for deterministic financial parsing. Here's the system we built to eliminate it entirely.

kawacukennedy / kuberna-labs

Kuberna Labs - The Full-Stack Platform for Agentic Web3. Build, deploy, and monetize autonomous AI agents across decentralized networks with TEEs, zkTLS, and cross-chain intents.

Kuberna Labs

Agent Orchestration Platform — Deploy, run, and certify autonomous AI agents that execute cross-chain Web3 tasks.

⭐️ If you find this project useful, please star it on GitHub! ⭐️

It helps others discover the project and motivates contributors.

📋 Table of Contents

Overview

Kuberna Labs gives AI agents secure execution rails across any blockchain: agents parse natural language intents, make autonomous trading decisions, settle via on-chain escrow, and get post-quantum certified for verifiable reputation.

Target users: Web3 developers and teams who want to deploy autonomous AI agents that can trade, monitor, and execute on any chain without managing LLM infrastructure, blockchain RPCs, or certification pipelines.

✨ What Makes Kuberna Different?

Feature	Kuberna	Others
Natural Language → On-Chain Action	Parse "swap 1 ETH for USDC on Solana" → escrow → execution → certificate	Require

…

View on GitHub

The problem with LLMs for structured extraction

LLMs are probabilistic by design. They don't know anything — they predict the most likely token sequence given their training data. For financial intents, this means:

Chain names overlap with token symbols — "Arbitrum" vs "ARB", "Solana" vs "SOL"
Amounts can be ambiguous — "1 ETH" is clear, "send some" is not
Missing chain names — "swap 1 ETH for USDC" doesn't specify the destination chain
Novel phrasing — "bridge my bags over to polygon" needs to resolve to Polygon (MATIC)

Each of these is a recoverable error for a deterministic parser. Each is a potential loss-of-funds event for a probabilistic one.

The cost of hallucination in financial execution is not a bad chatbot response. It's real money moving to the wrong chain.

Our 4-layer approach

We never call GPT-4 first. The LLM is the last resort, not the primary parser.

Layer 1: compromise.js   (zero-dep NLP, offline)    ← 80% of intents
Layer 2: 12 regex patterns (deterministic matching)  ← 5% of intents
Layer 3: GPT-4 fallback   (only when conf < 0.6)     ← 15% of intents
Layer 4: RAG memory        (learns from past parses)  ← ongoing

Layer 1: compromise.js

compromise.js is a zero-dependency NLP library that runs in the browser, Node.js, and Deno. It handles:

Subject-verb-object extraction ("swap ETH for USDC")
Named entity recognition ("Ethereum", "Solana", "Arbitrum")
Number and unit parsing ("1.5 ETH", "500 USDC")

It weighs ~200KB and requires no API key. For well-formed intents, it's sufficient 80% of the time.

import nlp from 'compromise';

function parseWithCompromise(input: string): Intent | null {
  const doc = nlp(input);
  const tokens = doc.match('#Noun+');
  const amounts = doc.numbers().get();
  // ... extract structured intent
}

Layer 2: Regex patterns

For the 5% of intents where compromise.js yields low confidence, we fall through to 12 regex patterns covering common structures:

const PATTERNS = [
  // "swap X for Y on Z"
  /swap\s+(?<amount>\d+\.?\d*)\s+(?<source>\w+)\s+for\s+(?<dest>\w+)\s+on\s+(?<chain>\w+)/i,
  // "bridge X to Y"
  /bridge\s+(?<amount>\d+\.?\d*)\s+(?<token>\w+)\s+to\s+(?<chain>\w+)/i,
  // "send X to Y on Z"
  /send\s+(?<amount>\d+\.?\d*)\s+(?<token>\w+)\s+to\s+(?<chain>\w+)/i,
  // ... 9 more patterns
];

Each pattern maps matched groups to a validated Intent structure. If the mapping contains an unrecognized chain or token, the parse fails safely — no hallucination possible.

Layer 3: GPT-4 fallback

Only when both layers 1 and 2 return confidence < 0.6 do we call GPT-4. The prompt is structured to minimize hallucination:

const prompt = `
Parse the following cross-chain intent into JSON.
Only use chain names from this list: ${VALID_CHAINS.join(', ')}
Only use token symbols from this list: ${VALID_TOKENS.join(', ')}
If any value cannot be determined, set it to null. Do not infer.

Input: "${input}"
Output:`;

The LLM is constrained to a known vocabulary. If it returns a chain name not in VALID_CHAINS, the system rejects the parse. This caught the "Arbitrum" → "ARB" hallucination described above.

Layer 4: RAG memory

Every successful parse (regardless of which layer handled it) is stored in a vector database. Common patterns are promoted to new regex patterns over time.

After 6 months of operation, layer 4 has:

Generated 4 new patterns now handled by layer 2
Increased layer 1 hit rate from 72% to 80%
Reduced LLM fallback from 22% to 15%

Confidence scoring

Each layer assigns a confidence score. We stop at the first layer with score > 0.6.

const { intent, confidence } = await parseIntent('swap 1 ETH for USDC on Solana');

console.log(intent);
// {
//   sourceChain: "solana",
//   sourceToken: "ETH",
//   destToken: "USDC",
//   sourceAmount: "1",
//   confidence: 0.85
// }

Confidence is based on:

How many fields were successfully extracted (4/4 is better than 3/4)
Whether all chain/token names are in the known vocabulary
Pattern match strength (regex exact match > compromise fuzzy match > LLM generation)

If confidence is below 0.6 after all 4 layers, the intent is rejected and the agent is asked to rephrase.

How we tested this

175 tests covering:

Well-formed intents ("swap 1 ETH for USDC on Solana")
Missing chain names ("swap 1 ETH for USDC")
Novel phrasing ("move my bags to polygon")
Deliberately adversarial inputs ("ETH for BTC on Ethereum ethereum ethereum")
Chain/token confusion ("bridge to ARB on Arbitrum")
Mixed case, typos, extra whitespace

Property-based tests using fast-check verify invariants: the parser never returns a chain name not in VALID_CHAINS, never returns a token symbol not in VALID_TOKENS, and never fabricates an amount.

Zero hallucinated chains in production.

When you SHOULD use an LLM

The 4-layer system isn't anti-LLM. It's pro-determinism.

Use an LLM when the input is genuinely novel, the phrasing is ambiguous, or the intent contains information your deterministic layers can't handle. But don't use an LLM as your primary parser for financial inputs.

The LLM is a safety net, not the primary system. Build deterministic layers first. Let the LLM handle edge cases. And always validate the output against a known vocabulary before accepting it.

The parser is MIT licensed and works without any API key: backend/src/services/intentParser.ts

If you've hit similar hallucination problems with LLM-based extraction, I'd love to hear how you solved it in the comments.

Previously in this series: We Built an Open-Source SDK for Cross-Chain AI Agents — Here's What Broke
Next in this series: How We Built a Circuit Breaker for AI Agents That Touch Real Money

We Built an Open-Source SDK for Cross-Chain AI Agents, Here's What Broke

kennedy — Wed, 24 Jun 2026 14:28:31 +0000

It's 3 AM and your AI agent just bridged $500 to a chain you've never heard of.

The logs say "optimal route found." The balance says $0. The agent can't explain why.

This is the problem we spent 6 months solving.

We built Kuberna Labs, an MIT-licensed SDK that gives AI agents secure execution rails across any blockchain. The whole thing is open-source: github.com/kawacukennedy/kuberna-labs

Here's what we actually had to build.

kawacukennedy / kuberna-labs

Kuberna Labs - The Full-Stack Platform for Agentic Web3. Build, deploy, and monetize autonomous AI agents across decentralized networks with TEEs, zkTLS, and cross-chain intents.

Kuberna Labs

Agent Orchestration Platform — Deploy, run, and certify autonomous AI agents that execute cross-chain Web3 tasks.

⭐️ If you find this project useful, please star it on GitHub! ⭐️

It helps others discover the project and motivates contributors.

📋 Table of Contents

Overview

✨ What Makes Kuberna Different?

Feature	Kuberna	Others
Natural Language → On-Chain Action	Parse "swap 1 ETH for USDC on Solana" → escrow → execution → certificate	Require

…

View on GitHub

What "agent execution" actually means

Most people think "AI agent" means a chatbot with tool access. That's not what we're building.

Agent execution, in our definition, means:

An agent forms an intent ("swap 1 ETH for USDC on Solana")
That intent is parsed into a structured, verifiable format
Executors compete to fulfill the intent at the best price
An escrow contract holds funds until conditions are met
A TEE attestation proves the agent's decision was made correctly

Every layer above had to be built from scratch. No off-the-shelf solutions existed for open-source agent settlement.

Why intent-based execution is safer than direct wallets

Giving an agent a private key is the obvious approach. And it's terrifying.

If an agent holds a key, that key is accessible wherever the agent runs. A compromised agent means a drained wallet. There's no intermediary, no dispute window, no recourse.

const sdk = new KubernaSDK({ apiKey: process.env.KUBERNA_API_KEY })

const intent = await sdk.intents.create({
  sourceChain: "ethereum",
  destChain: "solana",
  sourceToken: "ETH",
  destToken: "USDC",
  sourceAmount: "1.0",
})

The agent posts an intent. The SDK handles the rest. No keys, no custody, no single point of failure.

How we stop the intent parser from hallucinating chains

This was the hardest technical problem we solved.

We started with GPT-4 to parse natural language intents. The results were terrifying:

// Input: "bridge my ETH to Arbitrum"
// GPT-4 output:
{ sourceChain: "Ethereum", destChain: "Arbitrum", token: "ARB" }

It confused the destination chain with the ARB token. If an agent executed this parse, it would swap ETH for ARB instead of bridging. That's a $10,000 hallucination.

We built a 4-layer fallback system:

compromise.js — zero-dependency NLP that works fully offline. Handles 80% of intents.
12 regex patterns — matching "X for Y on Z" and variations. Deterministic, no failure mode.
GPT-4 fallback — only when confidence < 0.6 from layers 1 and 2. Activated in ~15% of cases.
RAG memory — learns from past parses. Common patterns are promoted to layer 2 over time.

Each layer assigns a confidence score. We stop at the first layer with score > 0.6.

The result: zero hallucinated chains in production. 175 tests covering every edge case.

What on-chain escrow looks like for AI agents

Trustless settlement requires an escrow contract that handles the agent-specific edge cases:

function assignExecutor(
  bytes32 intentId,
  address executor,
  bytes calldata params
) external nonReentrant onlyAgent(intentId) {
  Escrow storage e = escrows[intentId];
  require(e.status == EscrowStatus.PENDING, 'not pending');
  e.executor = executor;
  e.executorParams = params;
  e.status = EscrowStatus.ASSIGNED;
  emit ExecutorAssigned(intentId, executor, params);
}

Why TEE attestation matters for provable decisions

An agent's decision trace must be provable. Without attestation, the agent can claim "I don't know what happened" and you have no way to verify.

We run decision-making inside an SGX enclave. Every inference produces a cryptographic receipt:

{
  "intentId": "0xabc...",
  "decision": "executor_selected",
  "executorAddress": "0xdef...",
  "confidence": 0.87,
  "attestation": "sgx://enclave-123/receipt/0x789..."
}

This receipt is stored on-chain. Anyone can verify that the agent made the decision it claims to have made, inside a trusted execution environment, at a specific point in time.

The circuit breaker problem

An agent that can't stop calling a dead API is an agent that burns money.

We implemented a sliding-window circuit breaker around all OpenAI calls:

CLOSED — normal operation
3 failures in 5 minutes → OPEN
30 second probe interval → HALF_OPEN
Probe succeeds → CLOSED
Probe fails → back to OPEN

const circuit = new CircuitBreaker(intentParser, {
  threshold: 3,
  windowMs: 300_000,
  probeIntervalMs: 30_000,
});

const result = await circuit.call('swap 1 ETH for USDC on Solana');

When the circuit is open, the agent falls back to the local compromise.js parser. No API call needed. The agent still works — it just makes simpler decisions.

Graceful degradation > perfect uptime.

What broke (the honest part)

Not everything went smoothly. Here's what we got wrong:

Intent parser hallucinating chains. The GPT-4 hallucination problem above cost us a week of refactoring. The 4-layer system was born from failure.

Where we're going next

zkTLS integration — proving agent decisions without revealing sensitive data
Solana support — the first non-EVM chain in the execution layer
NEAR Intents — cross-chain settlement using NEAR's intent infrastructure

The whole thing is MIT. 175 tests, all green. If you've fought with cross-chain settlement and won (or lost), I'd love to hear about it in the comments. PRs very welcome.

Next in this series: Why We Don't Let GPT-4 Parse Financial Intents (And What We Use Instead)

Building Autonomous Cross-Chain AI Agents with Kuberna Labs

kennedy — Sun, 15 Mar 2026 20:13:27 +0000

If you've ever tried to build an AI agent that can actually do something on-chain—like swap tokens, monitor a protocol, or execute a trade across chains—you know the pain. You need to manage private keys, estimate gas, handle failed transactions, and orchestrate complex cross-chain flows. It's brittle, time-consuming, and error-prone.

That's why we built Kuberna Labs: an open-source SDK and infrastructure that abstracts away the complexity of cross-chain execution for AI agents.

The Stack

Our architecture is designed to take a high-level intent (e.g., "Swap 1 ETH to USDC on Solana") and execute it securely, with cryptographic guarantees. Here's how it works:

LLM / NLP Engine – Parses natural language into structured tasks.
Kuberna SDK – Provides a unified API for agent creation, intent submission, and execution.
Execution Layer:
- TEEs (Phala, Marlin) – Run agent logic in trusted enclaves with remote attestation.
- zkTLS (Reclaim, zkPass) – Fetch verified Web2 data without exposing credentials.
- Intent Router (ERC-7683) – Broadcasts intents to a decentralized solver network.
Solver Network – Agents compete to fulfill intents, with funds secured in escrow contracts.

Why This Matters

Most AI agents today are just chatbots—they can't actually transact value. Kuberna turns them into autonomous economic actors. Imagine an agent that:

Monitors a DeFi protocol's TVL and alerts you on Discord.
Executes arbitrage across DEXes when profitable.
Proves your bank balance on-chain without revealing the number (via zkTLS).

Get Started in 2 Minutes

npm install @kuberna/sdk

import { KubernaSDK } from '@kuberna/sdk';

const sdk = new KubernaSDK({ apiKey: 'YOUR_API_KEY' });
const agent = await sdk.createAgent({
  name: 'YieldOptimizer',
  framework: 'ElizaOS',
});
console.log(`Agent ${agent.id} is live!`);

The SDK handles all the hard stuff—wallet management, gas estimation, intent routing—so you can focus on your agent's logic.

Open Source & Community

Kuberna Labs is 100% open-source and built in public. We're based in Kigali, Rwanda, and we're on a mission to become the operating system for the agentic economy.

👉 GitHub Repo

👉 Discord

We'd love your contributions, ideas, and stars. Let's build the future of autonomous agents together.

Sunder: The Open‑Source AI Coding Assistant That Translates, Explains, and Pairs With You

kennedy — Thu, 12 Feb 2026 09:00:17 +0000

The Problem

Every developer knows the drill:

You find a brilliant Python snippet, but your project is in JavaScript.
You want a second pair of eyes, but scheduling a code review takes days.
Copilot helps, but it’s proprietary, doesn’t explain why, and can’t translate.

Sunder fixes all of that; and it’s now open source.

What Is Sunder?

Sunder is an AI‑powered collaborative platform for code snippets. Think GitHub Gists meets Figma meets Gemini.

With Sunder you can:

Save & discover snippets across 50+ languages
Translate code between languages with functional equivalence
Pair program with an AI that learns your style
Real‑time collaborate on snippets with cursors, chat, and video
Get explanations and refactoring suggestions on demand

All inside a beautiful Next.js + Tailwind UI.

Why Open Source?

We believe developer tools should be transparent, community‑owned, and accessible to everyone.

By open‑sourcing Sunder we’re saying:

You shouldn’t need a corporate budget to have an AI pair programmer.

We also want to build the best AI‑first coding platform – and that can only happen with contributions from developers like you.

Try It in 60 Seconds

git clone https://github.com/kawacukennedy/sunder
cd sunder
./scripts/setup.sh

That’s it. Docker Compose spins up PostgreSQL, Redis, and a mock AI server – you don’t even need a Gemini API key.

Then open http://localhost:3000 and start exploring.

🧩 What Needs Help?

We’ve curated 20+ “good first issues” with detailed instructions and mentors.

Area	Example Issue
🎨 Frontend (React)	Add syntax highlighting for Rust
⚙️ Backend (Node)	Optimize snippet search with trigram indexes
🧠 AI (Gemini)	Improve translation accuracy for Go → TypeScript
📚 Docs	Write a tutorial for real‑time collaboration

👉 Browse good first issues →

💬 Join Our Community

We’re on Discord; ask questions, share what you build, and meet other contributors.

One Last Thing

If you believe AI tools should be open and collaborative:

Star the repo – it helps others find us
Share this post with a friend who loves AI
Pick an issue and make your first contribution today

Let’s build the future of coding – together.

Sunder on GitHub: github.com/kawacukennedy/sunder

Contact: Email
Twitter: @Arnaud_Kennedy

I’m Building a High-Signal Discord for Developers Who Actually Want to Build (Not Another Dead Server)

kennedy — Thu, 08 Jan 2026 18:44:17 +0000

Most developer Discord servers fail for the same reasons:

Too many channels
No structure
No onboarding
Everyone talks, nobody builds

So I decided to build something different.

I just launched a Developer Discord Community designed around clarity, progression, and real collaboration.

What makes this server different

This is not a “drop a link and disappear” Discord.

We’ve designed it with:

Structured onboarding (Beginner, Intermediate, Advanced)
Clean channel UX (you only see what’s relevant to you)
Focused help channels (no noise, no spam)
Project collaboration (ideas → teams → execution)
A new Web3 channel for serious discussions around blockchain, smart contracts, and decentralized apps

Who this is for

Developers who want to learn properly
Developers who want to build real projects
Developers who want feedback, not fluff
Developers who want a community that respects their time

Stacks include:
Frontend, Backend, Mobile, AI/ML, DevOps — and now Web3.

What you’ll actually do inside

Ask and answer real technical questions
Get code reviews
Collaborate on projects
Share resources that matter
Learn from developers at different levels

Join here

👉 Discord Server

If you’re tired of low-signal communities and want a place that feels intentional and well-run, you’re welcome.

Let’s build something meaningful.

I Built 12 Projects In 12 Days… and Almost Lost My Mind 😭💻

kennedy — Tue, 02 Dec 2025 11:51:56 +0000

If you’ve ever said “I’ll start coding seriously tomorrow”,
and then tomorrow becomes next week… and next week becomes
“after this YouTube video”…

Yeah. Same.

I wasn’t a “perfect” coder — I wasn’t even a consistent coder.

I was more like:

Start a project → Get excited → Get stuck → Open TikTok → Never return.

But deep inside, something had to change.

So I did something… questionable, bold, and slightly unhinged:
I challenged myself to build 12 projects in 12 days.

Did I suffer? Yes.
Did I improve? More than I expected.
Would I do it again?

…Let’s not talk about that yet.

😤 Days 1–3: “I Am Him” Energy

I started small — a little too small.

A weather app
A mini Pac-Man style game
A simple note app

I felt unstoppable. I was coding like I had a personal sponsorship from Red Bull.

😵 Days 4–6: Bug-Induced Hallucinations

This is where things… shifted.

You know those bugs that exist purely to test your patience?

Like when a button doesn’t work because you spelled onclick as onlcik
for 2 hours straight.

At one point, I opened my console and it opened back at me.

😭 Days 7–9: The Existential Dread Arc

Halfway through, I questioned EVERYTHING:

My skills
My sanity
My life decisions
Whether computers were even meant for humans

But each time I considered giving up, a tiny voice whispered:

“Bro, you already tweeted about this challenge. You can’t embarrass yourself now.”

So I kept going.

🤯 Days 10–12: Final Boss Mode

Something weird happened:
I started coding… calmly?

My debugging got faster.
My problem-solving improved.
I didn’t cry (as much).

By Day 12, I pushed the last project, closed VS Code, and just sat there.

I felt peace.
Or maybe burnout. Hard to tell.

💡 What I Learned (that school doesn’t teach you)

✔ Consistency > Motivation

Motivation comes and goes.
Consistency stays — especially when your pride is on the line.

✔ Projects teach faster than tutorials

You can’t “tutorial” your way into mastery.
You need to build stuff. Break stuff. Fix stuff. Cry a bit.

✔ Your future self will thank you

Even if your current self is suffering and eating cold noodles at 2 AM.

🔥 Final Thoughts

This challenge didn’t turn me into a genius overnight.

But it changed my mindset.

If you're a beginner reading this, let me tell you:
You can become a great developer — just don’t quit when it gets hard.

Start small. Build consistently.
And maybe don’t do 12 projects in 12 days unless you're mentally prepared.

(You’re probably not. I wasn’t.)

❤️ If You Enjoyed This

Leave a comment!
Share the article!
Tell me if you want the “12 Projects in 12 Days” full breakdown + code.

I might drop it.
After I recover.