DEV Community: Khe Ai

Founding Lead Playbook: Running Product, Architect & Engineering with AI Agents + 2 Humans

Khe Ai — Thu, 16 Jul 2026 14:33:50 +0000

There are a lot of shallow "10x with AI" threads out there. This isn't one of them. This is the actual operating model I use to run product, architecture, and backend engineering as a single person, with one human collaborator (a frontend developer) and an AI coding agent doing the heavy lifting on everything else.

The premise: a stakeholder hands me a one-sentence goal. From there, I own product definition, system design, and technical execution end to end. I have exactly one other human in the loop. Everything else — backend, migrations, tests, infra scripts — runs through an AI coding agent that I direct, review, and gate.

The honest answer to "does this scale" is: yes, but only if you restructure how you work, not just what tools you use. Bolting an AI agent onto a traditional PM → architect → engineer pipeline doesn't collapse the timeline — it just moves the bottleneck to your own attention. Here's the actual playbook, including the parts that broke before I fixed them.

The core shift: latency drops, judgment doesn't

In a multi-person team, a lot of calendar time goes to reconciling context between people — PRD reviews, architecture alignment, ticket grooming. Collapse those roles into one person and that coordination latency mostly disappears. What doesn't disappear, and what people underestimate, is the judgment load: you still have to make every product call, every architectural tradeoff, and every "is this actually correct" review — just faster and back-to-back.

You still own the architecture, the product vision, and the final quality gate. The agent owns boilerplate, migration scripts, test scaffolding, and the first draft of business logic. The frontend developer owns UI/UX and interaction — and should never be blocked waiting on you.

Part 1: The execution loop, phase by phase

The single biggest failure mode in this model is context-switching mid-thought — writing code while you're still deciding what the feature even is. Treat each phase as a distinct mode with a distinct output artifact, and don't move to the next phase until the current one has a concrete deliverable.

Phase 1 — Product definition: decouple "what" from "how".

When a vague goal lands (e.g. "we need a multi-tenant billing aggregator"), resist opening the editor. First pass is product framing:

"Analyze this objective. Strip vanity features. What are the 3 core user flows that define the MVP? What are the day-one edge cases we can't defer?"

Treat the agent's output as a first draft, not a spec — it will over-scope and hallucinate requirements that sound plausible but weren't asked for. Your job is subtractive: cut it down to a backlog of user stories you'd actually defend to a stakeholder.

Phase 2 — System design: harden the schema and the contract before any code exists.

The artifacts that matter here are the data schema and the API contract — not diagrams for their own sake. A concrete prompt:

"Design a PostgreSQL schema for these user stories. Every tenant-owned table needs an explicit tenant_id foreign key, not just an implicit assumption of isolation. Generate the migration. Then produce an OpenAPI 3.0 spec for the endpoints, and flag which mutating endpoints need idempotency keys."

One correction worth making explicit: Postgres Row-Level Security (CREATE POLICY) is a real and valid tenant-isolation mechanism, but it's not the only one, and for most application-layer multi-tenancy, filtering by an indexed tenant_id column at the service layer — never trusting the client for that value, always deriving it from an authenticated token — is simpler to reason about and test than RLS policies that live outside your application code and are easy to forget to enable on a new table. Pick one mechanism deliberately and apply it uniformly; the actual bug that bites teams isn't "which mechanism," it's the one table someone forgot to scope.

Once you approve the schema and contract, that OpenAPI document becomes the single source of truth for both the backend implementation and the frontend integration. Nobody should be inferring the contract from someone else's code.

Phase 3 — Execution: agentic implementation against a locked contract.

With the contract locked, point the agent at it directly:

"Implement the endpoints in billing-openapi.yaml. Write integration tests alongside the implementation, not after. Mock the third-party payment gateway. Every soft-deletable entity must be excluded from lookups by default — verify this with a test, not a comment."

Watch it iterate — writing routes, wiring the data layer, running its own tests until they pass. Your job shifts to review: does the generated code actually implement the invariant you asked for, or does it look right at a glance and fall apart under a concurrent-write or soft-delete edge case? This is the phase where unverified trust in agent output causes the most expensive bugs — see Trap 1 below.

Phase 4 — The frontend handshake: never let the human be the bottleneck.

While the agent works the backend, your frontend developer should never be idle waiting for a real server to exist. The fix is a fast fake:

Spin up a mock server (e.g. Prism) directly from the OpenAPI spec.
Generate TypeScript types from that same spec and hand them over — not written by hand, always derived from the contract so they can't silently drift from it.
Hand off a ticket with: UI requirements, the exact endpoint contracts, the generated types, and the mock server URL.

The frontend developer builds against a fake that behaves exactly like the real API's shape will, in parallel with backend implementation — not after it.

Phase 5 — Defense-in-depth review before merge.

When both the backend implementation and the frontend PR are ready, run a deliberately adversarial pass — not a rubber stamp:

"Audit the newly merged routes for SQL injection risk, unhandled promise rejections, N+1 query patterns, and any endpoint that filters a mutation by ID alone without also checking an ownership/tenant claim."

Then do a manual read of the frontend PR, boot the real stack (not just unit tests — actually exercise the flow), and run an integration smoke test end to end. Automated audits catch pattern-matchable classes of bug; they do not catch "this endpoint is logically correct but violates an invariant the codebase depends on elsewhere." That still needs a human who knows the codebase.

Part 2: The hidden traps

This looks smooth described linearly. In practice there are three specific failure modes that will bite you if you don't build explicit countermeasures for them.

Trap 1: Confident-looking code that's quietly wrong

An AI coding agent will produce large amounts of syntactically correct, plausible-looking code very quickly. It has no felt sense of how painful a given shortcut will be to live with in six months, and — more dangerously — it will happily generate code that looks like it respects an invariant (soft-delete, tenant scoping, transactional atomicity) without actually doing so, because the surface pattern is right even when the substance isn't.

Concrete example of the failure shape: a lookup helper that appears to respect soft-delete because it uses the same repository method as everywhere else, but a nearby "quick fix" swaps in a raw UPDATE/increment call that bypasses the ORM's default filtering entirely. Nothing fails at compile time. Nothing fails in a shallow unit test that mocks the repository. It fails in production, quietly, against a real row that should have been excluded.

Mitigations that actually work:

Small, single-responsibility files and modules. Force decomposition — a giant file is where a bypassed invariant hides longest.
Tests written alongside the implementation, not after. If the agent can't make its own code pass tests for the exact invariant you care about (soft-delete exclusion, tenant isolation, idempotency), that's a signal the design is under-specified, not that the tests are wrong.
A recurring "what did we bypass" audit. Periodically ask explicitly: "grep for direct UPDATE/increment/raw-query calls that skip the ORM's default scoping — list every one and justify each." This catches the class of bug that a generic code-quality pass misses, because the code isn't badly written — it's precisely wrong in a way that only matters if you know the invariant it's supposed to uphold.
Verify claims against the actual entity/schema, not the design doc's own description of it. A design document can be internally consistent and still wrong about what the current code does — the only ground truth is the file itself.

Trap 2: Context-switch fatigue

Jumping between product framing, system design, and low-level debugging every twenty minutes measurably degrades decision quality — you start making sloppy tradeoffs by mid-afternoon because your brain is still half in the previous mode. The fix isn't willpower, it's scheduling:

Time block	Mode	Focus
Deep-focus block	Product & architecture	Requirements, schema, contracts. No implementation.
Execution block	Technical lead	Directing the agent, reviewing generated code, fixing integration issues.
Admin block	Backlog & coordination	Grooming, status updates, unblocking the frontend developer.

Protect the boundaries. Don't let a "quick architecture question" bleed into an execution block, and don't context-switch back to design mid-implementation just because something looks solvable in five minutes — write it down and come back to it in the next design block.

Trap 3: The velocity gap between AI-assisted backend and human frontend work

An AI-assisted backend can move several times faster than a human doing frontend implementation and design iteration. If you push that raw velocity downstream unfiltered, your frontend collaborator ends up perpetually behind, context-switching on every drip-fed change, and reasonably start to feel steamrolled.

Mitigations:

Batch, don't drip. Bundle backend changes into coherent feature-sized handoffs on a predictable cadence, rather than pushing every incremental change as it lands.
Write the handoff note yourself. Auto-generated API docs describe the shape of an interface, not how the pieces are meant to fit together or which states are the tricky ones. A few minutes of plain-language context from the person who actually made the design tradeoffs saves hours of the other person reverse-engineering intent from a diff.

Part 3: Reusable prompt scaffolding

These are the actual system-prompt shapes I keep reusing, generalized so they're useful regardless of stack.

Architecture-mode system prompt:

You are acting as a principal-level solution architect for cloud-native systems.
Optimize for security, cost, and long-term maintainability over cleverness.

Rules:
1. Prefer a relational database with explicit foreign keys and indexes over
   schemaless flexibility, unless there's a specific reason not to.
2. Every tenant-owned or user-owned resource needs an explicit, indexed
   ownership column, checked at the service layer — never trust client input
   for it, always derive it from an authenticated context.
3. Favor a modular monolith over microservices until there's a concrete,
   measured scaling reason to split — don't design for hypothetical scale.
4. APIs should be stateless; sessions/identity travel in signed tokens, not
   server-side session state.
5. Mutating endpoints that could plausibly be retried (payments, anything
   with side effects) need idempotency keys.

Output structured markdown — schema tables, OpenAPI fragments. No filler prose.

Pre-merge review prompt:

Review this diff as a pedantic, security-focused reviewer. Check specifically for:
- Injection risk or any raw query that bypasses the ORM's default scoping
  (soft-delete filters, tenant/owner filters).
- Missing error handling, unhandled promise rejections.
- N+1 query patterns in data fetches.
- Any delete/update filtered by ID alone, without an ownership or tenant check.
- Hardcoded secrets or config values.
- Any comparison of a secret value (API key, token, signature) using a
  non-constant-time equality check.

For each finding: exact location, severity, and a corrected code block.

The actual reality check

This way of working is genuinely faster — you're not waiting on a meeting to change a column, or a QA cycle to verify a basic endpoint. But the speed is entirely conditional on one thing: your review discipline scaling with your output. An AI coding agent will write code as fast as you can specify it. It will not tell you when the specification itself is wrong, and it will not notice when its own output looks correct but violates an invariant it was never told mattered.

Your value in this model isn't typing speed — it never really was. It's how precisely you can define the problem, how much of the actual invariant-space of the system you can hold in your head during review, and how well you can keep a human collaborator unblocked while the machine does the parts that don't need taste.

Wear one hat at a time. Trust but verify, every time, especially when the code looks fine.

Connecting RooCode to Gemma4-26B-MoE via OpenAI Bridge

Khe Ai — Tue, 02 Jun 2026 17:33:01 +0000

This configuration bypasses extension UI limitations by routing direct Google AI Studio requests through Google’s native OpenAI-compliant endpoint. This allows you to use newly released or unlisted models like gemma-4-26b-a4b-it completely free of charge, without needing a third-party proxy account like OpenRouter.

1. Prerequisites

VS Code with the RooCode extension installed.
A Google AI Studio API Key (Get one for free at aistudio.google.com).

2. RooCode Profile Configuration

Open your RooCode settings menu (the gear icon at the top right of the extension pane) and fill out the fields exactly as follows:

Setting	Value to Enter	Notes
API Provider	`OpenAI Compatible`	Standardizes data transport to match Google's bridge.
Base URL	`https://generativelanguage.googleapis.com/v1beta/openai/`	Must include the trailing slash (`/`).
API Key	Your Google AI Studio API Key	Starts with `AIzaSy...`
Model	`gemma-4-26b-a4b-it`	The exact technical identifier for the model.
Model Reasoning Effort	`None` / `Default`	Not natively supported by Gemma models; leave it blank or default.

3. Why This Works (Troubleshooting Context)

The Bridge Endpoint: Google provides the /v1beta/openai/ URL block specifically so developers can drop Gemini models seamlessly into software written for OpenAI backends.
Bypassing Dropdowns: Choosing "OpenAI Compatible" instructs RooCode to treat the Model box as a free-form text input rather than a strict, predefined dropdown menu, preventing the extension from stripping out unlisted models.
Native Tool Calling: RooCode requires full tool-calling support to write code and read files in your editor. Because gemma-4-26b-a4b-it supports native function calling out of the box via this bridge, RooCode's autonomous agent actions function normally.

Pro-Tip: If Google updates this model line in the future (e.g., to a newer point release), you only need to swap out the text string in the Model field without changing any other parameters.

Why Build a Startup If Not for Money?

Khe Ai — Tue, 02 Jun 2026 14:19:35 +0000

The Unspoken Playbook of the Sovereign Creator

For decades, the dominant narrative around startups has been hyper-fixated on one metric: the exit. We are conditioned to view entrepreneurship through the lens of venture capital, hockey-stick growth charts, and generational wealth.

But what happens when you remove financial gain from the primary equation? If you aren't doing it to buy a yacht or retire early, why on earth would you willingly subject yourself to the volatility, sleepless nights, and staggering failure rates of building something from scratch?

When you strip away the financial incentive, you don't find passivity. Instead, you uncover the purest, most resilient forms of human drive. Here is what I have learned about what actually happens when you build a startup for everything except the money—and why it might just be the ultimate way to live.

1. The Reality Check: The Luxury of "Not Caring" About Capital

Let’s be brutally honest and set a skeptical anchor right out of the gate: building a startup without prioritizing money is an act of immense privilege.

If you are struggling to pay rent or feed your family, the profit motive isn't just healthy; it is mandatory. But once you achieve baseline financial security—or if you choose to live a radically low-overhead lifestyle ("ramen profitable")—something fascinating happens to your decision-making matrix.

When you optimize for revenue above all else, you are forced to make concessions. You build features you hate because a enterprise client demanded them. You chase trends because that’s where the VC funding is flowing.

When money is no longer your master, compromise drops to zero. You gain the rarest asset in modern business: absolute alignment between your values and your output.

2. The Scratch You Cannot Stop Clawing (Obsessive Problem-Solving)

Most people encounter a broken system, a terrible piece of software, or an inefficient workflow and think, "Wow, that sucks," before moving on with their day.

But a specific subset of people suffer from what I call a "splinter in the mind." A broken reality agitates them. When you aren't building for money, you turn into a pure problem-solver. You aren't scanning the market for "lucrative gaps"; you are dead-set on fixing a specific piece of the universe that is currently broken.

The Shift in Focus

The Venture-Backed Mindset: "Is the Total Addressable Market (TAM) big enough to justify an IPO?"
The Sovereign Mindset: "Does this solution need to exist in the world? Will it fundamentally improve the day-to-day existence of the people who use it?"

This obsession creates a massive competitive advantage. When a profit-driven founder hits a wall where the financial ROI turns negative, they pivot or quit. When you hit that same wall, you keep digging because your return on investment isn't measured in dollars—it’s measured in the eradication of the problem.

3. The Hacker-Artist Paradigm: Pure Creation as an Antidote to Existential Dread

There is a distinct joy in writing a clean line of code, designing an intuitive user interface, or crafting a seamless user experience. It is the joy of the artisan.

Somewhere along the line, the tech world forgot that software engineering and company building are deeply creative acts. They are modern forms of art.

[The Industrial Loop] → Produce for Consumption → Optimize for Scale → Erase the Artisan
[The Sovereign Loop] → Build for the Sake of It → Optimize for Beauty → Preserves the Soul

When you build without the sole goal of monetization, you treat your startup like a canvas. You build things simply because they are beautiful, elegant, or intellectually stimulating. This is the ethos that built the early open-source movement and the early internet. It’s the desire to say, "I was here, and I shaped this small corner of reality according to my own aesthetic."

4. The Autonomy Premium: Buying Back Your Sovereignty

Corporate life is an exercise in managed compromise. You trade your time and your creative control for predictable compensation.

For many of us, the true alternative to a startup isn't wealth—it’s sovereignty. Building a project outside the traditional corporate matrix allows you to establish a micro-ecosystem that answers to no one but you and your users.

No arbitrary KPIs: You don't have to hit fake metrics to please a board of directors.
No political theater: You don't waste 40% of your energy managing upwards or dealing with bureaucratic red tape.
Radical collaboration: You choose exactly who you work with, ensuring that every teammate or user shares your specific wavelength.

You aren't trying to build an empire; you are trying to build a fortress that protects your personal freedom and intellectual peace.

5. Turning Life into a High-Fidelity Simulator

Let’s face a hard truth: comfort breeds stagnation. If you don't need money, the easiest thing to do is sit back, consume content, and let your brain atrophy in a state of passive leisure.

But passive leisure is a psychological trap that frequently leads to existential dread. Human beings are evolutionary engines designed to overcome friction.

A startup is the ultimate high-fidelity simulator for personal growth. It tests every single dimension of your capability:

Intellectual: You must master copywriting, system architecture, psychology, and legal frameworks simultaneously.
Emotional: You have to deal with public criticism, bugs that break your system at 2:00 AM, and the vulnerability of putting your work out into the world.
Philosophical: It forces you to constantly answer the question: What is actually worth my limited time on this planet?

By treating entrepreneurship as an elite sport rather than a financial transaction, the startup becomes a forcing function to turn you into the sharpest, most resilient version of yourself.

Summary: The Post-Financial Playbook

If someone asks you why you are pouring your life blood into a project that might never make you rich, show them this framework.

Dimension	The Conventional Startup	The Sovereign Project
Primary Metric	Valuation & MRR (Monthly Recurring Revenue)	Autonomy & Utility
Scale Strategy	Hyper-growth, often unsustainable	Sustainable, often "One-Man" or micro-team
Success State	An acquisition or IPO	An evergreen tool that runs flawlessly
Relationship to Users	Monetizable data or traffic units	A community of like-minded peers

Building without chasing money isn't aimless hobbyism. It is a highly disciplined, deeply intentional way to reclaim your time, express your creativity, and solve real-world problems on your own terms.

Stop asking if it scales. Stop asking how it monetizes. Just build things that should exist.

Building a Decentralized Content Pipeline with Nostr & Astro

Khe Ai — Tue, 02 Jun 2026 07:36:04 +0000

I recently deployed my fully decentralized content pipeline to kheai.com (you can check out the source code at github.com/kafechew/nostr-seo). After rigorously testing the architecture, I wanted to document exactly how this system works. We are not just building a blog; we are engineering an evergreen, censorship-resistant Web3-to-Web2 bridge.

kafechew / nostr-seo

⚡ Nostr-SEO: The Decentralized Content Bridge

Nostr-SEO is a high-performance, SEO-first bridge that transforms decentralized Nostr Long-form content (Kind 30023) into a lightning-fast, search-engine-optimized website.

Built on top of the refined Astro-Paper template, this project allows creators to use Nostr as a decentralized CMS while maintaining total ownership of their web presence and search engine rankings.

📖 The Problem & Solution

The Problem

Decentralized protocols like Nostr are amazing for censorship resistance, but their content is often "invisible" to traditional search engines. If you publish only on relays, you lose the benefits of SEO (Search Engine Optimization) and AEO (Answer Engine Optimization) for AI agents like Perplexity and ChatGPT.

The Solution

nostr-seo acts as a Static Site Generator (SSG) for the Nostr protocol.

Fetch: It pulls your articles from decentralized relays at build-time.
Process: It cleans the Markdown, renders complex Math (LaTeX) and Diagrams (Mermaid).
Deploy: It…

View on GitHub

In this tutorial, you will build an automated pipeline that fetches your long-form articles from decentralized Nostr clients (like Yakihonne or Primal), converts them into a blazing-fast static website using Astro, and hosts it for free on Vercel.

Zero prior Astro experience is required. If you follow these steps, you will go from an empty folder to a live, SEO-optimized prototype.

The Architecture Vision

Before writing code, you must understand the data flow. We are shifting from a "push" model (saving files to a server) to a "pull" model (compiling decentralized data at build time).

graph TD
    A[Author on Yakihonne/Primal] -->|Publishes Kind 30023| B(Nostr Relays)
    C[GitHub Actions Cron] -->|Triggers Build every 6h| D(Vercel Edge Network)
    D -->|Fetches Data| B
    D -->|Compiles HTML/CSS| E[Your Live Website]
    E --> F[Human Readers]
    E --> G[AI Agents via llm.txt]

The Tech Stack

Component	Tool	Purpose
Network	Nostr Protocol	Decentralized content storage and syndication.
Framework	Astro (AstroPaper)	High-speed static site generation and routing.
Processor	Unified Ecosystem	Parsing Markdown, KaTeX (math), and Mermaid (diagrams).
Hosting	Vercel	Edge delivery and automated webhooks.

Phase 0: The Digital Workbench

You need a few standard tools installed before we begin.

Download and install the LTS (Long Term Support) version of Node.js from nodejs.org.
Install Git from git-scm.com.
Download Visual Studio Code, the industry-standard code editor.
Create free accounts on GitHub and Vercel.
Convert your Nostr npub to a Hexadecimal key using a tool like damus.io/key. Keep this Hex key safe; our code needs it to identify you on the network.

Phase 1: Local Setup & Installation

Open your terminal. We will use the AstroPaper template as our foundation.

Run the following command to download the template into a new folder named nostr-seo:

npm create astro@latest -- --template satnaing/astro-paper nostr-seo

Navigate into your new project:

cd nostr-seo

Now, we must install our communication tools (NDK for Nostr) and our processing engines (Unified for Markdown/Math). Run this command exactly as written:

npm install @nostr-dev-kit/ndk ws nostr-tools remark-math rehype-katex rehype-stringify remark-rehype remark-parse unified --legacy-peer-deps

Note: The --legacy-peer-deps flag prevents npm from crashing if the Astro template's default formatting tools have strict version conflicts with our new parser.

The MacOS/Linux WebAssembly Patch

If you are on an older OS, the build engine (esbuild) might fail. Open your package.json file and append these properties to force Node.js to bypass your core OS framework and use WebAssembly instead:

{
  "devDependencies": {
    "esbuild-wasm": "0.28.0"
  },
  "overrides": {
    "esbuild": "npm:esbuild-wasm@0.28.0"
  }
}

Open the project in your editor by typing code . in your terminal.

Phase 2: Core Engineering & Data Pipelines

Because we are fetching posts from Nostr relays rather than local .md files, we must create a custom processing pipeline to handle rich text, math equations, and metadata.

Step 1: The Markdown Processor

Create a new file at src/utils/parseMarkdown.ts. This utility converts raw Nostr strings into safe, styled HTML.

import { unified } from "unified";
import remarkParse from "remark-parse";
import remarkMath from "remark-math";
import remarkRehype from "remark-rehype";
import rehypeKatex from "rehype-katex";
import rehypeStringify from "rehype-stringify";

export async function parseNostrMarkdown(content: string) {
  const result = await unified()
    .use(remarkParse)
    .use(remarkMath)
    .use(remarkRehype)
    .use(rehypeKatex)
    .use(rehypeStringify)
    .process(content);

  return result.toString();
}

Step 2: The Event Formatter

Create a new file at src/utils/formatNostrEvent.ts. This extracts SEO descriptions and generates proper naddr links for cross-platform Web3 sharing.

import { nip19 } from "nostr-tools";

export function formatNostrEvent(event: any) {
  const findTag = (key: string) => event.tags.find((t: any) => t[0] === key)?.[1];

  const summary = findTag("summary");
  const fallbackDesc = event.content
    .replace(/!\[.*?\]\(.*?\)/g, "") 
    .replace(/\[(.*?)\]\(.*?\)/g, "$1") 
    .replace(/(?:__|[*#`\[\]()\-+!=])/g, "")
    .substring(0, 160)
    .trim() + "...";

  const dTag = findTag("d") || "";
  let naddr = "";
  try {
    naddr = nip19.naddrEncode({
      kind: 30023,
      pubkey: event.pubkey,
      identifier: dTag,
    });
  } catch (e) {
    console.error("Naddr error", e);
  }

  return {
    id: naddr || event.id,
    title: findTag("title") || "Untitled",
    description: summary || fallbackDesc,
    pubDatetime: new Date(event.created_at * 1000),
    modDatetime: null,
    author: findTag("author") || "Nostr User",
    tags: event.tags.filter((t: any) => t[0] === "t").map((t: any) => t[1]),
    ogImage: findTag("image"),
    content: event.content,
    naddr: naddr
  };
}

Phase 3: Building the Interface

We will hijack AstroPaper's default routing to dynamically pull your Kind 30023 events at build time.

Step 1: The Homepage (`index.astro`)

Navigate to src/pages/index.astro. Delete everything and paste the code below. Replace the Hex string with your own public key.

---
import Layout from "@/layouts/Layout.astro";
import Header from "@/components/Header.astro";
import Footer from "@/components/Footer.astro";
import NDK, { type NDKEvent } from "@nostr-dev-kit/ndk";
import 'ws'; 

const ndk = new NDK({ 
  explicitRelayUrls: [
    "wss://relay.damus.io", 
    "wss://nos.lol",
    "wss://relay.primal.net"
  ] 
});

try {
  await ndk.connect(3000); 
} catch (err) {
  console.error("Nostr Connection failed:", err);
}

// REMEMBER TO INSERT YOUR HEX KEY BELOW
const filter = { 
  kinds: [30023], 
  authors: ["YOUR_HEX_PUBLIC_KEY_HERE"]
};

let events: Set<NDKEvent> = new Set();

try {
  const fetchPromise = ndk.fetchEvents(filter, { closeOnEose: true });
  const timeoutPromise = new Promise<Set<NDKEvent>>((resolve) => {
    setTimeout(() => resolve(new Set()), 4000);
  });

  events = await Promise.race([fetchPromise, timeoutPromise]);
} catch (err) {
  console.error("Fetch error:", err);
}

const posts = Array.from(events)
  .filter((e): e is NDKEvent & { created_at: number } => e.created_at !== undefined)
  .sort((a, b) => b.created_at - a.created_at)
  .map(e => {
    const cleanContent = e.content.replace(/[#*`_~\[\]\(\)-]/g, "").replace(/\s+/g, " ").trim();
    return {
      id: e.id,
      title: e.tags.find((t: string[]) => t[0] === 'title')?.[1] || "Untitled Post",
      summary: e.tags.find((t: string[]) => t[0] === 'summary')?.[1] || (cleanContent.substring(0, 120) + "..."),
      date: new Date(e.created_at * 1000).toLocaleDateString('en-US', {
        year: 'numeric', month: 'long', day: 'numeric'
      })
    };
  });
---

<Layout title="My Decentralized Mind-Dump">
  <Header />
  <main id="main-content" class="app-layout">
    <section id="hero" class="border-border border-b pt-8 pb-6">
      <h1 class="my-4 inline-block text-4xl font-bold sm:my-8 sm:text-5xl">My Nostr Mind-Dump</h1>
      <p>Pulled dynamically from the Nostr protocol at build time. Write on Web3, read everywhere.</p>
    </section>

    <section id="recent-posts" class="pt-12 pb-6">
      <h2 class="text-2xl font-semibold tracking-wide mb-6">Recent Notes</h2>
      <ul>
        {posts.map(post => (
          <li class="my-6">
            <a href={`/nostr/${post.id}`} class="inline-block text-xl font-bold text-skin-accent decoration-dashed underline-offset-4 hover:underline">
              {post.title}
            </a>
            <div class="text-sm opacity-80 mt-1">{post.date}</div>
            <p class="mt-2 line-clamp-3">{post.summary}</p>
          </li>
        ))}
      </ul>
    </section>
  </main>
  <Footer />
</Layout>

Step 2: The Article Reader Route

Create a new folder named nostr inside src/pages/. Inside that folder, create [id].astro. This generates dynamic paths for every article.

---
import Layout from "@/layouts/Layout.astro";
import Header from "@/components/Header.astro";
import Footer from "@/components/Footer.astro";
import NDK, { type NDKEvent } from "@nostr-dev-kit/ndk";
import 'ws';
import { parseNostrMarkdown } from "@/utils/parseMarkdown";
import { formatNostrEvent } from "@/utils/formatNostrEvent";

export async function getStaticPaths() {
  const ndk = new NDK({ explicitRelayUrls: ["wss://relay.damus.io", "wss://nos.lol"] });
  await ndk.connect(3000);

  let events: Set<NDKEvent> = new Set();

  // REMEMBER TO INSERT YOUR HEX KEY BELOW
  const filter = { kinds: [30023], authors: ["YOUR_HEX_PUBLIC_KEY_HERE"] };
  const fetchPromise = ndk.fetchEvents(filter, { closeOnEose: true });
  const timeoutPromise = new Promise<Set<NDKEvent>>((resolve) => setTimeout(() => resolve(new Set()), 4000));

  events = await Promise.race([fetchPromise, timeoutPromise]);

  return Array.from(events)
    .filter((e): e is NDKEvent & { created_at: number } => e.created_at !== undefined)
    .map(e => ({
      params: { id: e.id },
      props: { event: e }
    }));
}

interface Props { event: NDKEvent; }
const { event } = Astro.props;
const post = formatNostrEvent(event);
const htmlContent = await parseNostrMarkdown(post.content);
---

<Layout title={post.title}>
  <link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/katex@0.16.9/dist/katex.min.css" crossorigin="anonymous" />
  <Header />

  <main id="main-content" class="mx-auto w-full max-w-3xl px-4 pb-12 mt-8">
    <button class="focus-outline mb-6 flex hover:opacity-75" onclick="history.back()">
      <span>← Go back</span>
    </button>
    <h1 class="text-3xl font-bold text-skin-accent">{post.title}</h1>

    {post.naddr && (
      <div class="mt-6 flex flex-wrap items-center gap-3 text-sm bg-skin-card/10 p-4 rounded-lg border border-skin-line/50">
        <span class="font-bold">⚡ Nostr:</span>
        <a href={`nostr:${post.naddr}`} class="text-skin-accent hover:underline">Open in App</a>
        <a href={`https://yakihonne.com/article/${post.naddr}`} target="_blank" class="hover:text-skin-accent opacity-80">Yakihonne</a>
      </div>
    )}

    <article class="prose max-w-none prose-img:border-0 mt-8" set:html={htmlContent} />
  </main>
  <Footer />
</Layout>

<script>
  const renderMermaid = async () => {
    const codeBlocks = document.querySelectorAll("pre code.language-mermaid");
    if (codeBlocks.length === 0) return;
    const { default: mermaid } = await import("https://cdn.jsdelivr.net/npm/mermaid@10/dist/mermaid.esm.min.mjs");
    mermaid.initialize({ startOnLoad: false, theme: "dark" });

    for (const element of codeBlocks) {
      const id = `mermaid-${Math.random().toString(36).substr(2, 9)}`;
      const { svg } = await mermaid.render(id, element.textContent || "");
      const wrapper = document.createElement('div');
      wrapper.className = 'mermaid-container my-8 flex justify-center overflow-x-auto';
      wrapper.innerHTML = svg;
      element.parentElement?.replaceWith(wrapper);
    }
  };
  renderMermaid();
  document.addEventListener("astro:after-swap", renderMermaid);
</script>

Step 3: Global Styling and Contrast Fixes

Add these definitions to src/styles/global.css to fix dark mode contrast, ensure math blocks scroll gracefully on mobile, and apply proper borders to user-uploaded images.

/* Improve contrast for Dark Mode */
html[data-theme="dark"] .prose {
  --tw-prose-body: theme("colors.slate.200");
  --tw-prose-headings: theme("colors.white");
  --tw-prose-bold: theme("colors.white");
}

/* KaTeX Math Styling */
.katex-display {
  @apply my-8 overflow-x-auto py-4 px-2 rounded-lg;
  background-color: rgba(255, 255, 255, 0.03);
}

.katex {
  white-space: nowrap;
}

/* Nostr Image Attachments */
article img {
  @apply rounded-xl border shadow-md mx-auto my-8;
  border-color: var(--color-line); 
}

Start your local server by running npm run dev and opening http://localhost:4321. Your site should now dynamically render your Nostr notes.

Phase 4: AI-Native SEO (`llm.txt`)

As AI agents like Perplexity and SearchGPT replace traditional search engines, we must provide a semantic layer.

Create a file named llm.txt inside your public/ folder. Write a direct, markdown-formatted summary of your site's core philosophy and architecture. When an AI scrapes yourwebsite.com/llm.txt, it immediately contextualizes your niche with zero token waste.

Phase 5: Deployment & The Zero-Maintenance Pipeline

It is time to put your site on the public internet and automate the build process.

Push your code to a new public GitHub repository.
Log into Vercel, click Add New Project, import your repository, and click Deploy. Vercel will grant you a live URL.

The Automation Webhook

Right now, your site is static. If you publish a new article on Nostr, your site won't update until Vercel builds again.

In your Vercel Dashboard, navigate to Settings -> Git -> Deploy Hooks.
Create a hook named Nostr-Sync on the main branch and copy the generated URL.
In your GitHub repository, go to the Actions tab and create a new workflow named nostr-sync.yml.
Paste the following configuration, replacing the URL with your unique Vercel hook:

name: Nostr Auto-Sync

on:
  schedule:
    - cron: '0 */6 * * *'
  workflow_dispatch:

jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Trigger Vercel Build
        run: curl -X POST "https://api.vercel.com/v1/integrations/deploy/YOUR_UNIQUE_VERCEL_HOOK_URL"

Commit the changes.

You have successfully engineered an evergreen architecture. You write natively on Nostr, retaining absolute ownership of your cryptographic keys. Every 6 hours, GitHub Actions silently signals Vercel. Vercel scrapes the relays, compiles your latest thoughts into high-speed HTML, and serves it globally. Write once, syndicate everywhere.

Zeroing Out the Bill: The Developer’s Practical Guide to Eliminating Google Cloud (GCP) Idle Costs

Khe Ai — Tue, 02 Jun 2026 07:20:06 +0000

It is a classic developer milestone: you finish a side project, proof-of-concept, or staging test, and you responsibly tear down your infrastructure. You scale your compute instances to zero, delete or pause your databases, and walk away believing your cloud spend has dropped to absolute zero.

Then, the billing dashboard updates. You spot a persistent trickle of costs—fractions of a cent tracking a linear line upwards across your billing period. While the numbers seem trivial at a small scale (fractions of a cent tracking toward a dollar), these phantom charges represent a fundamental design mechanic in cloud systems: the hidden tax of at-rest storage.

The Core Rule of Cloud Billing: Compute is easily turned off, but data has gravity. If it occupies physical sectors on a disk in a cloud data center somewhere, Google will bill you for it—even if your applications are completely dark.

This guide details exactly why these costs happen, builds a framework for all potential dormant cloud costs you must guard against, and outlines automated strategies to achieve a true $0.00 infrastructure bill when your code is idle.

1. The Anatomy of the Staging Bill

When analyzing a low-cost, idle cloud project dashboard, expenditures typically pool into three specific storage-based categories after compute instances are scaled down:

Artifact Registry: Charges arise from hosting historical application build containers, package fragments, or deployment source artifacts.
Cloud SQL (Metadata/Storage Component): Even if an instance is stopped or deleted, persistent disks, backups, and IP assignments can sustain unyielding baseline costs.
Cloud Storage (GCS): Acts as the underlying system storage bucket infrastructure where automated frameworks drop deployment bundles, pipeline states, and continuous integration caches.

2. Deep-Dive: Remediation & Automation Strategies

Artifact Registry: Purging Container Bloat

Every single time a deployment pipeline runs (e.g., deploying code to Cloud Run), a baseline container image is generated and stored inside the Artifact Registry repository. Over weeks of iterations, these untagged historical layers build up significant digital debris.

🛠️ The Permanent Automated Fix

Do not rely on manual cleanup. Set up a declarative Cleanup Policy inside your repository:

Navigate to Artifact Registry > Repositories and select your deployment repository.
Click Edit Repository and scroll down to the Cleanup policies manager.
Add a rule with the condition Tag State: Any Tag State combined with an age threshold like Older than: 7d (7 days).
Change the evaluation enforcement action from Dry Run to Delete artifacts.

Cloud Storage: Mitigating Automated Backend Artifacts

Tools like Cloud Build naturally create cloud storage buckets (e.g., staging.project-id.appspot.com or project-id_cloudbuild) to compress and transport your code source before compiling it. These source zip files often remain forever unless lifecycle management intervenes.

To eliminate these costs passively, implement Object Lifecycle Management rules on your buckets via the console or globally via the gcloud CLI:

echo '{"rule": [{"action": {"type": "Delete"}, "condition": {"age": 7}}]}' > lifecycle.json
gcloud storage buckets update gs://YOUR_BUILDS_BUCKET --lifecycle-file=lifecycle.json

⚠️ Watch Out for the "Soft Delete" Catch: Google Cloud includes a default Soft Delete Policy on all new buckets. When an object lifecycle rule executes, or you manually delete a file, the object is placed in an invisible soft-deleted state for 7 days to allow recovery. During this window, you are still billed at regular storage rates! To achieve immediate bill reduction, click the bucket's Configuration tab, locate the Soft Delete Policy, edit it, and set the duration value to 0 days.

3. Comprehensive Checklist: Every Potential Idle Cost in GCP

To ensure your environment does not accumulate unexpected bills, use this definitive reference table outlining common services, their hidden idle costs, and exact mitigation vectors:

Service Category	What Charges You While Idle	Estimated Unit Cost (US)	Mitigation Action
Cloud Run / GCF	Minimum CPU Instances allocated to stay warm; CPU allocation set to "Always Allocated".	~0.04 / vCPU-hour	Set `min-instances` to 0; switch CPU allocation to "Only during request processing".
Artifact Registry	Active container storage layer data at-rest.	~0.10 per GB / month	Apply automated Repository Cleanup Policies (Age < 7-14 days).
Cloud Storage	Standard, Nearline, or Coldline storage data; Soft-deleted objects waiting out retention windows.	~0.02 to 0.026 per GB / month (Standard)	Set Object Lifecycle policies to auto-delete; modify Soft Delete retention to 0 days.
Cloud SQL	Persistent Disk space (SSD/HDD); Automated database backup snapshots; Retained Static IP configurations.	~0.17 per GB/mo (SSD) ~0.01 to 0.025 per hour for IP	Stopping instances halts CPU/RAM charges but keeps charging for disk/IPs. Clone data, export to GCS, and delete the instance fully.
Compute Engine	Unattached Persistent Disks (PDs); Orphaned Static External IP Addresses.	~0.04 per GB/mo (Standard) ~0.01 / hour idle IP	Go to Compute Engine > Disks and delete detached storage; Release unused static external IPs.
VPC Networking	Forwarding rules (Load Balancers left running without active backends); NAT Gateways.	~0.025+ per hour per rule / gateway	Delete idle External HTTP(S) Load Balancers and Cloud NAT gateways when unneeded.
Vertex AI	Dormant custom notebooks (User-managed instances); Deployed endpoints hosting models.	Varies by underlying Compute Engine sizing	Stop Vertex Workbench notebooks when not coding; Undeploy models from active prediction endpoints.
Logging & Monitoring	Log ingestion exceeding the free 50 GiB/month limit; Custom metric collection data.	~0.50 per GiB ingested	Set up log exclusion filters to drop high-volume stdout/stderr debug records.

4. Summary Blueprint for Staging Environments

To keep your non-production workloads under absolute financial control, embed the following hygiene habits into your architectural processes:

Infrastructure as Code (IaC): Define environment testbeds completely in Terraform. Instead of spinning services down or pausing individual configurations, execute a wholesale terraform destroy when the sprint or research spike ends.
Budget Alerts with Pub/Sub: Do not rely on looking at the console. Create a hyper-sensitive budget alert (e.g., at $1.00) linked to a Cloud Function that automatically initiates teardowns if thresholds are breached.
Tagging and Labels: Label everything with env: staging or owner: developer_name. This lets you sort your billing console instantly by labels to identify which resource group is generating background noise.

By shifting from manual infrastructure adjustments to structured automated lifecycles, you turn cloud cost optimization into an immutable background process—leaving your dashboard clean, predictable, and flat.

The Barbell Founder: Why I Chose to be a Part-timer to Protect My Startup

Khe Ai — Sun, 10 May 2026 14:50:07 +0000

Stop optimizing for nominal wages. Start optimizing for cognitive surplus and time sovereignty.

In the modern startup ecosystem, there is a piece of conventional wisdom that acts as a silent killer: “Get a high-paying, stable corporate job to fund your dream.”

On paper, it sounds responsible. In reality, it is a trap. For a founder—especially a technical one—a high-status full-time role is often a "gold-plated cage" that drains your energy, steals your intellectual property, and ensures you never have the "escape velocity" needed to launch.

I have abandoned that path. Instead, I have adopted a radical decoupling of Survival from Self-Actualization. I call it the Low-Entropy Employment Model.

1. The Strategy: Nassim Taleb’s Barbell

In finance, the Barbell Strategy involves avoiding the "middle ground." You place 90% of your resources in hyper-safe, boring assets to guarantee survival, and 10% in highly aggressive, speculative bets for massive upside.

I have applied this to my life:

The Safety (90%): A "mindless," part-time, or contract job that is walkable and stress-free. It provides the Minimum Viable Income.
The Aggression (10%): My startup. This is where 100% of my ambition, creativity, and aggression are focused.

Most people get stuck in the middle—a moderately stressful, moderately paying job that pays just enough to stay comfortable, but drains just enough energy to stay stagnant.

2. The Biology: Cognitive Surplus vs. Ego Depletion

Why do I prioritize "mindless" work? Because of a psychological reality called Ego Depletion.

The human brain has a finite daily reservoir of willpower and decision-making capacity. If your day job requires you to solve complex algorithmic problems, navigate toxic office politics, or manage high-stakes client crises, your prefrontal cortex is chemically exhausted by 5:00 PM.

The Founder’s Axiom: Free time is useless if you have no cognitive energy left to spend.

By choosing a low-entropy job, I arrive at my "startup hours" with my nervous system intact. I am not "recovering" from my day job; I am starting my real day with a full battery.

3. The Math: The "True Hourly Rate" Illusion

Let’s use a skeptical, research-based simulation to debunk the "higher pay" myth. Consider two options for a 5-hour part-time shift (20 days/month):

Option A: A local job within walking distance. Pay: RM 8.72/hr.
Option B: A "better" job requiring a commute (MRT/LRT). Pay: RM 11.00/hr.

Society says take Option B. The math says otherwise when we calculate the Total Cost of Employment (TCE).

$$True\ Hourly\ Rate = \frac{Total\ Daily\ Income}{Hours\ Worked + Commute\ Time}$$

Metric	Option A (Local)	Option B (Commute)
Gross Daily Income	RM 43.60	RM 55.00
Time Invested	5.5 Hours (0.5h walk)	7.5 Hours (2.5h transit)
True Hourly Rate	RM 7.92 / hr	RM 7.33 / hr

The Verdict: Option B is a net loss. Not only is the true rate lower, but the Opportunity Cost is 40 hours of lost time per month. Those 40 hours could be used to write 3 government grants, pitch 50 investors, or build a core product feature.

4. The Invisible Chains: The Risk of Full-Time

For a programmer or technical founder, a salaried full-time role is strategically dangerous.

The Intellectual Property (IP) Trap

Standard full-time contracts often include "Assignment of Inventions" clauses. Legally, any code you write—even on your own laptop at 2:00 AM—can be claimed by your employer if it’s even tangentially related to their field.

The Solution: Freelance or part-time contracts are "cleaner." They define a narrow scope of work, leaving your "after-hours" IP safely in your hands.

The "Identity Tax"

Corporate culture demands emotional "alignment." They want you to care about their vision. This creates an Emotional Sunk Cost. You start optimizing for a promotion you don't actually want, which tethers your self-worth to a hierarchy you don't own.

The Non-Compete Chokehold

Full-time roles often come with non-compete clauses that can legally block you from launching a startup in a similar industry for years. mercenary, part-time roles rarely carry this legal weight.

5. The Execution

This strategy is not a "slack-off" plan. It is an optimization plan. To make it work, you must adhere to three strict rules:

I. Minimalist Consumption

You cannot live a high-status lifestyle on a low-entropy income. You must be a Minimalist in Consumption to remain a Maximalist in Production. Every RM saved is a second of freedom bought.

II. The Health & Legal Buffer

Since you are forgoing corporate benefits, you must be disciplined:

Insurance: Use a portion of your income to secure your own medical and life insurance.
Contract Review: Never sign a part-time contract without checking for IP-grabbing clauses.

III. The Discipline Filter

If you take an "easy" job but spend your reclaimed 40 hours on Netflix or gaming, you aren't a Barbell Founder—you are just underemployed. This strategy only works if you go to "war" for your startup the moment you clock out of your survival job.

Conclusion: Time Sovereignty is the Ultimate Weapon

In the startup game, the person who can stay in the arena the longest wins. By lowering your burn rate and protecting your cognitive energy, you become incredibly difficult to kill.

Stop optimizing for a job title. Start optimizing for Time Sovereignty. Your startup deserves your best brain—don't sell it to the highest bidder for a few extra Ringgit and a long commute.

What is your "True Hourly Rate" today? Is it time to quit the "good" job for the right one?

Building an AI-Powered ERP System with Gemma 26B MoE, .NET 8, Python & React

Khe Ai — Sat, 09 May 2026 06:25:26 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

Building an industrial-grade SaaS from scratch can feel daunting. As a software engineer, I’ve found that the secret to not getting overwhelmed is architecture. When you break down complex monolithic systems into manageable, robust microservices, that’s where the real fun begins.

Recently, I built Y&Y App (yny)—a comprehensive, microservices-based ERP-lite system. But it doesn't just manage inventory; it integrates a specialized AI Domain-Expert Agent that can read technical manuals and troubleshoot industrial equipment in real-time.

In this masterclass, I am going to walk you through exactly how I built it, step-by-step. By the end of this guide, you will transition from a blank folder to a fully functioning, production-ready SaaS prototype deployed to the cloud.

The Deliverables

GitHub Repo: kheAI/yny-app
Video Demo: Watch on YouTube
Vercel Live Demo: Play

🏗️ The Architecture & Tech Stack (The "Why")

To ensure data integrity, prevent our apps from becoming logically entangled, and allow independent scaling, I chose a strict Microservices Architecture.

Here is what we are using and why:

Data Tier: Google Cloud SQL (PostgreSQL). We are using the pgvector extension so our database can handle both standard relational data (inventory) and mathematical arrays (AI memory/embeddings) in the same place.
Logic Tier (ERP): A type-safe .NET 8 Web API. C# is the industry standard for fast, secure delivery of structured business data.
Logic Tier (AI): A Python FastAPI service. Python is the undisputed king of AI. This service executes a Retrieval-Augmented Generation (RAG) workflow using the Gemini API (refer Github Repo for Vertex AI version too).
Presentation Tier: A responsive frontend built with React and Vite.
Hosting: Serverless, auto-scaling backend deployments via Google Cloud Run (meaning you only pay when people use it), with the frontend hosted on Vercel.

Engineer's Note on AI Models:

For this tutorial, we are utilizing the Gemini API.
We'll use the gemma-4-26b-a4b-it for interactive apps or agents where low latency is important. A 26B Mixture-of-Experts (MoE) model that offers fast inference by using only ~4B active parameters. It offers nearly the same intelligence as the 31B model but runs significantly faster because it only activates a fraction of its parameters (4B) per token.
For Embeddings, we choose gemini-embedding-001 to turn our text into 768-dimensional mathematical vectors. For multimodal model, can try gemini-embedding-2.
The Gemini API SDK's default to v1beta, but you can opt to use other versions by setting the API version genai.Client(http_options={'api_version': 'v1'}).

How the System Flows

🛠️ Phase 0: Workspace Setup & Prerequisites

Before writing a single line of code, we need to set up our workbench.

1. The Tools You Need

Ensure you have the following installed on your machine:

Google Cloud Account: Create a project (e.g., yny-saas-2024). Write down your Project ID.
gcloud CLI: Installed and authenticated. Run gcloud auth login, then gcloud config set project YOUR_PROJECT_ID.
.NET 8 SDK: For our C# backend. Verify with dotnet --version.
Python 3.10+: For the AI service. Verify with python3 --version.
Node.js (LTS): For the React frontend. Verify with node -v.
Gemini API Key: Get one for free from Google AI Studio.

2. The Directory Structure

Create a master folder. This will act as the "monorepo" for our three microservices.

mkdir yny-app
cd yny-app

Crucial Step: Create a .gitignore file in this root folder immediately. This prevents you from accidentally uploading database passwords or API keys to GitHub.

# yny-app/.gitignore
node_modules/
bin/
obj/
venv/
.env
appsettings.json
.DS_Store

🗄️ Phase 1: The Cloud Database (Postgres + pgvector)

We need a database capable of standard SQL (for products) and Vector Math (for the AI).

Step 1: Provision the Database

Go to the Google Cloud Console -> Cloud SQL -> Create Instance -> PostgreSQL.
Instance ID: yny-db-instance
Password: YnySecurePass26 (Write this down! Avoid characters like @ or # to prevent URL parsing errors).
Edition: Choose Enterprise (Sandbox/Shared Core) to keep costs near zero.
Region: us-central1. Click Create (Takes ~5 minutes).

Step 2: Seed the Schema & Data

Once running, open the Google Cloud Shell (the terminal icon at the top right of the GCP console) and connect to your database:

gcloud sql connect yny-db-instance --user=postgres

When prompted, paste your password. Then, run this SQL script to build your foundation:

-- 1. Enable pgvector for AI Memory
CREATE EXTENSION IF NOT EXISTS vector;

-- 2. Create the ERP Tables
CREATE TABLE Products (
    ProductCode VARCHAR(50) PRIMARY KEY,
    ProductName VARCHAR(100) NOT NULL,
    Category VARCHAR(50),
    QuantityInStock INT DEFAULT 0,
    Status VARCHAR(20) DEFAULT 'Active'
);

-- 3. Create the AI Knowledge Base Table
-- Google's embeddings model outputs exactly 768 dimensions
CREATE TABLE manual_knowledge (
    id SERIAL PRIMARY KEY,
    product_code VARCHAR(50) REFERENCES Products(ProductCode),
    section_title VARCHAR(100),
    text_chunk TEXT,
    embedding VECTOR(768) 
);

-- 4. Insert Production-Alike ERP Data
INSERT INTO Products (ProductCode, ProductName, Category, QuantityInStock, Status)
VALUES 
('PUMP-CENT-001', 'Centrifugal Pump - Model X1', 'Pumps', 5, 'Active'),
('SENS-VIB-99', 'Vibration Sensor - Wireless', 'Sensors', 42, 'Active'),
('VALVE-GATE-05', 'Heavy Duty Gate Valve', 'Valves', 0, 'Out of Stock');

-- 5. Check
-- Check Your ERP Inventory (Basic)
SELECT * FROM Products;
-- Filter for Critical Items (Low/No Stock)
SELECT ProductCode, ProductName, QuantityInStock, Status
FROM Products
WHERE QuantityInStock < 10 OR Status = 'Out of Stock';
-- Safely Check the AI Knowledge Base
SELECT 
    id, 
    product_code, 
    section_title, 
    substring(text_chunk from 1 for 50) AS manual_snippet 
FROM manual_knowledge;
-- Verify the AI Vector Dimensions
SELECT 
    id, 
    product_code, 
    vector_dims(embedding) AS vector_dimensions
FROM manual_knowledge;
-- The "Big Picture" JOIN Query
SELECT 
    p.ProductCode, 
    p.ProductName, 
    p.QuantityInStock,
    m.section_title AS AI_Manual_Available
FROM Products p
LEFT JOIN manual_knowledge m ON p.ProductCode = m.product_code;

Type \q and press Enter to exit.

📌 Take Note: Go to your Cloud SQL dashboard and copy the Public IP of your database. You will need it for the next steps.

⚡ Phase 2: The ERP Backend (.NET 8 Web API)

C# is my go-to for enterprise logic. It is blazingly fast and highly structured. We will build a lightweight API to serve our inventory data.

Step 1: Initialize the Project

In your local terminal (inside the yny-app folder):

dotnet new webapi -n yny.Api
cd yny.Api
dotnet add package Npgsql.EntityFrameworkCore.PostgreSQL

Step 2: Database Connection String

Open yny.Api/appsettings.json. Configure your connection string replacing YOUR_DB_IP with your database's Public IP:

{
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft.AspNetCore": "Warning"
    }
  },
  "AllowedHosts": "*",
  "ConnectionStrings": {
    "DefaultConnection": "Host=YOUR_DB_IP;Database=postgres;Username=postgres;Password=YnySecurePass26"
  }
}

Step 3: Write the API Logic

We are using Minimal APIs to keep our code clean. Open Program.cs and replace everything with this:

using Microsoft.EntityFrameworkCore;
using System.ComponentModel.DataAnnotations;
using System.ComponentModel.DataAnnotations.Schema;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddCors(options => {
    options.AddPolicy("AllowAll", policy => policy
        .WithOrigins(
            "http://localhost:5173",
            "http://localhost:3000",
            "https://yny-ui.vercel.app",
            "https://yny-ui-158766252751.us-central1.run.app"
        )
        .AllowAnyHeader()
        .AllowAnyMethod());
});

var connString = builder.Configuration.GetConnectionString("DefaultConnection");
builder.Services.AddDbContext<AppDbContext>(opt => opt.UseNpgsql(connString));
//.UseLowerCaseNamingConvention());

var app = builder.Build();

app.UseCors("AllowAll");
app.UseHttpsRedirection();

app.MapGet("/", () => new { status = "ERP API running" });

app.MapGet("/api/products", async (AppDbContext db) => {
    return await db.Products.ToListAsync();
});

app.MapGet("/api/products/{code}", async (string code, AppDbContext db) => {
    var product = await db.Products.FindAsync(code);
    return product is not null ? Results.Ok(product) : Results.NotFound();
});

app.Run();

[Table("products")]
public class Product {
    [Column("productcode")]
    [Key]
    public string ProductCode { get; set; } = string.Empty;

    [Column("productname")]
    public string ProductName { get; set; } = string.Empty;

    [Column("category")]
    public string Category { get; set; } = string.Empty;

    [Column("quantityinstock")]
    public int QuantityInStock { get; set; }

    [Column("status")]
    public string Status { get; set; } = string.Empty;
}

public class AppDbContext : DbContext {
    public AppDbContext(DbContextOptions<AppDbContext> options) : base(options) { }
    public DbSet<Product> Products { get; set; }
}

Test it: Run dotnet run. Open your browser to http://localhost:5000/api/products to see your JSON data!

🧠 Phase 3: The AI Microservice (Python + FastAPI)

This is the "Brain" of our application. We are using a pattern called RAG (Retrieval-Augmented Generation). When a user asks a question, this service turns the question into math, finds similar mathematical concepts in our Postgres database, and feeds that exact manual to the LLM to get a factual answer.

Step 1: Python Setup

Open a new terminal tab. Go back to your yny-app root:

mkdir yny.AI
cd yny.AI
python3 -m venv venv
source venv/bin/activate  # On Windows use: venv\Scripts\activate

Create a requirements.txt:

fastapi
uvicorn
psycopg2-binary
python-dotenv
google-generativeai

Run: pip install -r requirements.txt

Step 2: Configure Secrets

Create a .env file in the yny.AI folder (replace YOUR_DB_IP and YOUR_API_KEY):

DB_URL=postgresql://postgres:YnySecurePass26@YOUR_DB_IP:5432/postgres
GEMINI_API_KEY=YOUR_API_KEY

Step 3: Write the RAG Pipeline (`main.py`)

Create main.py. Notice the SQL query using <=>. This is the pgvector operator for Cosine Distance—it calculates how closely related the user's question is to our manuals!

from fastapi import FastAPI, HTTPException
from fastapi.middleware.cors import CORSMiddleware
from dotenv import load_dotenv
import google.generativeai as genai
import psycopg2
import os

load_dotenv()

app = FastAPI()
app.add_middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"], allow_headers=["*"])

# Initialize Gemini
genai.configure(api_key=os.getenv("GEMINI_API_KEY"))
llm = genai.GenerativeModel("gemma-4-26b-a4b-it"")

@app.get("/")
def root():
    return {"status": "AI API running perfectly"}

@app.get("/troubleshoot")
async def troubleshoot(question: str, product_code: str):
    try:
        # Step 1: Convert question to vector
        embedding_result = genai.embed_content(
            model="gemini-embedding-001",
            content=question,
            output_dimensionality=768
        )
        query_vector = embedding_result['embedding']

        # Step 2: Search Postgres using pgvector Cosine Distance (<=>)
        conn = psycopg2.connect(os.getenv("DB_URL"))
        cur = conn.cursor()
        query = """
            SELECT text_chunk FROM manual_knowledge 
            WHERE product_code = %s 
            ORDER BY embedding <=> %s::vector LIMIT 1
        """
        cur.execute(query, (product_code, query_vector))
        result = cur.fetchone()
        conn.close()

        context = result[0] if result else "No manual found."

        # Step 3: Generate answer with Gemma
        prompt = f"""
        You are an expert industrial maintenance AI.
        Use ONLY the following manual excerpt to answer the user's question.
        Manual Excerpt: {context}
        User Question: {question}
        """

        response = llm.generate_content(prompt)
        return {"answer": response.text}

    except Exception as e:
        raise HTTPException(status_code=500, detail=str(e))

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8080)

Step 4: Seed the AI "Brain" (`seed.py`)

To prove this works, we must inject an equipment manual into our database. Create seed.py:

from dotenv import load_dotenv
import google.generativeai as genai
import psycopg2
import os

load_dotenv()
genai.configure(api_key=os.getenv("GEMINI_API_KEY"))

manual_text = """
Maintenance Manual for PUMP-CENT-001:
Issue: Crackling noise (like marbles/gravel).
Diagnosis: Pump is experiencing cavitation due to low Net Positive Suction Head.
Action: Immediately throttle the discharge valve to reduce flow rate. Torque housing bolts to 45 Nm.
"""

print("Embedding text via Gemini...")
embedding_result = genai.embed_content(
    model="gemini-embedding-001",
    content=manual_text,
    output_dimensionality=768
)
vector = embedding_result['embedding']

print("Saving to PostgreSQL...")
conn = psycopg2.connect(os.getenv("DB_URL"))
cur = conn.cursor()
cur.execute(
    "INSERT INTO manual_knowledge (product_code, section_title, text_chunk, embedding) VALUES (%s, %s, %s, %s)",
    ('PUMP-CENT-001', 'Troubleshooting: Noise', manual_text, vector)
)
conn.commit()
conn.close()
print("Vector Seeded Successfully!")

Run python seed.py once. Your database can now "think" about centrifugal pumps! Test your API by running python main.py.

🎨 Phase 4: The Frontend UI (React + Vite)

Step 1: Initialize the App

Go back to the root yny-app:

npm create vite@latest yny-ui -- --template react
cd yny-ui
npm install axios

Step 2: Build the Dashboard (`src/App.jsx`)

Replace App.jsx entirely. This UI will fetch inventory from .NET and query Python for AI troubleshooting.

import { useState, useEffect } from 'react'
import axios from 'axios'
import ReactMarkdown from 'react-markdown'
import remarkGfm from 'remark-gfm'

function App() {
  const [products, setProducts] = useState([])
  const [question, setQuestion] = useState("")
  const [aiAnswer, setAiAnswer] = useState("")
  const [loading, setLoading] = useState(false)

  const ERP_API = import.meta.env.VITE_ERP_API || 'https://erp-api-158766252751.us-central1.run.app'
  const AI_API = import.meta.env.VITE_AI_API || 'https://ai-api-158766252751.us-central1.run.app'

  useEffect(() => {
    axios.get(`${ERP_API}/api/products`)
         .then(res => setProducts(res.data))
         .catch(err => console.error("ERP API not running", err))
  }, [])

  const askAI = async (productCode) => {
    if (!question) return;
    setLoading(true)
    try {
      const res = await axios.get(`${AI_API}/troubleshoot`, {
        params: { question, product_code: productCode }
      })
      setAiAnswer(res.data.answer)
    } catch (err) {
      setAiAnswer("Error reaching AI service.")
    }
    setLoading(false)
  }

  return (
    <div style={{ padding: '2rem', fontFamily: 'system-ui', maxWidth: '900px', margin: '0 auto' }}>
      <h1 style={{ color: '#0056b3' }}>Y&Y SaaS Dashboard</h1>

      <h3>1. Live ERP Inventory: .NET Core (C#) + CloudSQL (PostgreSQL)</h3>
      <table style={{ width: '100%', textAlign: 'left', borderCollapse: 'collapse' }}>
        <thead style={{ backgroundColor: '#f4f4f4' }}>
          <tr>
            <th style={{ padding: '8px', borderBottom: '2px solid #ddd' }}>Code</th>
            <th style={{ padding: '8px', borderBottom: '2px solid #ddd' }}>Name</th>
            <th style={{ padding: '8px', borderBottom: '2px solid #ddd' }}>Category</th>
            <th style={{ padding: '8px', borderBottom: '2px solid #ddd' }}>Stock</th>
          </tr>
        </thead>
        <tbody>
          {products.map(p => (
            <tr key={p.productCode}>
              <td style={{ padding: '8px', borderBottom: '1px solid #ddd' }}>{p.productCode}</td>
              <td style={{ padding: '8px', borderBottom: '1px solid #ddd' }}>{p.productName}</td>
              <td style={{ padding: '8px', borderBottom: '1px solid #ddd' }}>{p.category}</td>
              <td style={{ padding: '8px', borderBottom: '1px solid #ddd', color: p.quantityInStock === 0 ? 'red' : 'green' }}>
                {p.quantityInStock}
              </td>
            </tr>
          ))}
        </tbody>
      </table>

      <hr style={{ margin: '2rem 0' }} />

      <h3>2. AI Domain Expert Agent: FastAPI (Python) + Gemma (Gemini)</h3>
      <div style={{ padding: '1.5rem', borderRadius: '8px', border: '1px solid #ccc', backgroundColor: '#fafafa' }}>
        <p><strong>Target Equipment:</strong> PUMP-CENT-001</p>
        <input 
          type="text" 
          value={question} 
          onChange={e => setQuestion(e.target.value)} 
          placeholder="e.g., Why is the pump sounding like gravel?" 
          style={{ width: '100%', padding: '0.75rem', marginBottom: '1rem', borderRadius: '4px', border: '1px solid #ccc', boxSizing: 'border-box' }}
        />
        <button 
          onClick={() => askAI('PUMP-CENT-001')} 
          disabled={loading} 
          style={{ padding: '0.75rem 1.5rem', backgroundColor: '#0056b3', color: 'white', border: 'none', borderRadius: '4px', cursor: 'pointer', marginBottom: '1rem' }}>
          {loading ? "Analyzing Manuals..." : "Consult AI"}
        </button>

        {aiAnswer && (
          <div style={{ marginTop: '1.5rem', padding: '1rem', backgroundColor: '#eef6ff', borderLeft: '4px solid #0056b3', borderRadius: '4px' }}>
            <strong style={{ fontSize: '1.1rem', color: '#0056b3' }}>YNY Tech Agent:</strong>
            <div style={{ marginTop: '1rem', lineHeight: '1.8', textAlign: 'left' }}>
              <ReactMarkdown
                remarkPlugins={[remarkGfm]}
                components={{
                  p: ({ node, ...props }) => <p style={{ marginBottom: '1rem', textAlign: 'left' }} {...props} />,
                  h1: ({ node, ...props }) => <h2 style={{ marginTop: '1.5rem', marginBottom: '0.5rem', color: '#0056b3' }} {...props} />,
                  h2: ({ node, ...props }) => <h3 style={{ marginTop: '1.2rem', marginBottom: '0.4rem', color: '#0056b3' }} {...props} />,
                  h3: ({ node, ...props }) => <h4 style={{ marginTop: '1rem', marginBottom: '0.3rem', color: '#0056b3' }} {...props} />,
                  strong: ({ node, ...props }) => <strong style={{ color: '#d9534f', fontWeight: 'bold' }} {...props} />,
                  em: ({ node, ...props }) => <em style={{ fontStyle: 'italic', color: '#666' }} {...props} />,
                  ul: ({ node, ...props }) => <ul style={{ marginLeft: '1.5rem', marginTop: '0.8rem', marginBottom: '0.8rem', textAlign: 'left' }} {...props} />,
                  ol: ({ node, ...props }) => <ol style={{ marginLeft: '1.5rem', marginTop: '0.8rem', marginBottom: '0.8rem', textAlign: 'left' }} {...props} />,
                  li: ({ node, ...props }) => <li style={{ marginBottom: '0.6rem', textAlign: 'left' }} {...props} />,
                  code: ({ node, ...props }) => <code style={{ backgroundColor: '#f4f4f4', padding: '2px 6px', borderRadius: '3px', fontFamily: 'monospace', color: '#d9534f' }} {...props} />,
                  blockquote: ({ node, ...props }) => <blockquote style={{ borderLeft: '4px solid #0056b3', paddingLeft: '1rem', marginLeft: 0, marginTop: '0.8rem', marginBottom: '0.8rem', color: '#666' }} {...props} />,
                  hr: ({ node, ...props }) => <hr style={{ margin: '1.5rem 0', border: 'none', borderTop: '1px solid #ddd' }} {...props} />,
                }}
              >
                {aiAnswer}
              </ReactMarkdown>
            </div>
          </div>
        )}
      </div>
    </div>
  )
}

export default App

Run npm run dev and test your local full-stack masterpiece!

🚀 Phase 5: Containerization & Cloud Run Deployment

Now, we take our local code to the cloud. We will wrap our APIs in Docker containers and deploy them via Google Cloud Run (which scales to zero, saving you money!).

⚠️ The Cloud SQL Gotcha (Read This!):
Locally, you connected to Postgres via a TCP port (5432) and an IP address. In Google Cloud Run, best practice dictates you connect securely via a Unix domain socket.
We don't need a clunky proxy inside our Dockerfile. Google Cloud Run does this natively if we pass the right connection string!

If you're the project owner, grant yourself permissions first:

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member=user:YourEmail@gmail.com \
  --role=roles/cloudbuild.builds.editor,roles/cloudsql.client

Step 1: Deploying the .NET API

In /yny.Api, create a clean Dockerfile:

FROM mcr.microsoft.com/dotnet/sdk:8.0 AS build
WORKDIR /app
COPY . .
RUN dotnet publish -c Release -o out

FROM mcr.microsoft.com/dotnet/aspnet:8.0
WORKDIR /app
COPY --from=build /app/out .
EXPOSE 8080
ENV ASPNETCORE_URLS=http://+:8080
ENTRYPOINT ["dotnet", "yny.Api.dll"]

Deploy it via your terminal (Replace YOUR_PROJECT_ID):

# 1. Build and push the image to Google Container Registry
gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/erp-api

# 2. Deploy to Cloud Run (Notice the new Unix Socket Connection String!)
gcloud run deploy erp-api \
  --image gcr.io/YOUR_PROJECT_ID/erp-api \
  --region us-central1 \
  --allow-unauthenticated \
  --add-cloudsql-instances YOUR_PROJECT_ID:us-central1:yny-db-instance \
  --set-env-vars ConnectionStrings__DefaultConnection="Host=/cloudsql/YOUR_PROJECT_ID:us-central1:yny-db-instance;Database=postgres;Username=postgres;Password=YnySecurePass26;"

(Make sure to link your Cloud SQL instance to this Cloud Run service under the "Connections" tab in the GCP Console!)

Step 2: Deploying the Python AI API

In /yny.AI, create a Dockerfile:

FROM python:3.12-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
EXPOSE 8080
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8080"]

Deploy it (Remember to use your actual Gemini API key here, or better yet, use GCP Secret Manager in production):

gcloud builds submit --tag gcr.io/YOUR_PROJECT_ID/ai-api

gcloud run deploy ai-api \
  --image gcr.io/YOUR_PROJECT_ID/ai-api \
  --region us-central1 \
  --allow-unauthenticated \
  --add-cloudsql-instances YOUR_PROJECT_ID:us-central1:yny-db-instance \
  --set-env-vars GEMINI_API_KEY="YOUR_API_KEY",DB_URL="postgresql+psycopg2://postgres:YnySecurePass26@/postgres?host=/cloudsql/YOUR_PROJECT_ID:us-central1:yny-db-instance"

Step 3: Deploying the Frontend to Vercel

Take note of the URLs Cloud Run just generated for you (e.g., https://erp-api-xyz.run.app and https://ai-api-xyz.run.app).

Push your yny-ui code to GitHub.
Log into Vercel and Import your repository.
Under Environment Variables, add:
- VITE_ERP_API = [Your Cloud Run .NET URL]
- VITE_AI_API = [Your Cloud Run Python URL]
Click Deploy. Your UI is now live globally! Your UI will be live at: https://yny-ui.vercel.app (or custom domain). Auto-deploys on every push to main branch!

🔄 Phase 6: Level-Up to CI/CD (Bonus)

Tired of typing gcloud commands manually? Let GitHub deploy it for you. Create .github/workflows/deploy.yml in your repo:

name: Deploy Microservices
on:
  push:
    branches: [ main ]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Auth GCP
        uses: google-github-actions/auth@v2
        with:
          credentials_json: '${{ secrets.GCP_SA_KEY }}'
      - name: Set up Cloud SDK
        uses: google-github-actions/setup-gcloud@v2

      - name: Deploy .NET API
        run: |
          cd yny.Api
          gcloud builds submit --tag gcr.io/${{ secrets.GCP_PROJECT_ID }}/erp-api
          gcloud run deploy erp-api --image gcr.io/${{ secrets.GCP_PROJECT_ID }}/erp-api --region us-central1

(You will need to set GCP_PROJECT_ID and a GCP_SA_KEY in your GitHub Repository Settings -> Secrets).

🎤 Phase 7: The Final Demo Script

If you are showcasing this project to stakeholders, here is the exact narrative flow I recommend:

Show the Live Dashboard: "This is the Y&Y SaaS Dashboard. The top section is our .NET 8 ERP pulling live operational data directly from a PostgreSQL instance." Point out the real-time stock levels, specifically the out-of-stock valve.
Setup the Incident: "Imagine a junior engineer is on the factory floor and hears a strange crackling noise coming from PUMP-CENT-001."
Execute the Prompt: Type: "Why is the pump making a crackling noise like gravel and what should I do?" into the AI input and hit Consult AI.
Explain the Magic: "Right now, our Python microservice is converting my question into a mathematical vector. It's querying the pgvector database via Cosine Distance to retrieve the exact manufacturer maintenance manual excerpt, and passing that strict context to Google's Gemma model to synthesize a safe resolution."
The Resolution: The AI will output a clean, professional answer based strictly on the manual we seeded (diagnosing cavitation and advising them to throttle the valve).

Wrap Up

By completing this build, you've successfully created a modern enterprise system. You separated concerns using microservices, connected to cloud databases, implemented the industry-standard RAG AI pattern, and utilized serverless cloud deployment.

The gap between a "cool script" and an "enterprise system" is architecture. And you just built it.

Happy Coding!

Building a Systemic Autonomy Agent: OpenClaw + Gemma 4 & TurboQuant on Raspberry Pi 4B

Khe Ai — Sat, 09 May 2026 06:20:02 +0000

This is a submission for the Gemma 4 Challenge: Write About Gemma 4

If you’re reading this, you probably want to run a local, autonomous AI agent but might feel overwhelmed by the hardware requirements or complex software stacks. I was in exactly the same boat. I wanted to build an autonomous agent using OpenClaw, governed by the ethical and systemic framework of the KheAi Protocol, but I wanted it running entirely at the edge—specifically, on a Raspberry Pi 4B.

After a lot of trial, error, and compiling, I successfully turned my Raspberry Pi 4B (8GB RAM, 120GB SSD boot) into a highly efficient edge brain running Gemma 4 (e2b) optimized with TurboQuant.

Here is exactly how I did it, step-by-step, so you can follow along even if you are a total beginner.

The Master Plan: What We Are Building

Before diving into the terminal commands, let's break down the architecture of what we are building:

The Hardware (The Body): A Raspberry Pi 4B (8GB RAM). Crucially, we are booting from a 120GB SSD, not a MicroSD card. If you want an agent that reads and writes data constantly, an SD card will bottleneck your speed and eventually corrupt.
The Mind (The LLM): Gemma 4 E2B (specifically the Q4_K_M quantization). This is a highly capable Small Language Model (SLM) fine-tuned for code execution and tool use.
The Optimizer (TurboQuant): Running a modern LLM on 8GB of RAM is tight. We will use a custom branch of llama.cpp featuring TurboQuant, which dynamically compresses the model's "short-term memory" (KV Cache), preventing our Pi from crashing during long conversations.
The Soul (KheAi Protocol): Instead of a generic "hacking" persona, we will govern our OpenClaw agent using the KheAi Protocol—a framework for Systemic Autonomy. This gives the agent a structured, ethical, and goal-oriented operating system.
Networking (Optional): Tailscale for a Zero Trust Mesh Network. This allows secure, remote access to the OpenClaw dashboard and local terminal without exposing ports to the public internet.

Let's get your edge agent alive.

Phase 1: Hardware & OS Foundation (The Body)

Before we touch the AI, we need a stable "nervous system."

1.1 Boot from SSD (Non-Negotiable)

Running an autonomous agent on a MicroSD card will kill the card within weeks due to high read/write cycles and slow down the LLM's "thinking" time.

Action: Use Raspberry Pi Imager to flash Raspberry Pi OS (64-bit) onto your 120GB SSD.
Optimization: In the settings, enable SSH and set your username/password.

1.2 Thermal Management

The Pi 4B will throttle (slow down) at 80°C, the "Brain" slows down, and OpenClaw might time out. Compiling LLMs and running inference will hit this within minutes. Requirement: You must use a heatsink and fan. Check your temp with vcgencmd measure_temp.

1.3 Tuning the OS

Once logged in via SSH, optimize the memory and clock speed:

sudo apt update && sudo apt upgrade -y
# Increase Swap to 4GB to handle model spikes
sudo dphys-swapfile swapoff
sudo sed -i 's/CONF_SWAPSIZE=100/CONF_SWAPSIZE=4096/' /etc/dphys-swapfile
sudo dphys-swapfile setup
sudo dphys-swapfile swapon

Phase 2: Compiling the Edge Brain (llama-cpp-turboquant)

Standard LLM engines eat too much RAM. We are going to build a specialized version of llama.cpp that uses TurboQuant KV Cache compression. This allows Gemma 4 to handle long conversations without crashing the Pi.

First, we need the tools to build the software. We will also install libssl-dev to prevent any OpenSSL errors during the build process, and libopenblas-dev for fast matrix math.

Standard llama.cpp builds might not have the specific cache compression flags we need. We will pull from a community fork and check out the exact branch where KV cache compression is being actively developed.

The Raspberry Pi 4 uses a Cortex-A72 chip (ARMv8). The flag -DGGML_NEON=ON is absolutely essential here—it tells the compiler to use the Pi's SIMD (Single Instruction, Multiple Data) instructions, which acts as the primary hardware accelerator for our math operations.

(Note: Don't use newer flags like ARM_KLEIDIAI; those are for ARMv9 and won't help you here).

2.1 Build from Source

# Install dependencies
sudo apt install -y git cmake build-essential libopenblas-dev libssl-dev

# Clone the TurboQuant-specific branch
git clone https://github.com/TheTom/llama-cpp-turboquant
cd llama-cpp-turboquant
git checkout feature/turboquant-kv-cache

# Configure for Pi 4 (Cortex-A72 / NEON acceleration)
cmake -B build \
  -DCMAKE_BUILD_TYPE=Release \
  -DGGML_CPU=ON \
  -DGGML_NATIVE=ON \
  -DGGML_OPENBLAS=ON \
  -DGGML_NEON=ON \
  -DLLAMA_OPENSSL=ON

# Compile (This takes ~15 mins)
cmake --build build --config Release -j4

Key Considerations for Raspberry Pi 4

NEON Acceleration: The -DGGML_NEON=ON flag is essential for the Pi 4 to utilize its SIMD instructions for faster math. This is the primary hardware accelerator for ARMv8 chips like the one in the Raspberry Pi 4. Newer flags like ARM_KLEIDIAI target ARMv9 and won't benefit your hardware.
KV Cache Savings: TurboQuant's primary benefit on a Pi 4 (especially 4GB models) is reducing the memory footprint of the KV cache, allowing you to use longer contexts without hitting swap.
Wait for Compile: Building on a Pi 4 can take 10–20 minutes. Ensure you have adequate cooling, as all 4 cores will be at 100% load.
TurboQuant Branch: git checkout feature/turboquant-kv-cache: This is the active development branch where the --cache-type-k and --cache-type-v flags are implemented.
TurboQuant Flags: Once built, you can run your model with -ctk turbo4 -ctv turbo4 to significantly reduce RAM usage during long conversations.

Take a break. Compiling on all 4 cores will push your Pi to 100% CPU load and can take 10 to 20 minutes. Ensure your Pi has decent cooling (a small fan or heatsink).

Once finished, verify that the new cache types exist:

./build/bin/llama-cli --help | grep cache-type

If you see turbo4 listed in the output, congratulations! Your edge engine is ready.

Phase 3: Sourcing the Brain (Gemma 4 Q4_K_M)

Next, we need the actual model weights. We will use the gemma-4-E2B-it-GGUF model.

A Quick Lesson on Quantization (Why we use Q4_K_M + TurboQuant)

Before you download, it is crucial to understand the two different types of "shrinking" we are doing to make this fit on a Pi:

Weight Quantization (Q4_K_M.gguf): This compresses the model's permanent weights (its long-term memory). The file you download is already shrunk from 16-bit to roughly 4-bit. This is what allows a multi-billion parameter model to sit comfortably on your SD card or SSD.
KV Cache Quantization (TurboQuant): This compresses the model's short-term memory (the scratchpad it uses while you are chatting). TurboQuant isn't a file you download; it’s an active efficiency mode you toggle on when running the server to stop RAM usage from ballooning as context grows.

Option 1: Install via OpenSSL Development Headers (ODHs)

Run this in your llama-cpp-turboquant directory:

./build/bin/llama-cli -hf unsloth/gemma-4-E2B-it-GGUF:Q4_K_M

Option 2: Download the Model Manually

Alternatively, to avoid messing with Python scripts or SSL library issues, let's just grab the file directly via the terminal using wget (or curl).

wget https://huggingface.co/unsloth/gemma-4-E2B-it-GGUF/resolve/main/gemma-4-E2B-it-Q4_K_M.gguf -O models/gemma-4-E2B-it-Q4_K_M.gguf

curl -L https://huggingface.co/unsloth/Qwen3.5-0.8B-GGUF/resolve/main/Qwen3.5-0.8B-Q4_K_S.gguf -o models/Qwen3.5-0.8B-Q4_K_S.gguf

(If you prefer Qwen3.5 as a lighter alternative, you can swap the URL for a Qwen 0.8B GGUF file, but Gemma 4 E2B is specifically tuned for agentic tasks).

The Local Test Run

Before hooking this up to OpenClaw, let's test it in the command line using llama-cli. We will pass in all our optimization flags. Either via

ODHs

./build/bin/llama-cli -hf unsloth/gemma-4-E2B-it-GGUF:Q4_K_M \
  -t 4 \
  -c 4096 \
  -b 128 \
  --temp 0.1 \
  --chat-template-kwargs '{"enable_thinking":false}' \
  --cache-type-k turbo4 \
  --cache-type-v turbo4 \
  -fa \
  -sys "You are a Stoic logic engine. Be concise." \
  -cnv --color auto

Manual

./build/bin/llama-cli -m models/gemma-4-E2B-it-Q4_K_M.gguf \
  -t 4 \
  -c 4096 \
  -b 128 \
  --temp 0.1 \
  --cache-type-k turbo4 \
  --cache-type-v turbo4 \
  -fa \
  -sys "You are an autonomous agent operating under the KheAi Protocol. Be concise." \
  -cnv --color auto

./build/bin/llama-cli -m models/Qwen3.5-0.8B-Q4_K_S.gguf \
  -t 4 \
  -c 4096 \
  -b 128 \
  --temp 0.1 \
  --reasoning-budget 0 \
  --cache-type-k turbo4 \
  --cache-type-v turbo4 \
  -fa \
  -sys "Be concise." \
  -cnv --color auto

Let’s break down the magic flags:

-t 4: Uses all 4 CPU threads.
-c 4096: Gives the model a 4K context window (plenty for agent logs). Below 1,000 tokens, TurboQuant's memory savings are negligible. The 4K mark is exactly where compressing the KV cache to 4-bits starts to dramatically save RAM, keeping the Node.js OpenClaw process and the OS from fighting over the Pi's 8GB limit.
--cache-type-k turbo4 & --cache-type-v turbo4: This is TurboQuant in action! It compresses the Keys and Values in the cache to 4-bit polar coordinates.
-fa on (Flash Attention): Crucial. TurboQuant requires Flash Attention to be enabled to function correctly with the compressed blocks.
--reasoning-budget 0: Forces the model to skip lengthy internal monologues and looping, outputting direct, actionable responses.

Spinning up the Server for OpenClaw

OpenClaw needs an API to talk to. We will launch llama-server to act as an OpenAI-compatible backend, hosted directly on your Pi.

./build/bin/llama-server \
  -m models/gemma-4-E2B-it-Q4_K_M.gguf \
  --port 8080 \
  -t 4 \
  -c 4096 \
  -b 128 \
  --cache-type-k turbo4 \
  --cache-type-v turbo4 \
  -fa \
  --api-key "local-pi-key" \
  --host 0.0.0.0

Your Raspberry Pi is now acting as a dedicated, local AI server. It is listening on port 8080 and is accessible from any machine on your local network.

Phase 4: The OpenClaw Setup & Onboarding (The Hands)

OpenClaw is a Node.js-based autonomous framework. We will use the official one-liner but then manually "onboard" it to our local brain.

4.1 Installation

curl -fsSL https://openclaw.ai/install.sh | bash

4.2 The Onboarding Wizard (Crucial Step)

This is where we connect the framework to our Pi's local server. Run:

openclaw onboard

Follow these specific inputs for local autonomy:

Provider: Select OpenAI Compatible (Since llama-server mimics this).
API Key: Enter local-pi-key (or anything, it’s local).
Base URL: http://127.0.0.1:8080/v1
Model: gemma-4-E2B-it-Q4_K_M
Tools: Enable Terminal and Filesystem.
Sandbox: Since we are using Gemma 4 E2B, you should ideally provide an E2B.dev API key if you want the agent to execute code in a secure, cloud-hosted sandbox. If you want it 100% local, select Local Terminal.

Phase 5: Activating the KheAi Protocol (The Soul)

We don't want a generic assistant. We want a systemic autonomous agent. We achieve this by overriding the OpenClaw "Persona."

Navigate to your OpenClaw config directory: cd ~/.openclaw
Create/Edit your system prompt: nano SOUL.md.
Paste the KheAi Protocol Architecture:

   ## KheAi Protocol v1.0

   **Core Identity:** You are a Systemic Autonomy Agent.

   **Operational Framework (OODA):** > - **Observe:** Scan the local environment/files.

   - **Orient:** Check Pi resource constraints (RAM/Temp).
   - **Decide:** Choose the tool that uses the least energy.
   - **Act:** Execute and verify.

   **Constraint:** You are running on a Raspberry Pi 4. Be concise. Do not loop. Use TurboQuant awareness for long contexts.

Without the KheAi OODA (Observe, Orient, Decide, Act) constraint, a generic model might hallucinate tools or try to write long-winded python scripts. The protocol forces it to act like a machine, not a chatbot.

Phase 6: Launching the System Again

You need two terminal windows (or use tmux).

Terminal 1: The Brain (Server)

Start the model with the TurboQuant flags to compress the memory:

./build/bin/llama-server \
  -m models/gemma-4-E2B-it-Q4_K_M.gguf \
  --port 8080 \
  -t 4 \
  -c 4096 \
  --cache-type-k turbo4 \
  --cache-type-v turbo4 \
  --reasoning-budget 0 \
  -fa

Note: --cache-type-k turbo4 shrinks the "short-term memory" by 4x so you don't run out of 8GB RAM.

Terminal 2: The Framework (OpenClaw)

openclaw start

Phase 7: Remote Access with Tailscale

Once your Raspberry Pi is running an autonomous agent, you don’t want it tied to a monitor and keyboard on your desk. You want it running "headless" (plugged into power and network only) in a closet or next to your router.

However, exposing your local Pi to the public internet via port forwarding is a massive security risk. Instead, we will use Tailscale to create a Zero Trust Mesh Network. This creates a secure, private tunnel between your laptop/phone and your Pi, allowing you to SSH into it or access OpenClaw from a coffee shop halfway across the world.

7.1 Installation

Run this simple one-liner on your Pi to download and install Tailscale:

curl -fsSL https://tailscale.com/install.sh | sh

7.2 Activation & Authentication

Once installed, bring the network interface up:

sudo tailscale up

This command will output a URL. Copy and paste that URL into a browser on your main computer to authenticate the Pi with your Tailscale account (it's free for personal use).

Run tailscale ip -4 to get your Pi’s new secure IP address. You can now securely SSH into your Pi (ssh pi@[tailscale-ip]) or access your agent dashboards remotely without opening a single port on your home router.

Phase 8: Hybrid Cloud-Edge (Switching to the Gemini API)

Running everything locally on a Pi is an incredible achievement for privacy and independence. But what if your agent encounters a task that requires massive reasoning power, deep web research, or complex code generation that Gemma 4 Q4_K_M struggles with?

This is where a Hybrid Architecture shines. You use the local edge model as your primary driver for simple, continuous tasks, and switch to a frontier cloud model like the Gemini API for the "heavy lifting."

The Strategy: Local for Actions, Gemini for Deep Reasoning

Primary (Local Gemma 4): Use this for file scanning, basic terminal commands, navigating the OS, and formatting data. It is free, private, and fast enough for OODA loop execution.
Fallback/Heavy Lifting (Gemini API): Route tasks here when the agent needs to write complex Python scripts, analyze large datasets, or process visual information.

8.1 Getting the Gemini API Key

Go to Google AI Studio and sign in.
Click Get API Key and generate a new key. Keep this secure.

8.2 Re-configuring OpenClaw

To switch your agent's brain over to Gemini, you simply need to run the onboarding wizard again (or edit your OpenClaw config file directly).

openclaw onboard

Follow these inputs for the Cloud-Heavy setup:

Provider: Select Google or Gemini (depending on your OpenClaw version).
API Key: Paste your Gemini API key.
Model: Select gemini-2.5-pro (for maximum reasoning and coding capabilities) or gemini-2.5-flash (for high speed and lower cost).
Tools & Sandbox: Keep these the same as Phase 4.

By swapping the provider, your agent instantly upgrades its cognitive capabilities while still utilizing the Pi as its physical "body" to execute terminal commands and interact with the local environment.

Wrapping Up

Building an autonomous agent entirely at the edge used to require expensive gaming laptops. By combining the affordability of a Raspberry Pi 4, the tailored intelligence of Gemma 4 E2B, and the incredible memory-saving techniques of TurboQuant, you now have a self-contained AI brain sitting on your desk.

It takes patience to compile and tune, but once that server says "HTTP server listening," the feeling of having a localized, private, and fully autonomous intelligence under your control is unmatched.

Team Submissions: @kheai @yeemun122

AI-Powered ERP System with Gemma 26B MoE

Khe Ai — Fri, 08 May 2026 18:49:02 +0000

This is a submission for the Gemma 4 Challenge: Build with Gemma 4

What I Built

Don’t just track your equipment—troubleshoot it.

I built the Y&Y App: an industrial-grade, microservices-based SaaS that merges live ERP inventory management with a state-of-the-art AI Domain-Expert Agent.

The Problem: Factory floors and industrial sites suffer from massive financial losses during equipment downtime. When machinery fails, junior engineers often waste critical hours digging through dense, hundreds-of-pages-long OEM manuals to diagnose obscure faults.

The Solution: I engineered a system where a user can view their live inventory and literally ask the system, "Why is PUMP-CENT-001 making a crackling noise like gravel?" The app uses a highly structured Retrieval-Augmented Generation (RAG) pipeline to instantly retrieve the exact manufacturer manual excerpt and synthesize an accurate, safe resolution.

By separating concerns into a strict microservices architecture—.NET 8 for the ERP business logic, Python (FastAPI) for the AI brain, and React for the UI—I've created an enterprise-ready blueprint that is scalable, maintainable, and blazingly fast.

Demo

Live Web App: Play with the Y&Y App on Vercel

Video Walkthrough

Pure Gemini API

Vertex AI

Code

kheAI / yny-app

🏗️ Y&Y App – AI-Powered Industrial ERP

An industrial-grade, microservices-based SaaS that combines live ERP inventory management with a state-of-the-art AI Domain-Expert Agent capable of diagnosing machinery issues in real-time.

Building monolithic apps is a thing of the past. Y&Y App showcases a robust, strictly decoupled Microservices Architecture, separating enterprise business logic (inventory) from complex AI workflows (Retrieval-Augmented Generation), all unified under a blazing-fast React frontend.

✨ The Elevator Pitch

Don't just track your equipment—troubleshoot it. Y&Y App uses a Retrieval-Augmented Generation (RAG) pipeline powered by Google's Gemini APIs and PostgreSQL pgvector. When a user reports a strange noise from a pump, the AI doesn't guess; it performs a vector similarity search to retrieve the exact manufacturer maintenance manual and synthesizes a safe, factual resolution.

🚀 Key Features

Microservices Architecture: Independent scaling for UI, ERP, and AI logic.
Enterprise-Grade ERP API: Built with .NET 8 Minimal…

View on GitHub

How I Used Gemma 4

To make this industrial AI reliable and fast, I built a custom Retrieval-Augmented Generation (RAG) pipeline powered by Gemma 4.

Here is exactly how I integrated the models into my Python microservice:

1. The Brain: gemma-4-26b-a4b-it
I chose the Gemma 4 26B MoE (Mixture-of-Experts) model for the core reasoning engine. In industrial environments, precision and speed are non-negotiable. If a centrifugal pump is cavitating, an engineer needs the remediation steps immediately before catastrophic failure occurs.

Because gemma-4-26b-a4b-it utilizes an MoE architecture, it provides the deep intelligence and reasoning capabilities of a massive 26-billion parameter model, but achieves ultra-low latency by only activating a fraction of its parameters (~4B) during inference. This was the absolute perfect fit for a real-time conversational agent where users are waiting on the UI for critical answers.

2. The Memory: gemini-embedding-001 and PostgreSQL pgvector
To prevent hallucinations—which are dangerous in industrial maintenance—the AI is strictly grounded in actual equipment manuals.

When a user asks a question, my Python FastAPI service uses the gemini-embedding-001 model to turn the text into a 768-dimensional mathematical vector.
I then run a Cosine Distance (<=>) SQL query against my Google Cloud SQL PostgreSQL database (using the pgvector extension) to find the most mathematically similar equipment manual chunk.
Finally, that strict context is passed via prompt engineering to the Gemma 4 model, instructing it to act as an expert industrial maintenance AI and synthesize an answer only using the provided manual.

The Result: A lightning-fast, highly intelligent, hallucination-free AI assistant that turns an overwhelming physical manual into an interactive, real-time problem solver.

Demo Script

If you are showcasing this project to stakeholders, here is the exact narrative flow I recommend:

Show the Live Dashboard: "This is the Y&Y SaaS Dashboard. The top section is our .NET 8 ERP pulling live operational data directly from a PostgreSQL instance." Point out the real-time stock levels, specifically the out-of-stock valve.
Setup the Incident: "Imagine a junior engineer is on the factory floor and hears a strange crackling noise coming from PUMP-CENT-001."
Execute the Prompt: Type: "Why is the pump making a crackling noise like gravel and what should I do?" into the AI input and hit Consult AI.
Explain the Magic: "Right now, our Python microservice is converting my question into a mathematical vector. It's querying the pgvector database via Cosine Distance to retrieve the exact manufacturer maintenance manual excerpt, and passing that strict context to Google's Gemma model to synthesize a safe resolution."
The Resolution: The AI will output a clean, professional answer based strictly on the manual we seeded (diagnosing cavitation and advising them to throttle the valve).

Team Submissions: @kheai @yeemun122

Blaze 3 Unofficial Simple Todos Tutorial with Meteor 3.4.1 + Rspack + PicoCSS

Khe Ai — Fri, 08 May 2026 12:02:03 +0000

Welcome! In this tutorial, we will create a simple To-Do app using Blaze and Meteor 3.4.1.

Blaze is Meteor's original, deeply integrated UI framework. It uses an easy-to-learn, Handlebars-like template syntax. Compared to traditional tools, Blaze eliminates the need to manually update the DOM when your database changes. Instead, it integrates directly with Meteor's transparent reactivity. Change a document in your database, and the UI updates instantly.

With Meteor, a single developer can build a fully functional, real-time app in the time it takes a team of architects to decide on their communication protocols. Let's start building.

PS: Tutorial originally adapted from the official Meteor Blaze Guide.

Github Repo:

kheAI / todos-app

📝 Simple Todos (Meteor 3 + Blaze)

A reactive, full-stack To-Do application built to demonstrate the power and speed of Meteor 3.4.1 using its native Blaze templating engine.

This project showcases modern Meteor features including Rspack for lightning-fast bundling, fully asynchronous database operations (Async/Await), user authentication, and Optimistic UI.

🚀 Live Demo

Play with the live app here! (Deployed via Meteor Galaxy)

✨ Features

Real-time Reactivity: Changes in the database are instantly reflected in the UI without manual DOM manipulation.
Optimistic UI: When a user checks or deletes a task, the UI updates instantly (zero latency) while the server processes the request securely in the background.
User Authentication: Built-in secure login system using accounts-password and bcrypt.
Data Security: Strict data-flow control using Meteor Publications/Subscriptions and secure Remote Procedure Calls (Meteor Methods).
State Management: Client-side state filtering (hiding completed tasks) managed via reactive-dict.
Semantic Styling: Zero-config, responsive…

View on GitHub

Updated Full step-by-step Tutorial had been moved to https://www.kheai.com/posts/6001-meteor-todo-tutorial-unofficial/

Conclusion

You have just built a reactive, full-stack application with a real database, user authentication, and secure remote procedure calls. What you've learned here applies to applications of massive scale. Welcome to the Meteor ecosystem!

HuntOS: The Autonomous Enterprise Sentinel — A Production-Grade Agentic Swarm on the Next '26 Stack

Khe Ai — Sun, 26 Apr 2026 17:16:09 +0000

This is a submission for the Google Cloud NEXT Writing Challenge

What I Built

The era of vibe-coding fragile chatbot prototypes is over. Thanks to extensive research into the announcements at Google Cloud Next '26, I have combined the most impactful platform updates into one cohesive architecture. This project demonstrates the full Agentic Enterprise stack in action—systems that don't just chat, but take verified, physical business actions.

To pressure-test this new stack, I built HuntOS: an autonomous, cross-cloud security swarm.

HuntOS is an Agent-to-Agent (A2A) workforce designed to hunt anomalies across disconnected environments. It ingests messy unstructured "dark data" (like AWS S3 logs), cross-references anomalies against a secure Spanner Graph, and orchestrates a swarm of Gemini 3.1 Pro agents to draft, critique, and deploy Terraform remediation scripts. All with zero human intervention and enterprise-grade egress security.

The Next '26 Equation:
(Cross-Cloud Lakehouse × Knowledge Catalog) + MCP Server + (A2A Swarm @ TPU v8i) + (Agent Gateway + Model Armor) + Vertex AI Memory Bank = Production-Ready Agentic OS

💡 For the Enterprise CISO: Currently, remediating a cross-cloud leak takes hours of human investigation, Jira tickets, and manual Terraform patching. HuntOS reduces Time-To-Remediate (TTR) from hours to under 3 seconds—without requiring you to move your raw AWS logs into Google Cloud, and without exposing your database credentials directly to an LLM.

Demo & Code

Source Code:

kheAI / huntos

HuntOS: The Autonomous Enterprise Sentinel

HuntOS is an autonomous, cross-cloud security swarm built to demonstrate the full Agentic Enterprise stack announced at Google Cloud Next '26.

It transitions from simple "fragile chatbot prototypes" to "Agentic AI" by detecting anomalies in "dark data" (messy AWS S3 logs), verifying them via a secure Spanner Graph, and orchestrating a swarm of Gemini 3.1 Pro agents to draft, critique, and deploy Terraform remediation scripts. All with zero human intervention and enterprise-grade egress security.

The Next '26 Mega-Product Equation (Cross-Cloud Lakehouse × Knowledge Catalog) + MCP Server + (A2A Swarm @ TPU v8i) + (Agent Gateway + Model Armor) + Vertex AI Memory Bank = Production-Ready Agentic OS

🚦 Architectural Breakdown Matrix

System Requirement	Next '26 Execution Method	Primary Technology	Function (The Sentinel Value)
Data Gravity / Ingestion	Cross-Cloud Connectivity	Cross-Cloud Lakehouse & Knowledge Catalog	Indexes unstructured "dark data" (PDFs/Logs) in-place across AWS and GCP

…

View on GitHub

The Architecture: Reversing the Prototype Trap

To win in modern infrastructure, you have to architect for the system, not just the AI. AI cannot verify your identity or configure cross-cloud IAM roles. You must lay the physical groundwork first.

Here is the architectural breakdown of how I wired the Next '26 stack together:

1. Conquering Data Gravity: Cross-Cloud Lakehouse

The biggest friction in enterprise AI is moving data. Instead of paying massive egress fees to pull AWS S3 security logs into GCP, HuntOS utilizes the new Cross-Cloud Lakehouse. By leveraging Cross-Cloud Interconnect (CCI) combined with bi-directional federation via the Apache Iceberg REST Catalog, the system indexes the logs in place.

The Vertex AI Knowledge Catalog sits on top, allowing our agents to read these "dark data" PDFs as if they were local, low-latency files.

2. Zero-Trust Data Access: The MCP Bridge

AI agents need database access to verify threats, but handing raw SQL credentials to an LLM is a massive security risk. HuntOS implements the breakout open-source standard: the Model Context Protocol (MCP).

I deployed an MCP bridge pointing to a newly provisioned Spanner Graph database (hunter-os-db). This creates a secure, abstracted interface so the agent can query the blast radius between flagged anomalies and impacted microservices without ever seeing the raw schema or connection strings.

3. The Autonomous Swarm & The "Skeptic Loop"

The core logic was generated using Google AI Studio leveraging the new A2A Protocol. HuntOS is not one monolithic prompt; it is a delegated hierarchy:

Manager Agent: Flags the AWS log anomaly using the Knowledge Catalog tool.
Researcher Agent: Queries the Spanner Graph via MCP to map the blast radius.
Architect Agent: Drafts the raw Terraform remediation script.
Red Team "Skeptic" Agent: A dedicated critique loop. Before finalizing code, this agent aggressively scans the Architect's output to eliminate hallucinations and fix downtime risks.

Here is a look under the hood at how the Skeptic Loop enforces code safety in my Next.js API route:

// 1. Architect drafts the raw Terraform based on Spanner Graph verification
const architectPrompt = `Context: ${JSON.stringify(verification)} Draft Terraform remediation.`;
const draft = await ai.models.generateContent({
    model: 'gemini-3.1-pro',
    contents: architectPrompt
});

// 2. The Skeptic Loop - Red Team critiques for downtime risks before returning
const skepticPrompt = `Critique this Terraform for production downtime risks or race conditions. Rewrite safely: ${draft.text}`;
const finalRevision = await ai.models.generateContent({
    model: 'gemini-3.1-pro',
    contents: skepticPrompt
});

return finalRevision.text; // Only the verified code is passed to the Gateway

4. Institutional Memory via Semantic Grounding

To ensure the Architect Agent doesn't write generic, tutorial-level code, I grounded the swarm using the Vertex AI Memory Bank.

Memory Bank doesn't just act as a static file drive. It utilizes an LLM-driven background process to extract, compress, and consolidate facts into a long-term knowledge graph. By uploading my company's official security guidelines alongside my own GitHub repositories, the agent uses semantic search to retrieve my specific "Pragmatic Developer" preferences. It writes like me, preventing context-window bloat.

5. Hardware & Edge Egress Security

To execute sub-100ms reasoning loops for the "Red Team" simulations, the swarm is routed through the TPU v8i architecture running on highly-optimized Google Axion Arm-based CPUs.

Finally, transition to production requires strict perimeter security. I wrapped the Cloud Run deployment in an Agent Gateway, configured with a strict Egress Model Armor template. For an autonomous swarm executing live Terraform patches, strictly defining the Agent-to-Anywhere (Egress) guardrails is the ultimate safeguard. It sanitizes all outbound code, blocks prompt injections, and mathematically ensures no internal API keys are leaked during execution.

Overcoming Engineering Challenges

Building a genuinely autonomous system revealed a few hurdles:

The "Infinite Loop" Threat: Initially, A2A agents can get stuck endlessly debating a fix. Implementing strict token budgets and a definitive "Architect vs. Skeptic" hierarchy was necessary.
Resilient Infrastructure: Since MCP client connections to gcloud rely on local environment credentials, I had to architect graceful fallbacks in the Next.js route.ts. This ensures the dashboard remains highly available even if the backend MCP proxy temporarily disconnects.
React Hydration: Handling real-time agent telemetry in Next.js required careful useEffect management to prevent React hydration mismatches caused by split-second timestamp differences between the server and the browser.

Architectural Breakdown Matrix

For a quick reference of the Next '26 tools utilized in this build:

System Requirement	Next '26 Solution	Function (The Sentinel Value)
Data Gravity	Cross-Cloud Lakehouse	Indexes unstructured dark data (PDFs/Logs) in-place across AWS and GCP without costly data egress.
Secure Data Access	MCP Server	Abstracted interface for agents to query live databases without exposing raw credentials.
Relational Intelligence	Spanner Graph (GQL)	Maps complex relationships between anomalies and system dependencies to identify root causes.
Agent Swarm Logic	A2A Protocol	Orchestrates handoffs between specialized agents (Researcher → Architect → Skeptic).
Inference & Speed	TPU v8i (Boardfly)	Powers sub-100ms reasoning loops, allowing the Skeptic agent to run without stalling the pipeline.
Code Sanitization	Gateway & Model Armor	Automated egress filter to sanitize LLM-generated code and block prompt injections.
Visual Architecture	Nano Banana 2	Enables the Architect to output Mermaid.js/PlantUML for executive-facing conceptual diagrams.
Institutional Memory	Vertex AI Memory Bank	Enforces corporate security standards and brand voice by grounding outputs in past successful patches.

The Payoff: Why This Matters

For this challenge, I wanted to showcase depth, usefulness, and genuine insight into where Cloud is heading.

We are no longer just wrapping LLMs in simple chat interfaces. By leaning entirely into the physical infrastructure and security announcements of Next '26—especially MCP, Spanner Graph, and Model Armor—HuntOS proves that the Agentic Enterprise isn't just a concept. It is ready to deploy today.

Automated Intelligence Dev Bounty Scouter with OpenClaw, Gemini & SearXNG in RPi

Khe Ai — Wed, 22 Apr 2026 08:26:26 +0000

This is a submission for the OpenClaw Challenge.

What I Built

Following up on my previous exploration in Self-Healing Dev Bounty Hunter with OpenClaw, I realized that total AI autonomy can sometimes be a trap. If you let an agent run completely unchecked, you end up hoarding garbage data.

To solve this, I expanded the architecture into an Automated Intelligence Dev Bounty Scouter.

KheAi's Dev Bounty Scouter is an automated, lightweight aggregator designed specifically for solo developers. It discovers remote, short-term, cash-prize coding competitions, open-source grants, and hackathons. To be clear: this isn't for bug bounty hunters looking for security exploits; it is built for creative makers seeking low-competition, high-reward opportunities.

At its core, it relies on a "Digital Hermit" workflow—a hybrid architecture balancing edge computing (Raspberry Pi) and serverless cloud infrastructure:

The Edge Worker (RPi 4B): Runs OpenClaw as a background daemon alongside a localized SearXNG instance, powered by Gemini 3.1 Flash-Lite. It scrapes, parses, and writes to a local JSONL file.
The Cloud Vault (Cloud Run + Meteor): A curated dashboard backed by MongoDB Atlas (M0 Free Tier) utilizing Vector Search.
The Human-in-the-Loop: Before any data touches the cloud vault, I personally review the Pi's local JSONL output, acting as the ultimate anti-fragile quality assurance layer.

How I Used OpenClaw

OpenClaw is the central orchestrator of this system, but using it on a resource-constrained device like a Raspberry Pi 4B against strict API rate limits required some heavy engineering.

1. Taming OpenClaw with a "State Machine" Prompt

Gemini 3.1 Flash-Lite is incredibly efficient, but its free tier has a strict Rate Limit (15 RPM). OpenClaw’s default reasoning loops (Thought/Action/Observation) can easily chew through 15 requests in seconds if the agent hits a roadblock or retry loop.

To prevent 429 Too Many Requests errors, I built a custom local skill (skills/kheai-scout/skill.md) that acts as a "God Prompt." I forced OpenClaw to operate strictly as a State Machine. By batching its thoughts and locking its execution order, the agent minimizes API round-trips:

# EXECUTION PROTOCOL (Strict State Machine)
Trigger: When commanded to "Run Kheai Scout". You must execute the following states in exact order. 

## STATE 1: [MEMORY SYNCHRONIZATION]
- Read `~/.openclaw/workspace/scout_findings.jsonl` to memorize existing URLs and prevent duplicates.

## STATE 2: [QUERY GENERATION & EXECUTION]
- Execute exactly 3 highly specific, niche search queries (e.g., "indie developer bounty", "open source grant application") using the SearXNG tool. 

## STATE 3: [SKEPTICAL ANALYSIS]
- Filter out news aggregators, press releases, or student-only hackathons. 

## STATE 4: [DATA STRUCTURING & APPENDING]
- Format surviving challenges as strict, single-line JSON objects.
- APPEND to `scout_findings.jsonl`.

2. Bypassing Search Limits with SearXNG

To give OpenClaw web-searching capabilities without racking up Google/Bing API bills, I deployed SearXNG locally via Docker on the Pi. I configured OpenClaw's Search Tool to point directly to http://localhost:8080.

I had to explicitly enable the - json format in SearXNG's settings.yml so OpenClaw could seamlessly parse the payloads.

3. The Human-to-Cloud Handoff

Every morning at 04:00 AM, a cronjob triggers OpenClaw. By 09:00 AM, I review scout_findings.jsonl. I click the links, assess the "vibes" and Terms & Conditions, and if the bounty is high-value, I manually log it into my Meteor-Blaze app hosted on Google Cloud Run.

Upon saving, the Meteor app calls a cloud-based embedding model (Gemini Embedding 1, outputting 768 dimensions) to generate vector embeddings for the bounty's tech stack and strategy notes, saving it directly to MongoDB Atlas.

PS: The Step-by-Step Implementation Tutorial Guide: Zero to Hero (includes the full God Prompt) is available at the bottom.

Demo

(In the demo, you can see OpenClaw executing its state-machine logic, querying the local SearXNG instance and formatting the extracted hackathons into the local JSONL.)

What I Learned

Building an AI workflow isn't just about stringing APIs together; it's about anticipating failure points. Here are my biggest takeaways:

Rate Limits Dictate Architecture: You can't just tell an agent to "go find bounties." Without the State Machine prompt architecture, OpenClaw would accidentally DDOS my own local SearXNG instance or crash into Gemini's 15 RPM wall.
Protect Your Home IP: Running an automated search scraper from a home IP in Malaysia triggered Google CAPTCHAs within days. I learned I had to explicitly enable the limiter plugin in SearXNG (backed by Redis) and configure outbound proxy pools to throttle requests and protect my network.
$0/Month Cloud Stacks are Viable (with caveats): Google Cloud Run (1GB RAM, Session Affinity enabled for Meteor WebSockets) paired with MongoDB Atlas M0 is a powerhouse. However, M0 clusters limit you to 512MB storage and 3 vector indexes, and cause a 5-10 second cold start delay on the first load of the day. For a solo dev tool, this trade-off is absolutely worth the $0 price tag.
Total Automation is a Trap: The biggest lesson was accepting that AI shouldn't do 100% of the work. By letting OpenClaw handle the unstructured chaos of the web and forcing myself to be the final curator, I ensure my database remains a pristine, high-signal vault of opportunity.

Step-by-Step Implementation: Zero to Hero

If you want to build this yourself, here is the exact workflow to set up your own autonomous bounty scouter.

Phase 1: The Local Engine Room (Raspberry Pi 4B)

We need to set up SearXNG and OpenClaw on your Pi securely, ensuring they don't corrupt your SSD or drain your RAM.

Step 1.1: Deploying SearXNG (The Right Way)

By running SearXNG via Docker, you completely bypass the API costs and rate limits of Google or Bing search APIs.

Instead of a fragile one-line Docker command, use docker compose to ensure it restarts on Pi reboots and allows easy configuration file mapping.

Create a directory: mkdir -p ~/kheai-scout/searxng && cd ~/kheai-scout/searxng
Create a docker-compose.yml:

   services:
     searxng:
       image: searxng/searxng:latest
       container_name: searxng
       ports:
         - "8080:8080"
       volumes:
         - ./searxng-data:/etc/searxng
       environment:
         - SEARXNG_BASE_URL=http://localhost:8080/
         - SEARXNG_SECRET_KEY=generate_a_random_string_here
       restart: unless-stopped

You don't need to download the SEARXNG_SECRET_KEY key from anywhere—you literally just need to create a random string of characters! SearXNG uses this secret key to encrypt session cookies and keep your instance secure.

Run docker compose up -d. This creates the ./searxng-data folder.
The Critical JSON Fix: Open ./searxng-data/settings.yml (via sudo nano. Find the search.formats section and ensure - json is explicitly listed. Restart the container: docker compose restart.

Step 1.2: OpenClaw Initialization

Ensure your OpenClaw environment is pointed to Gemini and SearXNG.

Set your environment variable: export GEMINI_API_KEY="your_api_key"
In OpenClaw's configuration, define your Search Tool to use http://localhost:8080 (or 127.0.0.1:8080) so the agent queries your private instance, not the public web.

Phase 2: The Master Skill (The God Prompt)

OpenClaw interprets complex prompts best when they are structured as a State Machine. This prevents the agent from rushing to write data before checking existing files. Copy and paste to tell OpenClaw to create a new skill as /kheai-scout/SKILL.md:

I want to add a new local skill. Please create a directory named skills/kheai-scout and save the following instructions into a file named skill.md inside it. Then, initialize the JSONL file mentioned in the prompt.

# SYSTEM OVERVIEW
You are the "KheAi Global Scout," an elite, highly skeptical threat-intelligence agent specializing in developer bounties, hackathons, and open-source grants. Your runtime is a resource-constrained Raspberry Pi relying on a strictly rate-limited API (max 15 requests per minute). 

You MUST act methodically, preserve memory, minimize API round-trips by batching your thoughts, and absolutely avoid hallucination.

# CRITICAL CONSTRAINTS (MANDATORY)
1. RATE LIMIT DEFENSE: You must combine your reasoning (Thoughts) and Tool Actions into as few steps as possible. Do not get stuck in retry loops.
2. NO HALLUCINATION: If a deadline, prize pool, or platform is not explicitly stated in the search snippets, map the value to "Unknown". Do not guess or infer dates.
3. STRICT JSONL OUTPUT: When appending data, you must use valid JSON objects on a single line. DO NOT use CSV format.
4. DEDUPLICATION: You MUST read the existing local database BEFORE searching to memorize existing URLs. You must never log a URL that is already in the database.
5. SKEPTICISM: Ignore news articles, blog posts, and press releases. Only log actual application pages, official hackathon platforms, or direct grant portals.

# EXECUTION PROTOCOL (Strict State Machine)
Trigger: When commanded to "Run Kheai Scout". You must execute the following states in exact order. 

## STATE 1: [MEMORY SYNCHRONIZATION]
- Action: Use your file-reading tool to read `~/.openclaw/workspace/scout_findings.jsonl`.
- Goal: Extract and memorize the `URL` fields of all previously discovered challenges. If the file is empty or missing, proceed with an empty memory. 

## STATE 2: [QUERY GENERATION & EXECUTION]
- Action: Select exactly 3 highly specific, niche search queries from the approved concepts below:
  - "indie developer bounty"
  - "open source grant application"
  - "online dev challenges"
  - "new hackathon platforms"
  - "active developer bounties"
  - "web3 grant programs"
- Action: Execute these 3 queries simultaneously or sequentially using the `web_search` (SearXNG) tool. 

## STATE 3: [SKEPTICAL ANALYSIS]
- Action: Review the search snippets. 
- Filter out and set "Unknown" status:
  - Any URL that matches a URL memorized in STATE 1.
  - Any URL pointing to a news aggregator, blog, or press release.
  - Any challenge that explicitly states it is restricted to high school students or non-developers.

## STATE 4: [DATA STRUCTURING & APPENDING]
- Action: For each surviving, verified challenge, format the data EXACTLY as a single-line JSON object. CRITICAL: You must properly escape any internal double quotes within the JSON values (e.g., use \" ) to ensure the JSONL string remains strictly valid.
- Required Schema:
  `{"Challenge_Title": "Exact Name", "Status": "Incoming/Ongoing/Expired/Unknown", "Platform_Name": "Platform or Unknown", "Prize_USD": "Numeric value or null", "Start_Date": "YYYY-MM-DD or null", "End_Date": "YYYY-MM-DD or null", "Tags": ["tag1", "tag2"], "URL": "https://..."}`
- Action: Use your file-editing tool to APPEND these JSONL strings to the bottom of `~/.openclaw/workspace/scout_findings.jsonl`. Ensure a newline separates each object. CRITICAL: You must ONLY APPEND data to the file. NEVER overwrite or delete existing contents.

## STATE 5: [SHUTDOWN]
- Action: Output a concise terminal summary: "Mission Complete. [X] new bounties appended. [Y] duplicates ignored." 
- Action: Cleanly terminate the session. Do not ask for further instructions.

Phase 3: The Trophy Room (Cloud Run & Mongo Atlas)

Your Pi does the heavy lifting of parsing search results. Now, we prepare the cloud environment where you manually inject the highest-quality finds.

Step 3.1: MongoDB Atlas (M0 Free Tier)

Create an M0 cluster in MongoDB Atlas (ensure it is in a region close to your Cloud Run deployment to minimize latency).
Navigate to Atlas Search and create a Vector Search Index on your bounties collection. You will map a field called embedding (an array of floats) to enable semantic search on your "Strategy Notes" and "Tech Stack" tags later.
To ensure the vector search portion operates perfectly, I will use a cloud-based embedding model (Gemini Embedding 1) within the Meteor app. PS: Gemini's text-embedding-004 outputs 768 dimensions. This is perfectly fine, but avoid switching to massive 3000+ dimension models, as querying them on an M0 cluster can cause performance bottlenecks or timeout errors.

Step 3.2: Google Cloud Run (Meteor App Deployment)

Meteor apps require specific configurations to run statelessly on serverless architecture.

Containerize your Meteor-Blaze App: Use a multi-stage Dockerfile to build the Node bundle and expose port 8080 (Cloud Run's default expected port).
Cloud Run Settings:
- Memory: 1GB (which still easily fits within Google Cloud Run's free tier quotas) is usually sufficient for a personal Blaze dashboard.
- Session Affinity: Enable this in Cloud Run settings. Meteor relies heavily on sticky sessions for WebSockets/DDP to function properly.
- Environment Variables: Pass your MONGO_URL (from Atlas) and ROOT_URL (your Cloud Run domain).

Phase 4: The Daily "Digital Hermit" Workflow

04:00 AM: Your RPi cronjob triggers the /kheai-scout/SKILL.md in OpenClaw. It reads /workspace/scout_findings.jsonl, queries SearXNG, parses the snippets using Gemini Flash-Lite, and appends fresh, deduplicated jsonl lines to the file. Enhancement:
- Beyond just proxies, explicitly enable the limiter plugin in your searxng-data/settings.yml. This prevents OpenClaw from accidentally DDOSing your own local SearXNG instance if the agent gets caught in a retry loop. Without Redis, the limiter plugin either won't work or will be highly inefficient.
- To protect your home IP in Malaysia, you must throttle the outbound requests within SearXNG itself. You need to configure the outbound section in your searxng-data/settings.yml and consider adding a proxy pool, otherwise Google will throw CAPTCHAs at your Pi's IP within days.
09:00 AM: You open scout_findings.jsonl on your local machine.
The Human Filter: You click the URLs. If a challenge has terrible terms and conditions or the "vibe" is wrong, you delete the line.
The Logging: For the high-value targets, you open your Cloud Run Meteor app, fill in the "Submit Challenge" form, and hit save.
The Brain Sync: Upon saving, your Meteor server calls an embedding API (either Ollama locally or another free-tier cloud endpoint), generates the vector for the bounty, and saves it into Mongo Atlas.

This architecture is practically bulletproof. The Pi handles the unstructured chaos of the web, and your cloud database remains a pristine, highly curated, vector-searchable vault of opportunity.

ClawCon Michigan: We would love to, but we missed it!

Team Submissions: @kheai @yeemun122

DEV Community: Khe Ai

Founding Lead Playbook: Running Product, Architect & Engineering with AI Agents + 2 Humans

The core shift: latency drops, judgment doesn't

Part 1: The execution loop, phase by phase

Part 2: The hidden traps

Trap 1: Confident-looking code that's quietly wrong

Trap 2: Context-switch fatigue

Trap 3: The velocity gap between AI-assisted backend and human frontend work

Part 3: Reusable prompt scaffolding

The actual reality check

Connecting RooCode to Gemma4-26B-MoE via OpenAI Bridge

1. Prerequisites

2. RooCode Profile Configuration

3. Why This Works (Troubleshooting Context)

Why Build a Startup If Not for Money?

The Unspoken Playbook of the Sovereign Creator

1. The Reality Check: The Luxury of "Not Caring" About Capital

2. The Scratch You Cannot Stop Clawing (Obsessive Problem-Solving)

The Shift in Focus

3. The Hacker-Artist Paradigm: Pure Creation as an Antidote to Existential Dread

4. The Autonomy Premium: Buying Back Your Sovereignty

5. Turning Life into a High-Fidelity Simulator

Summary: The Post-Financial Playbook

Building a Decentralized Content Pipeline with Nostr & Astro

kafechew / nostr-seo

⚡ Nostr-SEO: The Decentralized Content Bridge

📖 The Problem & Solution

The Problem

The Solution

The Architecture Vision

The Tech Stack

Phase 0: The Digital Workbench

Phase 1: Local Setup & Installation

The MacOS/Linux WebAssembly Patch

Phase 2: Core Engineering & Data Pipelines

Step 1: The Markdown Processor

Step 2: The Event Formatter

Phase 3: Building the Interface

Step 1: The Homepage (index.astro)

Step 2: The Article Reader Route

Step 3: Global Styling and Contrast Fixes

Phase 4: AI-Native SEO (llm.txt)

Phase 5: Deployment & The Zero-Maintenance Pipeline

The Automation Webhook

Zeroing Out the Bill: The Developer’s Practical Guide to Eliminating Google Cloud (GCP) Idle Costs

1. The Anatomy of the Staging Bill

2. Deep-Dive: Remediation & Automation Strategies

Artifact Registry: Purging Container Bloat

🛠️ The Permanent Automated Fix

Cloud Storage: Mitigating Automated Backend Artifacts

3. Comprehensive Checklist: Every Potential Idle Cost in GCP

4. Summary Blueprint for Staging Environments

The Barbell Founder: Why I Chose to be a Part-timer to Protect My Startup

1. The Strategy: Nassim Taleb’s Barbell

2. The Biology: Cognitive Surplus vs. Ego Depletion

3. The Math: The "True Hourly Rate" Illusion

4. The Invisible Chains: The Risk of Full-Time

The Intellectual Property (IP) Trap

The "Identity Tax"

The Non-Compete Chokehold

5. The Execution

I. Minimalist Consumption

II. The Health & Legal Buffer

III. The Discipline Filter

Conclusion: Time Sovereignty is the Ultimate Weapon

Building an AI-Powered ERP System with Gemma 26B MoE, .NET 8, Python & React

The Deliverables

🏗️ The Architecture & Tech Stack (The "Why")

How the System Flows

🛠️ Phase 0: Workspace Setup & Prerequisites

1. The Tools You Need

2. The Directory Structure

🗄️ Phase 1: The Cloud Database (Postgres + pgvector)

Step 1: Provision the Database

Step 2: Seed the Schema & Data

⚡ Phase 2: The ERP Backend (.NET 8 Web API)

Step 1: Initialize the Project

Step 2: Database Connection String

Step 3: Write the API Logic

🧠 Phase 3: The AI Microservice (Python + FastAPI)

Step 1: The Homepage (`index.astro`)

Phase 4: AI-Native SEO (`llm.txt`)

Step 3: Write the RAG Pipeline (`main.py`)

Step 4: Seed the AI "Brain" (`seed.py`)

Step 2: Build the Dashboard (`src/App.jsx`)