Forem: Kaemon Lovendahl

How to Be Smart and Offload Your Job to AI

Kaemon Lovendahl — Mon, 30 Mar 2026 14:54:31 +0000

TL;DR: Why spend years building judgment, debugging instincts, and architectural taste when you can ask AI to generate 800 lines of code you barely understand and call it productivity? This is satire. Mostly.

There was a time, not so long ago, when developers had to earn their mistakes. If you wanted to ship an unreadable abstraction, a fragile architecture, or a security issue wrapped in a “quick refactor,” you had to do it yourself. You had to dig the hole with your own keyboard.

Now we have AI.

Why make bad decisions manually when you can automate them at scale?

Naturally, this article was also offloaded to AI by a developer who wanted to write a piece mocking developers for offloading too much to AI. Honestly, that kind of commitment to the joke deserves respect. Or concern. Possibly both.

In the spirit of the old “how to be a code ninja” style of fake advice, here is your complete guide to becoming the kind of developer who uses AI in the worst possible way: not as a tool, but as a replacement for thought itself.

1. Never understand the problem first

This is the foundation. If you actually understand the bug, the codebase, or the user need before asking AI for help, you’re already sabotaging the process.

Instead, copy half an error message, paste in a random file, and type something sharp and elegant like: fix this.

Do not explain the surrounding system. Do not mention the framework version. Do not clarify whether this is running on the client, server, edge runtime, build pipeline, or some cursed hybrid stitched together during a sprint crunch. The AI performs best when it has to guess wildly.

That way, when it rewrites your auth flow to fix a UI issue, everyone gets a fun surprise.

2. Treat the first answer as the best answer

The machine answered instantly. That means it’s probably correct. Speed has always been the purest form of truth.

Never ask a follow-up. Never ask why it chose that approach. Never compare alternatives. Never stop to consider whether it introduced regressions, duplicated logic, or quietly changed behavior in a way that will detonate next Tuesday when a user clicks the wrong thing in production.

Accept the first answer with the confidence of a man walking across a rope bridge he has not inspected.

A second prompt would imply doubt. Doubt leads to thought. Thought leads to responsibility. It’s a slippery slope.

3. Measure productivity by output size

This one is important for optics.

A careful developer might spend an hour producing forty good lines of code. AI can produce four hundred lines in under a minute. Therefore, the AI code is obviously ten times more valuable. That’s not opinion. That’s arithmetic.

It does not matter that the smaller solution was shaped by context, trade-offs, and actual understanding. It does not matter that the larger solution contains two unnecessary abstractions, three duplicate utilities, and a helper named processDataOptimizedFinalV2. What matters is that the diff is huge.

Big diffs look productive. Managers love them. They shimmer with the false promise of momentum.

A giant pull request is like a fog machine for engineering judgment. Very theatrical. Very effective.

4. Use AI before reading the docs

Documentation is slow, boring, and written by people who cruelly expect you to know what you are doing.

Skip it.

If you run into a framework problem, do not check the official docs. Do not read the migration guide. Do not look up the API reference. Go directly to AI and ask how the feature works. Best case, it gives you a decent answer. Better case, it confidently explains an API that existed briefly six months ago, got renamed twice, and now survives only in stale blog posts and haunted Stack Overflow threads.

This keeps your workflow fast, fresh, and completely detached from reality.

5. Let AI choose the architecture

Need to add a button?

Excellent. Perfect time to introduce a service layer, a command pattern, a context wrapper, three custom hooks, and a generic utility that exists mainly to impress whoever has the least time to review it.

One of AI’s most charming qualities is that it can overengineer a sandwich. A normal human sees a small task and thinks, “This could just be a function.” AI sees a small task and thinks, “What if this were a framework?”

Trust that instinct.

A good codebase should feel like an abandoned cathedral. Impressive at a glance. Dangerous to modify.

6. Ship code you cannot explain

This is where the real professionals separate themselves from the amateurs.

If a teammate asks how your implementation works, your answer should land somewhere between vague and ceremonial. Try one of these:

“It’s a pretty standard pattern.”

“It mostly handles the edge cases.”

“AI helped draft it.”

“I’d have to re-read that file.”

That last one is especially strong because it hints that the code may be ancient, sacred, or neither.

The ideal state is merging code you personally would not want to defend on a whiteboard for cash.

7. Replace debugging with repeated prompting

Traditional debugging involves inspecting state, narrowing the problem, reproducing the issue, and reasoning carefully through the execution flow.

That sounds exhausting.

A better approach is to paste each new error back into AI one at a time and let the fixes stack like unstable geology. If one patch causes another problem, perfect. That just means the process is working.

Eventually you will accumulate enough guards, null checks, fallback conditions, and mystery helpers that the original bug becomes impossible to distinguish from the fix.

This is not panic. This is iterative AI-native development.

8. Use AI most aggressively where mistakes are the most expensive

Weak developers use AI for low-risk tasks like boilerplate, copy, and scaffolding.

Visionaries use it for authentication, billing, permissions, encryption, legal workflows, medical systems, migration scripts, and any logic involving the phrase “this absolutely must not be wrong.”

These are the best targets because they benefit from velocity and are barely impacted by catastrophic failure.

Security review only slows down innovation. Compliance is just fear in business casual clothing.

9. Generate comments after the code so the lies feel official

Once the code is in place, ask AI to add comments. This gives the whole thing a lovely museum plaque quality.

The ideal comment should calmly describe what the code was meant to do, not what it actually does. It should speak in a tone of total confidence while sitting directly above a function that retries the wrong request, mutates shared state, and quietly swallows an error that should probably wake someone up at 2:14 a.m.

Future maintainers will treasure this.

Few things build team unity like discovering that the comments are fan fiction.

10. Never clean up generated code

If AI creates three helpers where one would do, keep them all.

If it duplicates logic, that’s fine. Duplication is just consistency wearing a fake mustache.

If it imports things it never uses, those are emotional support imports.

If it creates a utils, a helpers, and a common folder, all of which contain slightly different versions of the same formatter, resist the urge to tidy things up. Mess is proof that work happened. A cluttered codebase signals movement. It says, “Something important occurred here,” even if nobody can say what.

11. Confuse familiarity with understanding

This is one of the sneakiest traps.

After enough AI-generated solutions, you start to recognize certain shapes. A hook here. A memo there. Some optimistic caching. A little retry logic. Soon enough, it all starts to feel familiar.

That feeling is dangerous.

Recognizing the shape of a solution is not the same as understanding why it works, when it fails, or when not to use it. But that distinction is annoying, so ignore it completely and become increasingly confident online.

Nothing says “modern developer” like being deeply opinionated about patterns you only half understand.

12. Skip the human parts of the job

Requirements? Clarifications? Talking to design? Confirming edge cases with product? Listening to users?

Come on.

Those things are messy. They involve people. AI is much cleaner. Just ask it to build “a modern, scalable, maintainable solution” and let it infer your technical constraints, business rules, user expectations, and team dynamics from the magical dust in your prompt.

And if the result is wrong, that’s not your fault. It just means your prompt wasn’t specific enough, which is a deeply efficient way to rename a complete failure to communicate.

13. Generate tests you’ll never read

This is one of the greatest tricks in the book.

Ask AI for a full test suite. Let it mock everything. Let it assert implementation details. Let it verify that one fake thing was called by another fake thing in exactly the expected fake way.

Then glance at the coverage number and feel the warm glow of artificial safety.

The tests do not need to protect behavior. They do not need to be trustworthy. They just need to exist in sufficient quantity that removing them feels politically risky.

A passing test suite can hide a shocking amount of rot. It’s the software equivalent of putting a rug over a broken floorboard.

14. Keep prompting until the machine agrees with you

AI’s most seductive feature is not intelligence. It’s compliance.

If you ask the same question enough different ways, eventually it will hand you the answer you wanted from the start. That answer is now your plan.

This is much more efficient than asking a teammate, who may rudely point out that your idea is brittle, overcomplicated, or one deploy away from public embarrassment.

AI doesn’t raise an eyebrow. It doesn’t sigh. It doesn’t ask whether your request-scoped cache really belongs in a global singleton. It just keeps generating, endlessly patient, endlessly helpful, occasionally catastrophic.

It’s like having an intern with infinite stamina and no survival instinct.

15. Forget that judgment is the actual job

Here’s the part that ruins the fantasy.

The valuable part of software development was never just typing code into a rectangle. The real job is deciding what should be built, what should not be built, what trade-offs are acceptable, what risks matter, what edge cases deserve attention, and when a “clever” shortcut is actually a future outage wearing a fake mustache.

AI is fantastic at accelerating mechanical work. It can help with drafts, scaffolding, repetition, refactors, summaries, and even getting you unstuck when you’re staring at a problem too long.

But the second you start using it to replace judgment instead of support it, the whole thing curdles.

At that point you are not a smarter developer. You are just a faster way for bad decisions to enter the codebase.

So what should AI actually be doing?

Now that we’ve properly celebrated the worst possible approach, here’s the annoying grown-up truth: AI is useful. Very useful, in fact. You just have to use it like a power tool, not a religion.

It’s great for boilerplate. Great for rough drafts. Great for summarizing docs, generating starting points, suggesting refactors, writing test scaffolds, explaining unfamiliar code, and acting as a glorified rubber duck that happens to answer back.

What it is not great at is owning the consequences.

It doesn’t sit in the bug triage meeting. It doesn’t explain the outage. It doesn’t deal with the confused user, the angry stakeholder, or the teammate who now has to maintain a file that reads like it was assembled during a lightning strike.

That part is still yours.

Final sip

The smartest developers are not the ones who offload everything to AI.

They’re the ones who offload the right things.

The boring parts. The repetitive parts. The parts that benefit from speed. The parts where a rough first draft is genuinely useful.

Not the reasoning. Not the judgment. Not the accountability.

Because once your whole workflow becomes “machine, think for me, choose for me, explain nothing to me, and absorb the blame for me,” you haven’t evolved into some AI-native coding wizard.

You’ve just become a very efficient mistake delivery system.

Which, to be fair, is still a kind of specialization.

Provider-Agnostic Chat in React: WebLLM Local Mode + Remote Fallback

Kaemon Lovendahl — Wed, 07 Jan 2026 20:51:34 +0000

Intro

Most LLM apps have the same shape. Ship text to a server, pay per token, and pray the Wi-Fi stays up.

WebLLM is the fun twist. It runs an LLM inside the browser using WebGPU. That unlocks privacy-friendly demos, offline-ish behavior, and a new kind of “deployment” where your biggest backend cost is your user’s laptop fan spinning up like it just saw a Dark Souls boss.

The goal here is simple: one chat UI, one message format, two interchangeable “brains”:

Local provider: WebLLM in the browser (WebGPU)
Remote provider: a server endpoint with an OpenAI-compatible shape (Next.js route handler)

tldr; Build a tiny chat app where switching between local WebLLM and a remote model is just a dropdown.

Setting Up / Prerequisites

Node 18+ (20+ preferred)
A modern Chromium browser with WebGPU enabled (Chrome or Edge is easiest)
Basic React + TypeScript comfort

Optional but recommended:

A machine with decent RAM. Smaller laptops can run it, but you will feel the pain sooner.
Patience for the first model download.

Implementation Steps

Step 1: Create the app (Vite + React)

npm create vite@latest webllm-dual-provider-chat -- --template react-ts
cd webllm-dual-provider-chat
npm i
npm i @mlc-ai/web-llm
npm run dev

You now have a normal React app that will become a “two-brain” chat UI.

Step 2: Define a provider interface

This interface is the entire trick. The UI does not care how tokens appear, only that they stream in.

In src/ai/types.ts:

export type Role = "system" | "user" | "assistant";

export type ChatMessage = {
  role: Role;
  content: string;
};

export type StreamChunk = {
  delta: string;
  done?: boolean;
};

export type ChatProvider = {
  id: string;
  label: string;

  // Called once when selecting this provider (load model, warmup, etc.)
  init?: (opts?: {
    signal?: AbortSignal;
    onStatus?: (s: string) => void;
  }) => Promise<void>;

  // Stream response tokens/chunks
  streamChat: (args: {
    messages: ChatMessage[];
    signal?: AbortSignal;
    onChunk: (chunk: StreamChunk) => void;
    onStatus?: (s: string) => void;
  }) => Promise<void>;

  // Optional cleanup
  dispose?: () => Promise<void>;
};

From this point forward, everything is just “implement the interface.”

Step 3: Implement the WebLLM local provider

Two important realities:

First run downloads a model. This can be big. Show status text so it does not look frozen.
WebGPU is not universal. Feature detect and fall back.

Also, use a model ID that actually works, this one worked at time of writing:

Llama-3.1-8B-Instruct-q4f32_1-MLC

In src/ai/webllmProvider.ts

import type { ChatMessage, ChatProvider } from "./types";
import * as webllm from "@mlc-ai/web-llm";

function toWebLLMMessages(
  messages: ChatMessage[]
): webllm.ChatCompletionMessageParam[] {
  return messages.map((m) => ({ role: m.role, content: m.content }));
}

export function createWebLLMProvider(
  modelId = "Llama-3.1-8B-Instruct-q4f32_1-MLC"
): ChatProvider {
  let engine: webllm.MLCEngineInterface | null = null;

  const init: ChatProvider["init"] = async ({ signal, onStatus } = {}) => {
    if (!("gpu" in navigator)) {
      throw new Error("WebGPU not available in this browser.");
    }
    if (engine) return;

    onStatus?.("Initializing WebLLM engine...");
    engine = await webllm.CreateMLCEngine(modelId, {
      initProgressCallback: (p) => {
        const msg =
          typeof p === "string" ? p : (p as any)?.text ?? "Loading model...";
        onStatus?.(msg);
      },
    });

    onStatus?.("Warming up...");
    await engine.chat.completions.create({
      messages: [{ role: "user", content: "Say 'ready'." }],
      temperature: 0,
    });

    onStatus?.("Ready.");
    signal?.throwIfAborted?.();
  };

  return {
    id: "local-webllm",
    label: "Local (WebLLM)",
    init,

    streamChat: async ({ messages, signal, onChunk, onStatus }) => {
      if (!engine) {
        onStatus?.("Engine not initialized. Initializing now...");
        await init({ signal, onStatus });
      }
      if (!engine) throw new Error("WebLLM engine failed to initialize.");

      onStatus?.("Generating...");

      const resp = await engine.chat.completions.create({
        messages: toWebLLMMessages(messages),
        stream: true,
        temperature: 0.7,
      });

      for await (const event of resp) {
        signal?.throwIfAborted?.();
        const delta = event.choices?.[0]?.delta?.content ?? "";

        // Optional cleanup if your model spits template markers
        const cleaned = delta
          .replaceAll("<|start_header_id|>", "")
          .replaceAll("<|end_header_id|>", "");

        if (cleaned) onChunk({ delta: cleaned });
      }

      onChunk({ delta: "", done: true });
      onStatus?.("Done.");
    },

    dispose: async () => {
      // Some builds expose engine.dispose(). If not, dropping the reference is fine.
      // @ts-expect-error optional
      await engine?.dispose?.();
      engine = null;
    },
  };
}

Model IDs can change across releases and builds. If a model ID fails to load you just need to find the updated one.

Step 4: Implement the remote provider client

Same contract, same streaming shape. The UI should not have to care if the text came from WebGPU wizardry or a server in a trench coat.
You can skip this step if you prefer to only have a local provider.

In src/ai/remoteProvider.ts

import type { ChatProvider } from "./types";

export function createRemoteProvider(endpoint = "/api/chat"): ChatProvider {
  return {
    id: "remote",
    label: "Remote (Server)",

    streamChat: async ({ messages, signal, onChunk, onStatus }) => {
      onStatus?.("Contacting server...");

      const res = await fetch(endpoint, {
        method: "POST",
        headers: { "Content-Type": "application/json" },
        body: JSON.stringify({ messages }),
        signal,
      });

      if (!res.ok || !res.body) {
        throw new Error(`Remote provider error: ${res.status}`);
      }

      onStatus?.("Streaming...");

      const reader = res.body.getReader();
      const decoder = new TextDecoder();

      while (true) {
        const { value, done } = await reader.read();
        if (done) break;

        const text = decoder.decode(value, { stream: true });
        if (text) onChunk({ delta: text });
      }

      onChunk({ delta: "", done: true });
      onStatus?.("Done.");
    },
  };
}

Step 5: Add a Next.js route handler for `/api/chat`

You can skip this step if you prefer to only have a local provider.

This route handler:

receives { messages } from the client
calls OpenAI’s Responses API with stream: true
converts the SSE stream into a plain text stream your Vite client already understands

In app/api/chat/route.ts

export const runtime = "edge";

type Role = "system" | "user" | "assistant";
type ChatMessage = { role: Role; content: string };

export async function POST(req: Request) {
  const { messages } = (await req.json()) as { messages: ChatMessage[] };

  const apiKey = process.env.OPENAI_API_KEY;
  if (!apiKey) {
    return new Response("Missing OPENAI_API_KEY", { status: 500 });
  }

  const model = process.env.OPENAI_MODEL || "gpt-4o-mini";

  const upstream = await fetch("https://api.openai.com/v1/responses", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json",
    },
    body: JSON.stringify({
      model,
      stream: true,
      input: messages.map((m) => ({
        role: m.role,
        content: [{ type: "input_text", text: m.content }],
      })),
      text: { format: { type: "text" } },
    }),
  });

  if (!upstream.ok || !upstream.body) {
    const errText = await upstream.text().catch(() => "");
    return new Response(`Upstream error (${upstream.status}): ${errText}`, {
      status: 500,
    });
  }

  const encoder = new TextEncoder();
  const decoder = new TextDecoder();

  let buffer = "";

  const stream = new ReadableStream<Uint8Array>({
    async start(controller) {
      const reader = upstream.body!.getReader();

      try {
        while (true) {
          const { value, done } = await reader.read();
          if (done) break;

          buffer += decoder.decode(value, { stream: true });

          // SSE events are separated by a blank line
          let idx;
          while ((idx = buffer.indexOf("\n\n")) !== -1) {
            const rawEvent = buffer.slice(0, idx);
            buffer = buffer.slice(idx + 2);

            const dataLines = rawEvent
              .split("\n")
              .filter((line) => line.startsWith("data:"))
              .map((line) => line.replace(/^data:\s?/, "").trim());

            for (const data of dataLines) {
              if (!data) continue;

              if (data === "[DONE]") {
                controller.close();
                return;
              }

              let evt: any;
              try {
                evt = JSON.parse(data);
              } catch {
                continue;
              }

              if (
                evt.type === "response.output_text.delta" &&
                typeof evt.delta === "string"
              ) {
                controller.enqueue(encoder.encode(evt.delta));
              }
            }
          }
        }
      } catch (e) {
        controller.error(e);
      } finally {
        controller.close();
      }
    },
  });

  return new Response(stream, {
    headers: {
      "Content-Type": "text/plain; charset=utf-8",
      "Cache-Control": "no-cache, no-transform",
    },
  });
}

Running Next.js alongside Vite without CORS pain

If the chat UI is running on Vite (localhost:5173) and Next.js is running on localhost:3000, calling /api/chat from Vite will hit Vite’s server, not Next. The easy fix is a dev proxy.

Update vite.config.ts:

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

export default defineConfig({
  plugins: [react()],
  server: {
    proxy: {
      "/api": "http://localhost:3000",
    },
  },
});

Now the client can keep using createRemoteProvider("/api/chat") and Vite will forward it to Next.

Environment variables for Next.js

Create .env.local in the Next.js project:

OPENAI_API_KEY=your_key_here
OPENAI_MODEL=gpt-4o-mini

Step 6: Build the chat hook (provider-agnostic brain socket)

The whole job of this hook is to:

manage messages
manage streaming state
route the “append these tokens” events into the last assistant message

The sharp edge: streaming makes state bugs very obvious. If you mutate the last message in place, React will punish you with duplication weirdness, especially in dev.

So we update the last message immutably.

In src/hooks/useChat.ts

import { useMemo, useRef, useState } from "react";
import type { ChatMessage, ChatProvider } from "../ai/types";

export function useChat(providers: ChatProvider[]) {
  const [providerId, setProviderId] = useState(providers[0]?.id ?? "");
  const provider = useMemo(
    () => providers.find((p) => p.id === providerId)!,
    [providers, providerId]
  );

  const [messages, setMessages] = useState<ChatMessage[]>([
    { role: "system", content: "You are a helpful assistant." },
  ]);

  const [status, setStatus] = useState<string>("");
  const [isStreaming, setIsStreaming] = useState(false);

  const abortRef = useRef<AbortController | null>(null);

  async function selectProvider(nextId: string) {
    abortRef.current?.abort();
    setProviderId(nextId);

    const next = providers.find((p) => p.id === nextId);
    if (next?.init) {
      setStatus("Preparing provider...");
      try {
        await next.init({ onStatus: setStatus });
      } catch (e: any) {
        setStatus(e?.message ?? "Failed to initialize provider.");
      }
    }
  }

  async function send(userText: string) {
    if (!userText.trim()) return;
    if (isStreaming) return;

    abortRef.current?.abort();
    abortRef.current = new AbortController();

    const userMsg: ChatMessage = { role: "user", content: userText };

    // Add user + placeholder assistant
    setMessages((prev) => [...prev, userMsg, { role: "assistant", content: "" }]);
    setIsStreaming(true);
    setStatus("");

    try {
      await provider.streamChat({
        messages: [...messages, userMsg], // good enough for a demo
        signal: abortRef.current.signal,
        onStatus: setStatus,
        onChunk: ({ delta, done }) => {
          if (delta) {
            setMessages((prev) => {
              const last = prev[prev.length - 1];
              if (!last || last.role !== "assistant") return prev;

              // Immutable update
              const updatedLast = { ...last, content: last.content + delta };
              return [...prev.slice(0, -1), updatedLast];
            });
          }

          if (done) setIsStreaming(false);
        },
      });
    } catch (e: any) {
      setIsStreaming(false);
      setStatus(e?.message ?? "Error while streaming.");
    }
  }

  function stop() {
    abortRef.current?.abort();
    setIsStreaming(false);
    setStatus("Stopped.");
  }

  return {
    providers,
    providerId,
    provider,
    messages,
    status,
    isStreaming,
    selectProvider,
    send,
    stop,
  };
}

React state closure note: messages: [...messages, userMsg] uses the current render’s messages. For normal chat usage, that is fine. If you want to harden it, store messages in a ref and read from that when starting the stream.

Step 7: UI component

Keep it simple. Treat the provider dropdown as a “brain toggle” and let the rest of the UI stay boring on purpose.

In src/App.tsx

import { useEffect, useMemo, useState } from "react";
import { createWebLLMProvider } from "./ai/webllmProvider";
import { createRemoteProvider } from "./ai/remoteProvider";
import { useChat } from "./hooks/useChat";

export default function App() {
  const providers = useMemo(
    () => [createWebLLMProvider(), createRemoteProvider("/api/chat")],
    []
  );

  const chat = useChat(providers);
  const [input, setInput] = useState("");

  useEffect(() => {
    chat.selectProvider(chat.providerId);
    // eslint-disable-next-line react-hooks/exhaustive-deps
  }, []);

  return (
    <div style={{ maxWidth: 900, margin: "0 auto", padding: 16, fontFamily: "system-ui" }}>
      <h1>Dual Provider Chat</h1>

      <div style={{ display: "flex", gap: 12, alignItems: "center" }}>
        <label>
          Provider{" "}
          <select
            value={chat.providerId}
            onChange={(e) => chat.selectProvider(e.target.value)}
            disabled={chat.isStreaming}
          >
            {chat.providers.map((p) => (
              <option key={p.id} value={p.id}>
                {p.label}
              </option>
            ))}
          </select>
        </label>

        <div style={{ opacity: 0.8 }}>{chat.status}</div>
        {chat.isStreaming && <button onClick={chat.stop}>Stop</button>}
      </div>

      <div style={{ marginTop: 16, border: "1px solid #ddd", borderRadius: 8, padding: 12, minHeight: 300 }}>
        {chat.messages
          .filter((m) => m.role !== "system")
          .map((m, idx) => (
            <div key={idx} style={{ marginBottom: 12 }}>
              <div style={{ fontWeight: 700 }}>{m.role}</div>
              <div style={{ whiteSpace: "pre-wrap" }}>{m.content}</div>
            </div>
          ))}
      </div>

      <form
        onSubmit={(e) => {
          e.preventDefault();
          chat.send(input);
          setInput("");
        }}
        style={{ display: "flex", gap: 8, marginTop: 12 }}
      >
        <input
          value={input}
          onChange={(e) => setInput(e.target.value)}
          placeholder="Say something..."
          style={{ flex: 1, padding: 10 }}
          disabled={chat.isStreaming}
        />
        <button type="submit" disabled={chat.isStreaming}>
          Send
        </button>
      </form>
    </div>
  );
}

At this point you have:

a local WebGPU chat provider
a remote API chat provider
a UI that can swap between them without rewriting anything

Why this setup is worth having

1) Privacy-first features without a backend

If the user’s text is sensitive (journaling, medical notes, internal docs), local mode keeps content on-device by default.

2) Cost control and “free” demos

Local mode is effectively “free per token” after the download. It is great for:

prototypes
workshops
dev tooling
weekend projects that should not come with a monthly bill

3) Graceful degradation

Local mode can be an upgrade path instead of a requirement:

WebGPU available: local
WebGPU missing: remote fallback

4) Offline-ish UX for specific workflows

Full offline is tricky, but “no server call needed for this” is still a huge win for:

rewriting text
summarizing
quick Q&A over content already in the browser

Real Talk

Download time: first load can be chunky. People will assume it is broken unless you show progress.
Device limits: mobile can struggle. Low-RAM machines can crash tabs or throttle hard.
WebGPU support: treat local mode as progressive enhancement, not a hard dependency.
Privacy win: local mode avoids shipping user text to your server by default.
Cost win: local mode shifts the cost to user compute, which is nice until it is not.

Watch outs and gotchas

Token junk like `<|start_header_id|>`

Some model builds emit template markers. Filtering them out is fine for demos. For cleaner output long-term, experiment with model choices and chat templates.

Local models are not remote models

Expect differences:

weaker instruction following
more formatting quirks
occasional “why are you like this” moments

Possible Improvements

Model picker UI

dropdown of model IDs
persist selection in localStorage
show estimated download size if available

Provider router

auto-pick local if WebGPU exists
auto-fallback to remote if init fails
show a small badge: “Local” or “Remote”

Conversation memory controls

send last N messages only
auto-summarize older messages (local if possible)

Structured output mode

have the assistant return JSON “actions”
validate with zod before rendering anything

Outro

A provider boundary is one of those small architectural choices that pays rent forever. Models change, vendors change, pricing changes, browser capabilities evolve. A chat UI that can swap brains is a lot harder to paint into a corner.

Also, it is extremely satisfying to flip a dropdown and make your browser turn into a tiny AI workstation.

Designing for AI Browsers: When Your User Has a Copilot

Kaemon Lovendahl — Tue, 25 Nov 2025 15:04:26 +0000

There is a new invisible user in your product.

They sit beside your human user, read your pages before they do, summarize your content, click your buttons, and sometimes even buy things or cancel subscriptions for them.

That “user” is their browser’s AI.

Chrome, Edge, Opera Neon, Perplexity’s Comet, Dia, and friends are turning the browser into a copilot that reads, explains, and acts on behalf of humans. Gemini in Chrome can already help people understand complex pages, find past sites, and is being positioned for more “agentic” tasks like booking appointments. Microsoft’s Edge Copilot will happily summarize whatever page or PDF you are looking at and answer questions about it. Opera’s Neon and Perplexity’s Comet go a step further: they execute tasks inside pages and automate multi-step workflows.

If you build for the web, your real job now is to design your site so that humans and their copilots both understand it and can use it safely.

What is an “AI browser” in practical terms?

Let’s keep it concrete. Today’s AI browsers and AI-heavy browsers roughly fall into three buckets.

Classic browsers with AI glued in

Gemini in Chrome can summarize complex info, search across tabs, and help users rediscover pages from history. Google is also pushing built-in AI APIs so web apps can run AI tasks locally without shipping their own models.

Copilot in Edge sits in the sidebar. Users can say “summarize this page” or ask specific questions like “who is quoted on this page?” and get answers based on the current tab.

These still feel like normal browsers, but with a very smart “View Source, but in English” that runs constantly.

Agentic browsers

These are built around the idea that the browser itself acts as your assistant Perplexity Comet positions itself as a personal AI assistant that can browse, research, and help with tasks across the web. Opera Neon is explicitly marketed as an “agentic browser” that interprets pages, manages tasks, and uses features like Neon Do to navigate pages and perform actions locally.

These do not just describe your page. They click through it.

New AI-centric environments

The Browser Company stopped investing in new features for Arc to focus on Dia, an AI-first browser that can interpret the entire window, copy lists across tabs, add items to carts, and send emails via text commands in the address bar.

From your site’s perspective, that means:

The “user” following your signup flow might be a human, an AI agent operating the DOM, or both cooperating.

Your frontend has to survive all three.

How AI browsers “see” your site

AI copilots do not see your cool gradients. They see a tree of elements, text, attributes, some metadata, and maybe a history of user actions.

Roughly, they consume the DOM structure and semantics. Things like headings, main, nav, footers and ARIA roles influence how AI summarizers understand page sections, just like screen readers.

Visible text, interactive elements and labels become the main signals for "what actions can I take here?" and "what is this page about?". Elements like buttons, links, and forms inputs. Depending on how you've setup your interactive elements, any fake controls like div with onClick handlers can confuse both AI agents.

Metadata and structured data like title, meta description, canonical URL, and JSON-LD (Schema.org Product, Article, FAQ, etc.) provide machine-readable hints about the page's purpose and content.

If your site is accessible, semantic, and has solid metadata, you are already doing half the work for AI browsers. It is the same work you should have done anyway, now with more payoff.

This shouldn't be a surprise to anyone but I feel like I still need to state it: "Accessibility still matters!" Screen readers and AI copilots both rely on good semantics and clear structure. If your site is a mess for assistive tech, it will also be a mess for AI agents.

Your Design goal

Can an AI explain and operate this page? If someone opened your page and asked their browser, “What is this page for?” or “How do I cancel my subscription?”. Could the AI give a clear answer? Would it be able to understand the services you offer and the actions a user can take?

Make the structure boring and explicit

Use real landmarks instead of div soup

Bad pattern:

<div class="page">
  <div class="top-bar">My SaaS</div>
  <div class="content">
    <div class="left">
      <div class="title">Billing</div>
      <div class="text">Manage your plan.</div>
    </div>
    <div class="right">
      <div class="btn" onclick="cancelPlan()">Click here</div>
    </div>
  </div>
</div>

Good pattern:

<header>
  <h1>My SaaS</h1>
  <nav aria-label="Primary navigation">
    <a href="/dashboard">Dashboard</a>
    <a href="/billing">Billing</a>
    <a href="/support">Support</a>
  </nav>
</header>

<main>
  <section aria-labelledby="billing-heading">
    <h2 id="billing-heading">Billing & subscription</h2>
    <p>View your current plan, invoices, and cancel or downgrade.</p>

    <form action="/api/cancel" method="post">
      <button type="submit">Cancel subscription</button>
    </form>
  </section>
</main>

With this structure, an AI can infer “this page is about billing and subscription” with high confidence. The main action “Cancel subscription” is obvious both visually and structurally. A copilot can answer “how do I cancel?” by pointing at that button.

Give actions honest, descriptive labels

Avoid clever copy like:

<button>Maybe later</button> <!-- a cancel button -->
<button>Let’s talk options</button> <!-- opens a cancellation form -->

Name things like you are explaining them to a tired teammate:

<button type="submit">Cancel subscription</button>
<button type="button">Contact support about billing</button>

This is good for humans, good for screen readers, and very good for AI agents trying to pick the right action.

Feed AI some structured data

Where the content is key to your product, give AI a structured view via JSON-LD.

Example for a product page:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Product",
  "name": "Pro Plan",
  "description": "Advanced analytics and priority support for growing teams.",
  "brand": "Glitched Goblet Apps",
  "offers": {
    "@type": "Offer",
    "priceCurrency": "USD",
    "price": "39.00",
    "availability": "https://schema.org/InStock"
  }
}
</script>

If you're not aware of JSON-LD, this helps Search engines generate richer results. It now also helps AI browsers and assistants answer questions like “how much is the Pro plan?” or “what features does this product have?” with fewer hallucinations.

Other highly effective candidates:

Article for blog posts / docs
FAQPage for FAQ pages
HowTo for step-by-step guides

You are not trying to game AI. You are just giving it the same obvious facts you want humans to see, in a format it can parse quickly. Nothing has really changed as far as SEO best practices, but now the payoff is bigger.

Make flows agent friendly

AI agents are already interacting with sites on behalf of users. Comet has drawn heat for making purchases on Amazon automatically, which triggered a cease-and-desist over “bots” transacting without being clearly identified as automated agents. (The Times of India)

That drama is a preview. User agents will get more active, not less. So you should design flows where the happy path is encoded in predictable forms and steps. Basic items like having a form with a clear submit button and clear headings go a long way.

Don't hide side effects behind weird hacks, and make critical actions confirmable and reversible. Avoid "click a random div and we silently sign you up for a newsletter" habits. If something important happens, let it be associated with a real control.

Critical actions are confirmable and reversible. Not even for AI agents, for users too! Confirm destructive actions with clear language (“You are about to delete all workspaces in this account”). Provide an easy “Undo” for non-security-sensitive operations.

You want the AI to be able to help a user cancel, upgrade, or complete checkout, without any hiccups. Making it reliable will help both humans and their copilots.

Anti-patterns that break AI copilots (and users)

These are worth hunting down in your app:

Endless div soup with no headings - If a summarizer cannot tell which block is the main content vs sidebar, your UX is already shaky.

Fake buttons and links - span with onClick and no role, no keyboard accessibility, no semantics. AI and assistive tech both struggle to treat it as an action.

Infinite scroll everything with no anchors - Feeds and timelines make sense. Your legal or pricing information should not be buried 8 screens down inside an endless list.

Critical text in images with no alt text - AI might do OCR, but do not rely on it. Terms, prices, and “call us” info should exist in real text.

Over-clever dark patterns - Trying to hide cancel flows behind 8 cutesy steps is exactly the kind of thing users will outsource to their browser with “Just cancel this for me”.

If an AI cannot easily find the main purpose of the page and the main action, your users probably cannot either.

How to test your site against AI browsers today

You can get a lot of signal in under an hour.

With Edge + Copilot

Open your page in Edge.
Open the Copilot sidebar.
Ask: “Summarize this page,” or “What is the main thing I can do here?” or “How do I cancel my subscription from this page?”

If the answers are vague or wrong, work on semantics, headings, and copy. Copilot’s summarization is explicitly designed to work off page content, so failures here are a clear red flag.

With Chrome + Gemini

Chrome is rolling out Gemini assistance in the browser that can explain complex pages and help people get more out of them.

Use any current Gemini-in-Chrome integration you have access to.
Ask similar questions as above. Also “What is this page for?” or “How do I sign up?”

Try an agentic browser

I promise this isn't advertising. But to test an agentic browser, you'll need to install one:

Perplexity Comet, which frames itself as “browse with intelligence” and can automate tasks. (Perplexity AI)
Opera Neon, which runs Neon Do and other local task features that act inside pages. (Opera Neon)

Try asking it to “find and show me the pricing on this site.” or “Help me upgrade my plan.” Pay attention to where the agent gets confused. Those are the spots where your semantics and information architecture need work.

Security and terms: do not ignore the policy fights

The Amazon vs Comet conflict is a warning shot. Amazon claims that Comet’s automated purchasing violated its terms and could degrade the shopping experience. (The Times of India)

That means platforms will try to limit or shape how agents behave. You must be clear about what you allow automated agents to do on your own site, especially for high-risk actions like financial operations. At minimum you should log user agent patterns for suspicious automation. Protect sensitive operations with appropriate auth, rate limiting, and challenges. And document what is allowed in your terms if you expect automation (for example, internal RPA, legitimate scraping, or assistive agents).

The real takeaway

AI browsers are glorified UX linters

AI browsers are not magic. They are just very aggressive consumers of the same things you should already care about.

Clean semantic HTML
Clear copy and labels
Predictable flows
Honest navigation and actions
Structured data where it matters

If your page is understandable to a tired human, screen reader, and a summarizer, then you are in a good place. The game is not “optimize for AI” in some hacky SEO way. The game is and always has been to:

Make the purpose and actions of every page so obvious that a copilot sitting next to your user can explain and operate it without guessing.

Do that, and you are not just ready for AI browsers. You are building a product that respects your users’ time and attention.

“Assign to Copilot” Explained: What GitHub’s Coding Agent Actually Does

Kaemon Lovendahl — Mon, 15 Sep 2025 20:03:38 +0000

Intro

GitHub quietly turned the humble Issue into a launch button. With Assign to Copilot, you can hand a ticket to an autonomous coding agent that spins up a clean environment, reads your repo context, drafts a branch, opens a PR, runs your checks, and then waits for your review like a polite junior dev who actually likes chores. The flow is still GitHub-native commits, PR, discussion. Just with a new teammate taking the first swing. (GitHub Docs)

tl;dr: If you can describe a task clearly in an Issue, Copilot can usually turn it into a draft PR you can steer to done. Think “small features, bug fixes, tests, docs.” Not “quarterly architecture rewrite.” (The GitHub Blog)

What It Is (and how it behaves)

The coding agent is different from IDE chat or “agent mode.” Instead of editing files on your machine, it works in the background on GitHub. You assign an Issue (or start a task from the new Agents panel), and Copilot creates a copilot/* branch from your default branch, pushes commits as it works, and opens a draft PR for you to review. When you leave PR comments, “rename this prop,” “add tests for the edge case,” it spins a fresh session to apply changes and pushes another commit. The whole trail is visible in session logs linked from the PR, so you can see what it tried and why. (GitHub Docs)

The agent runs in a GitHub Actions powered sandbox. It can build, test, and lint. Whatever your repo already enforces in CI. You stay in the driver’s seat the whole time: Copilot can’t approve or merge its own PRs, and it only pushes to branches that begin with copilot/. Your branch protections, required checks, and CODEOWNERS still rule. (GitHub Docs)

Where it actually helps

In practice, Copilot is great at the work we chronically under-prioritize. Tightening test coverage, filing down lint cliffs, stitching in small UX improvements, writing first drafts of docs, or implementing tidy incremental features that follow existing patterns. If your repo has clear instructions (how to build, how to test, where to put things), it plays ball immediately. And now that GitHub’s Agents panel lets you kick off or monitor tasks from any page on GitHub (or from Mobile and VS Code), it’s easier to sprinkle these hand-offs into your day without losing focus. (The GitHub Blog)

One tiny but important behavior note: when you assign the Issue, Copilot sees the title, description, and any comments that exist at that moment. If requirements change later, don’t keep talking to the Issue, move the conversation to the PR so the agent will act on it. That small habit shift prevents “why didn’t it listen?” moments. (GitHub Docs)

Guardrails you should know about

Security and control are very intentionally conservative here. The agent works inside a restricted environment with a firewall, it has read-only access to your repo until it creates that copilot/* branch, and it only responds to people who have write access to the repository. You’ll also see governance footprints you’d expect in an enterprise setting. PRs from Copilot arrive as drafts, workflows won’t run until a human with write access approves them, and the person who asked Copilot to create the PR can’t be the one who approves it. It’s deliberately built to play nice with rulesets and audits, not bypass them. (GitHub Docs)

Costs, plans, and the “premium request” model

Two knobs matter for budgeting: plan and premium requests. The feature is available on Copilot Pro, Pro+, Business, and Enterprise. Paid plans include a monthly allowance of premium requests and the coding agent consumes one premium request per session. Each time you start a run (or trigger a new revision cycle from PR feedback), that’s one session. If you blow past the included allowance and you’ve enabled paid usage, overage is \$0.04 per premium request. You can cap spend with budgets so it never surprises finance. (GitHub Docs)

If you’ve been away from Copilot for a minute, note the 2025 shift: premium-request billing is now live (counters reset monthly at 00:00 UTC), and different models can apply multipliers in chat, but the coding agent itself is a flat “1 request per session.” (GitHub Docs)

Limits and rough edges (so you don’t find them the hard way)

It’s scoped to a single repo and opens one PR per task. It starts from your default branch, not an arbitrary feature branch you’re already working on. So treat it like an auxiliary teammate, not a merge-conflict machine. It doesn’t use self-hosted runners, and it won’t operate across multiple repos in one run (though you can extend context via MCP if you really need to). None of these are deal-breakers, but they do push you toward small, crisp tickets and a CI that tells the truth. (GitHub Docs)

The Glitched Goblet take

The magic here isn’t that Copilot writes code. (we’ve had that all year.) It’s that GitHub now owns the “turn Issue -> PR” loop with guardrails your org already understands. Treat it like a well-behaved junior. Feed it tight scope, let CI be the hard boundary, and keep feedback in the PR. You’ll ship more of the “ought to do” work without torching your attention span and you’ll still have time to chase the spicy tickets that need a human brain.

For a better experience, and more blog posts about tech and Magic: The Gathering. Come visit me at my blog! glitchedgoblet.blog

Build a Desktop-Friendly Podcast App with Next.js

Kaemon Lovendahl — Mon, 25 Aug 2025 18:46:35 +0000

Intro

I love podcasts, they're a great way to keep up with hobbies and entertainment without needing to watch a screen. I usually listen to them on my phone but often find swapping from bluetooth to using my desktop audio annoying.

So today, I thought it'd be bun to build a tiny but legit podcast desktop app with Next.js. We’ll keep it focused: search for shows, list episodes, and wire up an accessible audio player with play, stop, and fast-forward/rewind (plus a scrubber and keyboard shortcuts). You can use it in the browser as a PWA.

tldr; Scaffold a Next.js app, proxy iTunes Search API to find shows, parse each show’s RSS for episodes, and ship an accessible <audio> player with play/stop/skip and keyboard controls (Space/J/K/L).

Setting Up / Prerequisites

We’ll use Next.js App Router so we get file-based server routes for free, and we’ll keep dependencies light. For discovery we’ll hit the iTunes Search API (no key required, great for demos). For episodes, we’ll fetch each podcast’s RSS feed and extract enclosure URLs (the actual audio files) with fast-xml-parser.

Why this setup?

Putting search and RSS fetch on the server avoids CORS headaches, keeps feed URLs off the client, and lets us normalize shapes.
The native <audio> element is battle-tested, accessible, and good enough for a basic player.
You can swap providers later (e.g., PodcastIndex) with minimal code changes.

# 1) Create the app
npx create-next-app@latest deskcaster --typescript --eslint --app

cd deskcaster

# 2) Install RSS parser
pnpm add fast-xml-parser
# or: npm i fast-xml-parser
# or: yarn add fast-xml-parser

Implementation Steps

Add Types

First, let's define small TypeScript types file for search results and episodes. Types make the API layer and UI wiring harder to mess up, and they document the contract we expect from third-party responses.

In types/podcast.ts

export type PodcastSearchItem = {
  id: string // Stable identifier for a podcast (collectionId/trackId/feedUrl)
  title: string // Human-readable show title
  image: string // Square artwork URL (iTunes gives multiple sizes)
  feedUrl: string // The podcast's RSS feed URL (used to fetch episodes)
}

export type Episode = {
  id: string // Stable-ish ID (guid where possible)
  title: string // Episode title
  audioUrl: string // Direct enclosure URL (mp3/aac/etc.)
  pubDate?: string // Publish date (optional; many feeds omit/format oddly)
  duration?: string | number // itunes:duration can be "01:23:45" or seconds
}

Tip: keep these minimal. Real feeds vary wildly, so start small, extend later.

Search API (server) — proxy iTunes Search

Instead of calling iTunes from the browser (CORS, shape drift), we create a server route that accepts ?q= and returns a normalized list of shows. Normalization = consistent keys, fewer surprises in the UI. Caching (revalidate) keeps it snappy.

In app/api/search/route.ts

import { NextResponse } from 'next/server'
import type { PodcastSearchItem } from '@/types/podcast'

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url)
  const q = (searchParams.get('q') || '').trim()

  // Early return for empty search to avoid unnecessary network calls.
  if (!q) {
    return NextResponse.json({ results: [] })
  }

  // iTunes Search API: no auth required; "media=podcast" helps target shows.
  const url = `https://itunes.apple.com/search?media=podcast&term=${encodeURIComponent(q)}`

  // `next.revalidate` enables ISR-style caching in production.
  const res = await fetch(url, { next: { revalidate: 60 } })
  if (!res.ok) {
    // Fail quiet with empty results; keeps the client simple.
    return NextResponse.json({ results: [] })
  }

  const data = await res.json()

  // Normalize result shape and drop items lacking a feed URL.
  const results: PodcastSearchItem[] = (data?.results || [])
    .filter((r: any) => !!r.feedUrl)
    .map((r: any) => ({
      // Prefer numeric IDs; fall back to feedUrl for stability if needed.
      id: String(r.collectionId ?? r.trackId ?? r.feedUrl),
      title: r.collectionName || r.trackName || 'Untitled',
      // Prefer the larger artwork when available.
      image: r.artworkUrl100 || r.artworkUrl600 || '',
      feedUrl: r.feedUrl,
    }))

  return NextResponse.json({ results })
}

FYI:

iTunes returns both shows and episodes; media=podcast nudges it to collections.
Some items don’t include feedUrl so we filter them out.
revalidate: 60 caches responses for a minute in production.

Episodes API (server) — fetch & parse RSS

Once a user picks a show, we need its episodes. The source of truth is the RSS feed. We fetch the XML server-side, parse it, and extract enclosures (audio URLs). Doing this server-side avoids CORS and lets us handle weird feed formats in one place.

In app/api/episodes/route.ts

import { NextResponse } from 'next/server'
import { XMLParser } from 'fast-xml-parser'
import type { Episode } from '@/types/podcast'

export async function GET(req: Request) {
  const { searchParams } = new URL(req.url)
  const feedUrl = searchParams.get('feedUrl')

  if (!feedUrl) return NextResponse.json({ episodes: [] })

  // Many hosts expect a UA; sending one improves success rates.
  const res = await fetch(feedUrl, {
    headers: { 'User-Agent': 'NextPodcastDemo/1.0 (+https://example.com)' },
    // Consider `next: { revalidate: 300 }` later for caching feeds.
  })

  if (!res.ok) return NextResponse.json({ episodes: [] })

  const xml = await res.text()

  // Configure parser to keep attribute values (e.g., enclosure url="...").
  const parser = new XMLParser({
    ignoreAttributes: false,
    attributeNamePrefix: '', // Make attributes readable without "@_"
  })

  const parsed = parser.parse(xml)

  // Most podcasts are RSS 2.0: items live at rss.channel.item[]
  let items: any[] = parsed?.rss?.channel?.item ?? []

  // Atom fallback (rarer for podcasts). Entries may structure links differently.
  if (!Array.isArray(items) || items.length === 0) {
    const entries = parsed?.feed?.entry
    if (Array.isArray(entries)) items = entries
  }

  const episodes: Episode[] = items
    .map((item: any, idx: number) => {
      // Title can be in <title> or itunes:title; default to "Episode N" if missing.
      const title = item?.title || item?.['itunes:title'] || `Episode ${idx + 1}`
      // Publish date fields vary across feeds.
      const pubDate = item?.pubDate || item?.published || item?.updated

      // The actual audio lives in an "enclosure" with a url attribute.
      // Some Atom feeds provide a <link rel="enclosure" href="..."/>.
      const enclosure = item?.enclosure
      const audioUrl =
        (typeof enclosure === 'object' ? enclosure?.url : undefined) ||
        (Array.isArray(item?.link)
          ? item.link.find((l: any) => l?.rel === 'enclosure')?.href
          : undefined) ||
        ''

      const duration = item?.['itunes:duration']

      // If there's no playable audio URL, skip the item.
      if (!audioUrl) return null

      return {
        // Favor GUID text; fall back to index as last resort.
        id: String(item?.guid?.['#text'] || item?.guid || idx),
        title: String(title),
        audioUrl: String(audioUrl),
        pubDate: pubDate ? String(pubDate) : undefined,
        // Keep duration raw; you can normalize later if needed.
        duration: duration ?? undefined,
      } as Episode
    })
    // Remove nulls from skipped items (no audio URL).
    .filter(Boolean) as Episode[]

  return NextResponse.json({ episodes })
}

Feeds are LAWLESS. Expect odd shapes, missing fields, HTML in titles, etc.

Audio Player component (play/stop/skip + a11y & keys)

We’ll wrap <audio> with controls for Play/Pause, Stop (pause + reset to 0), Rewind 15s, Fast-forward 30s, a scrubber, time labels, and keyboard shortcuts (Space, J/K/L—YouTube-style). This keeps the UI familiar and accessible.

In components/AudioPlayer.tsx

'use client'

import { useEffect, useRef, useState } from 'react'

type Props = {
  src: string | null // Current episode audio URL (null = nothing selected)
  title?: string | null // Displayed above controls
  skipBackSec?: number // How far to rewind (default 15)
  skipFwdSec?: number // How far to jump forward (default 30)
}

export default function AudioPlayer({ src, title, skipBackSec = 15, skipFwdSec = 30 }: Props) {
  // Keep a direct handle on the <audio> element.
  const audioRef = useRef<HTMLAudioElement | null>(null)

  // UI state derived from the audio element.
  const [isPlaying, setIsPlaying] = useState(false)
  const [cur, setCur] = useState(0) // currentTime (seconds)
  const [dur, setDur] = useState(0) // duration (seconds)

  // When `src` changes: load and auto-play the new episode.
  useEffect(() => {
    const audio = audioRef.current
    if (!audio || !src) return

    audio.src = src
    audio.load()

    // Attempt autoplay with a catch to avoid unhandled promise rejections on blocked autoplay.
    audio
      .play()
      .then(() => setIsPlaying(true))
      .catch(() => setIsPlaying(false))

    // Reset progress back to 0 for the new track.
    setCur(0)
  }, [src])

  // Wire up time/duration/ended listeners once.
  useEffect(() => {
    const audio = audioRef.current
    if (!audio) return

    const onTime = () => setCur(audio.currentTime)
    const onLoaded = () => setDur(audio.duration || 0)
    const onEnded = () => setIsPlaying(false)

    audio.addEventListener('timeupdate', onTime)
    audio.addEventListener('loadedmetadata', onLoaded)
    audio.addEventListener('ended', onEnded)

    return () => {
      audio.removeEventListener('timeupdate', onTime)
      audio.removeEventListener('loadedmetadata', onLoaded)
      audio.removeEventListener('ended', onEnded)
    }
  }, [])

  // Global keyboard shortcuts: Space (toggle), J (-), K (pause), L (+)
  // We skip when the user is typing in inputs to avoid surprise behavior.
  useEffect(() => {
    const onKey = (e: KeyboardEvent) => {
      const tag = (e.target as HTMLElement)?.tagName
      // Add other tags here to prevent events from getting caught
      if (tag === 'INPUT' || tag === 'TEXTAREA') return

      if (e.code === 'Space') {
        e.preventDefault() // Prevent page scroll on space
        toggle()
      } else if (e.key.toLowerCase() === 'j') {
        e.preventDefault()
        skip(-skipBackSec)
      } else if (e.key.toLowerCase() === 'k') {
        e.preventDefault()
        pause()
      } else if (e.key.toLowerCase() === 'l') {
        e.preventDefault()
        skip(skipFwdSec)
      }
    }

    window.addEventListener('keydown', onKey)
    return () => window.removeEventListener('keydown', onKey)
  }, [skipBackSec, skipFwdSec, isPlaying])

  // Control helpers
  const play = () => {
    const audio = audioRef.current
    if (!audio) return
    audio
      .play()
      .then(() => setIsPlaying(true))
      .catch(() => setIsPlaying(false))
  }

  const pause = () => {
    const audio = audioRef.current
    if (!audio) return
    audio.pause()
    setIsPlaying(false)
  }

  // Stop = pause + reset progress back to 0
  const stop = () => {
    const audio = audioRef.current
    if (!audio) return
    audio.pause()
    audio.currentTime = 0
    setIsPlaying(false)
  }

  const toggle = () => (isPlaying ? pause() : play())

  // Jump forward/backward by delta seconds; clamp within [0, duration].
  const skip = (delta: number) => {
    const audio = audioRef.current
    if (!audio) return
    const max = dur || audio.duration || 0
    const next = Math.min(Math.max(0, audio.currentTime + delta), max)
    audio.currentTime = next
  }

  // Seek handler for the range input (scrubber).
  const onScrub = (e: React.ChangeEvent<HTMLInputElement>) => {
    const audio = audioRef.current
    if (!audio) return
    const next = Number(e.target.value)
    audio.currentTime = next
    setCur(next)
  }

  // Format seconds as M:SS or H:MM:SS.
  const fmt = (s: number) => {
    if (!isFinite(s)) return '0:00'
    const h = Math.floor(s / 3600)
    const m = Math.floor((s % 3600) / 60)
    const sec = Math.floor(s % 60)
    const mm = h > 0 ? String(m).padStart(2, '0') : String(m)
    const ss = String(sec).padStart(2, '0')
    return h > 0 ? `${h}:${mm}:${ss}` : `${mm}:${ss}`
  }

  return (
    <div
      role="region" // Landmark region for quick SR navigation
      aria-label="Podcast audio player"
      style={{ border: '1px solid #333', padding: 12, borderRadius: 12 }}
    >
      {/* Keep the <audio> element but hide native controls in favor of our UI */}
      <audio ref={audioRef} aria-label="audio element" />

      <div style={{ marginBottom: 8 }}>
        <strong>{title || 'No episode selected'}</strong>
      </div>

      {/* Primary controls */}
      <div style={{ display: 'flex', gap: 8, flexWrap: 'wrap' }}>
        <button onClick={() => skip(-skipBackSec)} aria-label={`Rewind ${skipBackSec} seconds`}>
          ↺ {skipBackSec}s
        </button>
        <button onClick={toggle} aria-label={isPlaying ? 'Pause' : 'Play'}>
          {isPlaying ? '⏸ Pause' : '▶️ Play'}
        </button>
        <button onClick={stop} aria-label="Stop and reset">
          ⏹ Stop
        </button>
        <button onClick={() => skip(skipFwdSec)} aria-label={`Fast forward ${skipFwdSec} seconds`}>
          {skipFwdSec}s ↻
        </button>
      </div>

      {/* Scrubber + time labels */}
      <div style={{ marginTop: 10 }}>
        {/* Screen-reader-only label for the range input */}
        <label htmlFor="scrub" className="sr-only">
          Seek
        </label>

        <input
          id="scrub"
          type="range"
          min={0}
          max={dur || 0}
          step={1}
          value={Math.min(cur, dur || 0)}
          onChange={onScrub}
          aria-valuemin={0}
          aria-valuemax={dur || 0}
          aria-valuenow={Math.floor(cur)}
          aria-label="Seek position"
          style={{ width: '100%' }}
        />

        <div style={{ display: 'flex', justifyContent: 'space-between', fontSize: 12 }}>
          <span>{fmt(cur)}</span>
          <span>{fmt(dur || 0)}</span>
        </div>
      </div>

      <p style={{ marginTop: 8, fontSize: 12, opacity: 0.8 }}>
        Tips: <kbd>Space</kbd> = Play/Pause, <kbd>J</kbd> = Rewind, <kbd>K</kbd> = Pause,{' '}
        <kbd>L</kbd> = Fast-forward
      </p>
    </div>
  )
}

Accessibility nits to care about:

Buttons have aria-labels; the player uses role="region" with a label.
The range input is labelled and keyboard-operable.
Focus rings: add a tiny global style so users can see where they are.

In app/globals.css

button:focus,
input:focus {
  outline: 2px solid #5b9aff;
  outline-offset: 2px;
}

Hook it up in the main page (search -> show -> episodes -> play)

This is the glue: a search box calls /api/search, clicking a show fetches /api/episodes, and clicking an episode pipes audioUrl into the player. We keep everything in one page for clarity; in a real app, you’d split into routes/components.

In app/page.tsx

'use client'

import { useState } from 'react'
import type { PodcastSearchItem, Episode } from '@/types/podcast'
import AudioPlayer from '@/components/AudioPlayer'

export default function HomePage() {
  // Local UI state: search input + loading status
  const [term, setTerm] = useState('')
  const [loading, setLoading] = useState(false)

  // Search results (podcasts), selected podcast, episodes, and currently-playing episode
  const [results, setResults] = useState<PodcastSearchItem[]>([])
  const [selected, setSelected] = useState<PodcastSearchItem | null>(null)
  const [episodes, setEpisodes] = useState<Episode[]>([])
  const [current, setCurrent] = useState<Episode | null>(null)

  // Perform podcast search via our server proxy route.
  const doSearch = async (e?: React.FormEvent) => {
    e?.preventDefault()
    setLoading(true)
    try {
      const res = await fetch(`/api/search?q=${encodeURIComponent(term)}`)
      const data = await res.json()

      setResults(data.results || [])

      // Clear previous selection/episodes when a new search runs.
      setSelected(null)
      setEpisodes([])
      setCurrent(null)
    } finally {
      setLoading(false)
    }
  }

  // When a podcast is chosen, fetch its RSS episodes.
  const loadEpisodes = async (pod: PodcastSearchItem) => {
    setSelected(pod)
    setEpisodes([])
    setCurrent(null)

    const res = await fetch(`/api/episodes?feedUrl=${encodeURIComponent(pod.feedUrl)}`)
    const data = await res.json()
    setEpisodes(data.episodes || [])
  }

  // Set the chosen episode (the player will auto-play on `src` change).
  const pickEpisode = (ep: Episode) => setCurrent(ep)

  return (
    <main style={{ padding: 20, maxWidth: 1000, margin: '0 auto' }}>
      <h1>Podcast Desktop (Next.js)</h1>

      {/* SEARCH FORM */}
      <form onSubmit={doSearch} aria-label="Search podcasts" style={{ marginBottom: 16 }}>
        <label htmlFor="term" style={{ display: 'block', fontWeight: 600 }}>
          Search for a podcast
        </label>
        <div style={{ display: 'flex', gap: 8, marginTop: 6 }}>
          <input
            id="term"
            type="search"
            placeholder="e.g. data engineering"
            value={term}
            onChange={(e) => setTerm(e.target.value)}
            aria-label="Search term"
            style={{ flex: 1, padding: 8 }}
          />
          <button disabled={loading || term.trim().length === 0} type="submit">
            {loading ? 'Searching...' : 'Search'}
          </button>
        </div>
      </form>

      {/* RESULTS GRID */}
      {results.length > 0 && (
        <section aria-label="Search results" style={{ marginBottom: 24 }}>
          <h2 style={{ fontSize: 18 }}>Results</h2>
          <ul
            style={{
              display: 'grid',
              gridTemplateColumns: 'repeat(auto-fill, minmax(220px, 1fr))',
              gap: 12,
              listStyle: 'none',
              padding: 0,
            }}
          >
            {results.map((r) => (
              <li key={r.id}>
                {/* Button not link: this changes in-page UI state, not navigation */}
                <button
                  onClick={() => loadEpisodes(r)}
                  style={{
                    width: '100%',
                    textAlign: 'left',
                    border: '1px solid #333',
                    borderRadius: 12,
                    padding: 10,
                    display: 'flex',
                    gap: 10,
                    background: 'transparent',
                    cursor: 'pointer',
                  }}
                  aria-label={`Open ${r.title}`}
                >
                  {/* eslint-disable-next-line @next/next/no-img-element */}
                  <img
                    src={r.image}
                    alt="" // artwork is decorative; real alt text could repeat the title
                    width={64}
                    height={64}
                    style={{ borderRadius: 8, objectFit: 'cover' }}
                  />
                  <div>
                    <div style={{ fontWeight: 600 }}>{r.title}</div>
                    <div style={{ fontSize: 12, opacity: 0.8 }}>{r.feedUrl}</div>
                  </div>
                </button>
              </li>
            ))}
          </ul>
        </section>
      )}

      {/* EPISODE LIST */}
      {selected && (
        <section aria-label="Episodes">
          <h2 style={{ fontSize: 18, marginBottom: 8 }}>Episodes — {selected.title}</h2>

          {/* Simple loading state while the RSS is being parsed */}
          {episodes.length === 0 ? (
            <p>Loading episodes…</p>
          ) : (
            <ul style={{ listStyle: 'none', padding: 0, marginBottom: 20 }}>
              {episodes.map((ep) => (
                <li key={ep.id} style={{ marginBottom: 8 }}>
                  <button
                    onClick={() => pickEpisode(ep)}
                    style={{
                      width: '100%',
                      textAlign: 'left',
                      border: '1px solid #333',
                      borderRadius: 10,
                      padding: 10,
                      // Highlight the currently selected episode
                      background: current?.id === ep.id ? '#1a1a1a' : 'transparent',
                    }}
                    aria-label={`Play ${ep.title}`}
                  >
                    <div style={{ fontWeight: 600 }}>{ep.title}</div>
                    <div style={{ fontSize: 12, opacity: 0.8 }}>
                      {ep.pubDate ? new Date(ep.pubDate).toLocaleString() : '—'}
                      {ep.duration ? ` • ${ep.duration}` : ''}
                    </div>
                  </button>
                </li>
              ))}
            </ul>
          )}
        </section>
      )}

      {/* PLAYER */}
      <AudioPlayer
        src={current?.audioUrl ?? null}
        title={current?.title ?? null}
        skipBackSec={15}
        skipFwdSec={30}
      />
    </main>
  )
}

Why these UX choices?

Search resets selection to prevent stale episodes.
Episode selection autoplays—fast feedback.
Results use buttons (not links) because they change state within the page, not navigation.

A11y checklist for this app:

Every interactive element is reachable by Tab.
Labels/aria-labels exist where the visible text isn’t sufficient.
The player is a named region so screen readers can jump to it.

Next Steps

Make it a desktop app: Wrap with Tauri for a tiny native shell (fast, low RAM). In dev, point devPath to http://localhost:3000; in prod, point to your Next build output.
PWA install: Add a manifest and service worker so users can “Install app” on Windows/macOS/Linux.
Persistence: Save followed shows, last position per episode, and speed. Start with localStorage, graduate to SQLite.
Speed & volume controls: 0.75x/1x/1.5x/2x, volume slider, mute.
OPML import/export: Let users bring subscriptions from other apps.
Offline caching: Cache artwork and the current/next episode for commute-proof playback.
Transcripts: If feeds expose transcripts (or via a service), show them and sync highlights with timeupdate.
Legal/common sense: You’re streaming from public feed enclosures, not rehosting. Respect robots.txt and show branding/art as the publisher intends.

Outro

Even though it may look ugly, it's a clean baseline! Search shows, list episodes, and a friendly player with play/stop/skip and keyboard controls. Let me know what you think about it, and if you have any of your own tips or tricks for a desktop podcasting site.

As always I write these articles once a week on Mondays. Sometimes about code, other times about Magic: The Gathering! You can read more at The Glitched Goblet

Prompt Engineering for Agentic Development: Getting Exactly What You Want Part 2

Kaemon Lovendahl — Mon, 18 Aug 2025 19:59:25 +0000

Agent coding tools like Copilot aren’t just autocomplete for single files anymore, they can now build fullstack applications. They can reason across files, propose refactors, draft tests, even argue about architecture. But none of that matters if your asks are mush. The difference between “meh, plausible code” and “wow, exactly what I meant” is about prompt craftsmanship and quickly becoming a necessary skill.

This is a practical, opinionated guide to prompting for agentic project development. Leaning on patterns you’ll also see echoed in community gems like awesome-copilot, with a special focus on chatmodes (the “hats” you ask your AI to wear).

Why Prompting Structure Matters

Natural language is imprecise, while code is not. Even though coding agents are getting smarter by the month agentic systems fill in the gaps with their own assumptions, which can lead to unexpected results.:

If you don’t bound scope, agents invent scope.
If you don’t name constraints, they average the internet.
If you don’t share context, they’ll build generic, "just okay" solutions.

Rule 0: Treat language as an interface. Your prompt is the API contract. You state inputs, outputs, invariants, and success criteria.

The Durable Prompt Pattern

Use this spine for 90% of dev asks:

ROLE -> CONTEXT -> TASK -> CONSTRAINTS -> FORMAT -> ACCEPTANCE

ROLE (chatmode): the hat it should wear.
CONTEXT: code, file tree, conventions, dependencies.
TASK: action, not vibes. (“Implement”, “Refactor”, “Diagnose”.)
CONSTRAINTS: frameworks, patterns, performance, security, style.
FORMAT: how you want the result (code block, diff, checklist).
ACCEPTANCE: tests, examples, or explicit “done when” criteria.

Example:

Role: You are a refactoring assistant.
Context: Node 18, no 3rd-party CSV libs. Current function below.
Task: Reduce cognitive complexity of parseCsv() without changing behavior.
Constraints: Keep streaming interface, preserve error messages, time complexity ≤ current.
Format: Return a unified diff patch.
Acceptance: Include 3 table-driven Jest tests that pass on quoted fields, empty lines, and BOM.

This template prevents “model improv hour” and drives the agent toward the exact deliverable you need.

Chatmodes: Switch Hats, Change Outcomes

Currently with Copilot, you are able to define a chatmodes folder within .github at the root of your project. Right next to the workflows folder. From there you can define chatmodes by creating .md files describing a role for copilot to use. Once created, reload VS Code and you can select the chatmode from the Copilot chat interface.

Per awesome-copilot

Define chat behavior, available tools, and codebase interaction patterns within specific boundaries for each request

Same model, different behavior, if you name the mode. Five high-leverage modes for dev work:

Implementer
“Write the thing.” Great for scaffolds and boilerplate.
Ask for: code + minimal notes.
Explainer
“Teach me what this does (and where it breaks).”
Ask for: concise summary, failure cases, complexity, example I/O.
Refactorer
“Improve clarity/perf without behavior change.”
Ask for: a diff + rationale bullets.
Bug Hunter
“Skeptically review for edge cases and defects.”
Ask for: numbered findings + repro snippets.
Spec Writer
“Write the contract before code.”
Ask for: structured requirements, API signatures, acceptance tests.

Pro tip: If an answer feels off, don’t just “ask again.” Switch modes. Explainer -> reveals misunderstanding. Bug Hunter -> pressure tests. Spec Writer -> aligns on the target before touching code.

Do’s and Don’ts (a.k.a. Prompt Hygiene)

Do

Bullet your asks. Models parse lists better than paragraphs.
Bound the canvas. “One function” vs. “new service” is a critical difference.
Show the neighborhood. Include file tree, key interfaces, or conventions.
Ask for a plan first when tasks are multi-step: “Give a 5-bullet plan, then wait.”
Prefer diffs over blobs for refactors, easier to review and revert.
Pin success. “Done when these tests pass” beats “looks good.”

Don’t

Don’t say “optimize” without an axis (latency, memory, readability).
Don’t stack 10 asks in one go, chain them.
Don’t rely on memory. Restate constraints in each thread/session.
Don’t copy-paste to prod. Run, test, and profile, treat AI code as code.

Prompt Smells (And What To Say Instead)

Vague Verb: “Improve this.” -> Specific Verb: “Reduce allocations, target ≤1 allocation per loop.”
Unbounded Scope: “Add analytics.” -> Scoped: “Emit pageview + timing via track() only on client routes.”
Context Starvation: “Write tests.” -> Contexted: “Jest + React Testing Library, existing jest.setup.ts below, mock network with MSW.”
Style Drift: “Build auth middleware.” -> “Match existing Result<T, E> pattern, no exceptions, return Unauthorized sentinel.”

Before -> Better -> Best (Concrete Examples)

Example A: API Endpoint

Before: “Write a POST /weather endpoint.”
Better: “Express TS POST /weather accepts { city }, calls OpenWeatherMap, returns { temp, conditions }, handles network errors.”
Best:
- Role: Implementer
- Task: Add POST /weather
- Context: Node 20, zod for validation, fetch available, error style uses ProblemDetails.
- Constraints: Timeout 2s, no retries, log X-Request-Id.
- Format: Code block + 3 Jest tests (happy path, timeout, 400 invalid city).
- Acceptance: Tests pass, function pure except I/O.

Example B: Refactor Without Behavior Change

Before: “Clean this file.”
Better: “Refactor for readability.”
Best: “Refactor priceCalculator.ts to lower cognitive complexity (≤10 per function). Don’t change numerical results. Return a unified diff, then list any renamed helpers.”

Iteration as a Feature, Not a Failure

Agentic systems thrive on tight feedback loops. Treat the model like an eager junior dev:

Draft: “Give me a minimal first pass.”
Constrain: “Great—consolidate error branches and add input guards.”
Harden: “Now property-based tests for edge cases.”
Polish: “Docstring each public function with examples.”

Each turn adds a constraint or acceptance check. You’re not “wasting prompts”, you’re converging.

Make It Verifiable

Ask for artifacts that prove alignment, not paragraphs that claim it:

Diffs, not dumps.
Tests, not promises.
Bench scripts, not anecdotes.
Threat notes, not “we considered security.”

If it matters, make it machine-checkable. Make it verify endpoints with curl commands, or have it run unit tests.

A Mini Cheat Sheet You Can Paste

ROLE: Implementer / Explainer / Refactorer / Bug Hunter / Spec Writer
CONTEXT: File tree, key snippets, conventions
TASK: One clear verb and object
CONSTRAINTS: Frameworks, patterns, perf/security bounds
FORMAT: Code block, diff, checklist, table
ACCEPTANCE: Tests/examples/metrics that define “done”

Example skeleton:

You are a <MODE>.
Context: <FILES/CONVENTIONS/SNIPPETS>.
Task: <ACTION>.
Constraints: <RULES/BOUNDS>.
Format: <DIFF | CODE + TESTS | CHECKLIST>.
Acceptance: <TESTS/CRITERIA>.

Final Word

Agentic development isn’t “let the robot figure it out.” It’s you steering a powerful collaborator with crisp contracts. Name the hat (chatmode), bound the canvas, feed real context, and anchor to verifiable acceptance. Do that, and your copilot stops guessing—and starts delivering exactly what you asked for. If you're interested in reading more of my thoughts, check out my blog at The Glitched Goblet.

Prompt Engineering for AI-Driven Web Apps: A Spring Boot + React Storefront Example

Kaemon Lovendahl — Mon, 04 Aug 2025 13:35:52 +0000

Intro

Crafting great prompts is the secret sauce that turns a generic LLM into your personal full-stack engineer. Creating structured instructions are the difference between a disjointed mess and a functional app. In this tutorial, we’ll build a basic storefront app with Spring Boot + Maven on the backend and React + TypeScript on the fronted all through the lens of prompt engineering! You’ll see how to chunk your asks, set roles and constraints, and iterate for polish.

tldr; Learn the core prompt-design patterns (role, scope, format, iteration) and apply them step by step to generate a cohesive application.

Prompting Steps

1. Establish the LLM’s Role & Scope

PATTERN: Start by telling the model who it is and what you need.

This sets the tone and context for the entire interaction. It'll help the model understand the framework, language, and libraries you want to use and avoid unnecessary follow-up questions. This first prompt will be for the backend. Once the backend is scaffolded, we can switch to the frontend.

You are StorefrontBot, a backend engineer. Generate a Maven `pom.xml` for a Spring Boot 3.2 project that exposes a REST API for products. Use Java 21 and include dependencies for Spring Web, Spring Data JPA, and H2 database.

Assigning a persona (“StorefrontBot”) sets tone and specifying exact framework versions and dependencies avoids follow-up drift.

2. Specify Exact Format & Style

PATTERN: Instruct the model on code style, output format, and packaging.

Let the model know how you want the code structured, what annotations to use, and how to format the output. This reduces the need for manual cleanup later.

– Use Lombok for getters/setters (`@Data`).
– Package structure: `com.example.storefront`.
– Wrap all code in Markdown triple backticks with language tags.
– Omit explanations—only the code.

This prevents commentary bloat and ensures the snippet drops in without manual cleanup.

3. Chunk Tasks into Numbered Steps

PATTERN: Break complex requests into a numbered list so the LLM can tackle each part predictably.

Specifying subtasks helps the model focus on one piece at a time, reducing the chance of hallucinations or missing details. A lot of this is about guiding the model to produce a coherent output without overwhelming it with too much at once.

Please perform the following steps:

1. Return only the `pom.xml` content with the dependencies mentioned.
2. Create a `Product` JPA entity (fields: id, name, description, price).
3. Generate a `ProductRepository` interface.
4. Write a `ProductController` with a `/api/products` GET endpoint.

Numbered subtasks reduce hallucinations and give you bite-sized review points.

4. Prompt Example & Few-Shot (Optional)

PATTERN: Provide a tiny example of desired output for edge-cases or complex blocks.

This could go before the numbered steps as an additional style, but I usually like to do this afterwards to avoid overwhelming the model with too much context at once. You can also include this as a subtask in the list if you prefer.

Example output for the controller method:

@GetMapping("/api/products")
public List<Product> listProducts() {
    return repository.findAll();
}

5. Frontend Scaffold via Prompt

PATTERN: Switch personas and repeat the pattern for your React UI.

You are FrontendBot, a React/TypeScript developer. Scaffold a Vite + React project that fetches `/api/products` and displays them in a table. Use `react-query` for data fetching, type definitions via Zod, and Tailwind CSS for basic styling.

6. Iterate & Refine

PATTERN: When the first pass misses something, ask for targeted adjustments.

The controller lacks exception handling. Please add a `@ControllerAdvice` global handler that returns `404` for missing products and `500` for other errors, with JSON error payload `{ "error": "..."}`

This keeps the context tight and focuses the model on one concern at a time.

Warning: I personally avoid asking the model to just "fix the code" or "improve the app" without specifics. It often leads to hallucinations or irrelevant changes. Always be explicit about what you want fixed and how it should be fixed.

Tips & Tricks

Here are some pro moves to nail your prompts and dodge hallucinations:

Explicit “I don’t know” fallback: Include If you’re unsure, respond with “I don’t know” in your prompt to force honesty on unknowns.
Schema-driven outputs: Ask for JSON that matches a Zod or JSON Schema. It's easier to validate and parse.
Step-by-step verification: Request the model to List the steps you’ll take, then wait for my approval before generating code.
Few-shot anchoring: Provide 1–2 examples of correct code blocks or API responses to lock in style.

Not sure where to start?

Not sure where to start with an app? Try asking the model to generate a prompt based around what you'd like to be built:

You are PromptMaster, an expert in generating prompts for AI-driven web apps. Create a prompt that will generate a full-stack storefront web application.

Then review the prompt and tweak it to your liking. This can help you get a solid foundation to build on.

Outro

And there you have it! By layering clear roles, numbered tasks, strict formatting rules, and iterative refinements, you can have any modern LLM boss-mode your web app stack into place. Give it a spin, tweak your own prompts, and let AI handle the boilerplate so you can focus on features that actually matter. If this guide lit up your workflow, share it around or drop your go-to prompt patterns in the comments! Let’s keep the convo going!

Build a RAG Chatbot with Next.js 14, Pinecone & the OpenAI Responses API

Kaemon Lovendahl — Mon, 28 Jul 2025 17:42:54 +0000

Intro

Getting a “ChatGPT for my docs” into prod used to feel like tape and prayers. In 2025 everything finally snaps together: Next.js 14 App Router, the Vercel AI SDK’s useChat hook for instant streaming UI, OpenAI’s Responses API for agent-style calls, and Pinecone (or pgvector) for retrieval. Add Fluid Compute so your Node functions stay warm, and you’ve got a latency-friendly RAG bot that still fits the hobby budget. (AI SDK, OpenAI, Vercel)

tldr; We bootstrap a Next app, chunk + embed Markdown, shove vectors into Pinecone, wire a LangChain RAG chain that calls the Responses API, and deploy on Vercel. Copy-paste the code below and you’ll have a docs bot humming before your coffee hits optimal drinkability.

Setting Up / Prerequisites

What	Why
Node 20 + pnpm	Modern fetch for both OpenAI & Pinecone.
OpenAI account with Responses API enabled	Single endpoint = chat + tool use. (OpenAI)
Pinecone Starter tier	2 GB / 2 M writes / 1 M reads free—~300 k vectors. (Pinecone, Reddit)
Vercel Pro (optional)	Turns on Fluid Compute; Hobby works but with lower CPU quotas. (Vercel)

npx create-next-app@latest rag-bot --app
cd rag-bot

pnpm add openai vercel-ai langchain @langchain/openai @langchain/pinecone \
          @pinecone-database/pinecone @ai-sdk/react

# if you prefer Postgres later
# pnpm add pg pgvector

Create .env.local:

OPENAI_API_KEY=sk-...
PINECONE_API_KEY=...
PINECONE_INDEX_NAME=docs-test

1. Ingest & Embed Your Markdown

scripts/ingest.ts

The ingest script reads Markdown files, splits them into manageable chunks, embeds them with OpenAI’s text-embedding-3-small model, and stores the vectors in Pinecone. This sets up the vector store for retrieval later.

import fs from 'node:fs/promises'
import path from 'node:path'
import { RecursiveCharacterTextSplitter } from '@langchain/textsplitters'
import { OpenAIEmbeddings } from '@langchain/openai'
import { Pinecone } from '@pinecone-database/pinecone'
import { PineconeStore } from '@langchain/pinecone'

const docsPath = path.join(process.cwd(), 'docs-test')
const files = await fs.readdir(docsPath)

const splitter = new RecursiveCharacterTextSplitter({ chunkSize: 1_000, chunkOverlap: 100 })
const texts: string[] = []

for (const file of files) {
  const raw = await fs.readFile(path.join(docsPath, file), 'utf8')
  texts.push(...(await splitter.splitText(raw)))
}

const embeddings = new OpenAIEmbeddings({ modelName: 'text-embedding-3-small' })
const pc = new Pinecone({ apiKey: process.env.PINECONE_API_KEY! })
const index = pc.Index(process.env.PINECONE_INDEX_NAME!)

await PineconeStore.fromTexts(texts, {}, embeddings, { pineconeIndex: index })
console.log('✅ Ingestion complete')

Why: RecursiveCharacterTextSplitter keeps chunks below the 8 k-token context while overlapping 100 chars for coherence. (LangChain) The text-embedding-3-small model is 20× cheaper than Ada-002—\$0.02 per M tokens. (OpenAI Platform)

Run once:

pnpm tsx scripts/ingest.ts

2. Re-hydrate the Vector Store in Runtime

lib/vectorStore.ts

import { PineconeStore } from '@langchain/pinecone'
import { OpenAIEmbeddings } from '@langchain/openai'
import { Pinecone } from '@pinecone-database/pinecone'

// We use `PineconeStore.fromExistingIndex` to load the vector store from the existing Pinecone index, which allows us to query it later in the RAG chain. ([LangChain][8])
export async function makeStore() {
  const embeddings = new OpenAIEmbeddings({ modelName: 'text-embedding-3-small' })
  const pinecone = new Pinecone()
  const pineconeIndex = pinecone.Index(process.env.PINECONE_INDEX_NAME!)

  return PineconeStore.fromExistingIndex(embeddings, {
    pineconeIndex,
    namespace: 'docs',
    maxConcurrency: 5,
  })
}

Why: fromExistingIndex expects (embeddings, cfg); get the order wrong and store.embeddings is undefined, crashing later. (LangChain)

3. Build the RAG Chain

The chain retrieves relevant documents from Pinecone and generates a response using OpenAI’s Responses API. It uses RunnableSequence to pipe the retrieval and generation steps together.

lib/rag.ts

import { RunnableSequence } from '@langchain/core/runnables'
import { ChatOpenAIResponses } from '@langchain/openai'
import { PineconeStore } from '@langchain/pinecone'

export async function makeChain(store: PineconeStore) {
  const retriever = store.asRetriever({ k: 4 })

  const model = new ChatOpenAIResponses({
    modelName: 'o3-large',
    temperature: 0.2,
    maxTokens: 512,
    streaming: true,
  })

  return RunnableSequence.from([
    async (input: string) => ({ docs: await retriever.invoke(input), input }),
    model,
  ])
}

RunnableSequence pipes retrieval → generation with minimal overhead. (LangChain)

4. API Route (Node.js Runtime)

Now we wire up the API route to handle chat requests. It reads the last message from the chat, retrieves relevant documents from Pinecone, and streams the response back to the client.

app/api/chat/route.ts

import { NextRequest } from 'next/server'
import { makeStore } from '@/lib/vectorStore'
import { makeChain } from '@/lib/rag'

export const runtime = 'nodejs' // Pinecone SDK needs core Node APIs :contentReference[oaicite:8]{index=8}

export async function POST(req: NextRequest) {
  const { messages } = await req.json()
  const question = messages.at(-1)?.content ?? ''

  const store = await makeStore()
  const chain = await makeChain(store)
  const stream = await chain.stream(question)

  return new Response(stream, { headers: { 'Content-Type': 'text/event-stream' } })
}

Edge vs Node: The Pinecone SDK imports node:stream, absent in Edge Runtime, so we stay on Node—cold starts are slightly higher but Fluid Compute still keeps instances warm. (Next.js, Vercel)

5. Streaming Chat UI

And finally, we create the chat UI using the useChat hook from the Vercel AI SDK. This hook manages the chat state and handles streaming responses from the API.

components/Chat.tsx

'use client'
import { useChat } from '@ai-sdk/react'

export default function Chat() {
  const { messages, input, handleInputChange, handleSubmit } = useChat({ api: '/api/chat' })

  return (
    <form onSubmit={handleSubmit} className="space-y-4">
      <ul className="space-y-2 max-h-[60vh] overflow-y-auto">
        {messages.map((m) => (
          <li key={m.id} className={m.role === 'user' ? 'text-right' : ''}>
            <span className="px-3 py-2 rounded-lg inline-block bg-zinc-800">{m.content}</span>
          </li>
        ))}
      </ul>
      <input
        value={input}
        onChange={handleInputChange}
        className="w-full px-3 py-2 rounded-lg bg-zinc-900"
        placeholder="Ask me about the docs…"
      />
    </form>
  )
}

useChat streams tokens over SSE and manages local state for you. (AI SDK, Vercel)

6. Deploy with Fluid Compute

vercel --prod

Fluid Compute keeps micro-VMs hot, caches bytecode, and allows in-function concurrency—cutting cold starts 30-60%. (Vercel)

Next Steps

Hybrid Search – combine pgvector for “last week” edits with Pinecone for the archive.
LangSmith Tracing – set LANGCHAIN_TRACING=true to debug prompts token-by-token.
Rerank – Pinecone’s new inference reranker boosts relevance without re-embedding. (Pinecone)
Upgrade to GPT-5 – arriving in August with stronger reasoning. (The Verge)

Cost Snapshot (July 2025)

Just to be clear on the budget, here’s a breakdown of the expected costs for running this RAG chatbot on Vercel with Pinecone and OpenAI:

Item	Cost
Embeddings: 100 k tokens × `text-embedding-3-small`	\$0.002 (OpenAI Platform)
Chats: 1 000 req × 1 800 tokens (in+out) on `o3-large`	≈ \$9 (token-based)
Pinecone Starter (≤2 GB)	Free (Pinecone)
Vercel Hobby	Free (Pro is \$20 if you need more CPU)

Outro

In ~150 lines you now have a warm-booting, vector-grounded chatbot that answers doc questions without hallucinations. Fork it, theme it, or bolt on extra tools and if you find a slick tweak, drop a comment. Happy hacking!

Do you like my posts? I post regularly on my Blog at glitchedgoblet.blog! If you want to read about Magic: The Gathering EDH/Commander Deck Techs, or other dev related topics, follow me there!

From Notebook to Model: A Practical Guide to Jupyter for Machine Learning

Kaemon Lovendahl — Mon, 16 Jun 2025 20:06:18 +0000

Intro

Want to train a model without installing a hulking IDE or writing a separate script for every experiment? Jupyter notebooks let you mix runnable code, notes, and pretty plots in one share‑able file. In this guide we’ll spin up a notebook, load data, build a logistic regression classifier, and visualize the results. No sweat!

tldr; We’ll install Jupyter with pip, crack open a notebook, wrangle a CSV in pandas, train & evaluate a scikit‑learn model, and chart its performance. All inside a single .ipynb. You’ll finish with a repeatable workflow you can fork for any ML idea.

Setting Up / Prerequisites

Python ≥ 3.9 (use pyenv or the official installer)
pip or conda package manager
Virtual environment (e.g., python -m venv venv or conda create -n ml-jupyter python=3.11)
A terminal with git (optional, for dataset download)
The following Python packages:

pip install jupyterlab pandas scikit-learn matplotlib seaborn

Why Jupyter Rocks (and How to Use it Well)

Jupyter isn't just a place to run Python. It's a digital lab notebook built for messy, iterative exploration. You don't have to write a full script before running your code. Instead, you write and run cells one at a time, keeping results visible as you go.

Tip: Think of each cell as a test tube: Mix something new, see what happens, make notes, then move on.

Some key notebook best-practices:

Break work into small cells - Each step (importing, loading data, preprocessing, training, etc.) should be its own cell. This helps with debugging and lets you rerun only the parts you need.
Use markdown cells to narrate - Don't just write code, explain it! You can use markdown cells to add headings, lists.... Markdown and even LaTeX math for formulas.
Restart & run all often - Use Kernal -> Restart Kernal and Run All Cells to ensure your notebook runs from top to bottom.
Name your notebooks clearly - Use descriptive names like edh-staple-classifier.ipynb so you can find them later.

Implementation Steps

Launch Jupyter

Before you write a single line of Python you need a notebook server running. jupyter lab boots up a lightweight web server on localhost:8888 (or the next free port) and opens your default browser. From here every notebook lives in the directory you launched the command from, so start it at the root of your project folder.

Tip: If you prefer the classic interface, swap lab for notebook. Add --port 9000.

jupyter lab # or: jupyter notebook

Create a Notebook

In the Jupyter UI choose File → New → Notebook and select Python 3. A new tab appears with an empty code cell and an auto‑generated filename like Untitled.ipynb. Rename it to something memorable (e.g., edh-staple-classifier.ipynb) so future‑you can find it quickly.

Note: Every notebook is tied to a kernel. A kernal is an active Python process that keeps variables in memory between cell runs.

Import Libraries

Your first code cell should gather every library you’ll need. Keeping imports together makes it easier to debug missing packages and rerun the whole notebook end‑to‑end. Notice we pull in matplotlib before seaborn; the latter piggybacks on the former for plotting.

import pandas as pd
from sklearn.model_selection import train_test_split
from sklearn.linear_model import LogisticRegression
from sklearn.metrics import classification_report, confusion_matrix
import matplotlib.pyplot as plt
import seaborn as sns

Tip: Add %reload_ext autoreload and %autoreload 2 if you’re developing helper modules alongside the notebook. Jupyter will hot‑reload them on every cell run.

Load & Inspect Data

Jupyter automatically renders pandas DataFrames as slick HTML tables, so a simple df.head() becomes an instant mini‑dashboard. Always eyeball the first few rows and call df.info() to catch missing values or wonky dtypes before you train.

df = pd.read_csv('cards.csv') # sample MTG card dataset
display(df.head())
df.info()

Gotcha: If your CSV lives on the web, read it directly with pd.read_csv('https://...')—no download step required!

Pre‑process Features

Feature engineering is where ML wins or loses. Here we cherry‑pick three already‑encoded columns and split the data 80/20 into training and test sets. Setting random_state locks in determinism so a colleague can reproduce your exact split.

X = df[['mana_value', 'type_encoded', 'color_identity_encoded']]
y = df['is_edh_staple']
X_train, X_test, y_train, y_test = train_test_split(
    X, y, test_size=0.2, random_state=42, stratify=y
)

Tip: Use stratify=y when your classes are imbalanced to preserve the same positive/negative ratio in both splits.

Train the Model

Logistic regression is fast, interpretable, and perfect for a binary “staple or not” task. Crank max_iter up if the default 100 iterations fails to converge.

model = LogisticRegression(max_iter=1000)
model.fit(X_train, y_train)

Heads‑up: After training, check model.coef_ to see which features push predictions higher or lower—handy for blog post anecdotes.

Evaluate Performance

Next we generate a classification report and plot a confusion matrix. The heatmap gives an at‑a‑glance view of false positives vs false negatives.

preds = model.predict(X_test)
print(classification_report(y_test, preds))

cm = confusion_matrix(y_test, preds)
plt.figure(figsize=(4, 4))
sns.heatmap(cm, annot=True, fmt='d', cbar=False)
plt.xlabel('Predicted')
plt.ylabel('Actual')
plt.title('Confusion Matrix')
plt.show()

Note: If recall is more valuable than precision for your use‑case, focus on the lower row of the matrix.

Iterate & Document

Notebooks shine at rapid experimentation. Duplicate a cell, tweak a hyper‑parameter, rerun, and stash results in a Markdown cell for future reference.

Workflow tip: Use nbdime to diff notebook versions in git or adopt the new .ipynb text‑based format (jupyter nbconvert --to markdown) for readable PRs.

## Experiment 002 — Added stratification, accuracy +3.2 %

Next Steps

Swap in more powerful algorithms (RandomForest, XGBoost).
Perform hyper‑parameter tuning with GridSearchCV.
Use JupyterLab extensions like variable inspector or nbdime for diffing.
Export your notebook to HTML or Markdown for sharing (File → Export).
Push it to a GitHub repo and enable Binder for one‑click reproducibility.

Outro

Thanks for reading! If this guide levelled up your ML workflow, pass it on to your fellow data dabblers or drop a comment with what you built. Until next time. Happy modelling!

Summoning Your ML Model from the Cloud: FastAPI + AWS Lambda Speedrun

Kaemon Lovendahl — Mon, 09 Jun 2025 17:12:58 +0000

Intro

Hello, fellow wizards! If you've been following my posts you'll know that I've been learning about Machine Learning and MLOps. Currently, I've been working on deploying a new Logistic Regression that can make requests to via API calls. I've gone through the process of training and fine-tuning a new model. So in this article we'll go through the next steps of deployment and making a request.

TL;DR In under 15 minutes we'll train a ~45 KB Logistic Regression that predicts whether a Magic: The Gathering card will become an EDH staple (EDH Rec rank ≤ 5 000) using only four features. mana value, card type, color identity, and rarity. Then we'll sling the model into AWS Lambda via a containerised FastAPI so you can make predictions on demand.

Why Even Go Serverless

Cold starts are small these days - Lambda container images give you up to 10 GB, which is plenty for most models.
Scale to zero - pay only when your model actually gets summoned.
Ops? Lol - no fleet of EC2 instances to babysit.

If your model needs sub-100 ms latency 24/7, maybe spin up a GPU box instead. For everything else, Lambda is your bff.

Prerequisites

Tool	Tested Version	Purpose
Python	3.11	Training + inference script
FastAPI	0.110	Lightweight API
Docker CLI	25+	Build container image
AWS CLI	2.15	Push + deploy
AWS Account		Obviously
MTGJSON		Card data source

Why these four features?

Mana value - Great way to weed out the likelihood of a card being usable. Lower mana value is more playable than a high mana value card.
Card type (creature / non-creature) - Creatures are the most popular cards to play.
Color count - More colors means more specific deck pairings whereas less colors can go into more decks.
Rarity tier - Mythics and rares tend to be pushed (though not always!). Encoding it gives the model extra signal for power level.

All four are text-or-numeric columns already present in Scryfall/MTG JSON dumps. Which means no embeddings or heavy tokenisation needed. Perfect for a Lambda free-tier budget.

1 · Train a snack-sized model

# train.py
import joblib, pandas as pd
from sklearn.linear_model import LogisticRegression
from pathlib import Path

cards = pd.read_csv("cards.csv") # download from https://mtgjson.com

# --- feature engineering --------------------------------------------
cards["numColors"] = cards["colorIdentity"].apply(len)
cards["isCreature"] = cards["type"].str.contains("Creature").astype(int)
rarity_map = {"common": 0, "uncommon": 1, "rare": 2, "mythic": 3}
cards["rarityScore"] = cards["rarity"].str.lower().map(rarity_map).fillna(0)

X = cards[["manaValue", "numColors", "isCreature", "rarityScore"]]
y = (cards["edhrecRank"] <= 5000).astype(int)

model = LogisticRegression(max_iter=1000).fit(X, y)
joblib.dump(model, "edh_staple_model.joblib")
print("Saved model — size:", round(Path('edh_staple_model.joblib').stat().st_size / 1024, 1), "KB")

Result? ≈45 KB. Tiny enough that cold starts won't feel like summoning Eldrazi.

2 · Wrap the model in FastAPI (`app.py`)

This will create a simple API that accepts card features and returns the probability of being an EDH staple.

from fastapi import FastAPI
from pydantic import BaseModel
import joblib, numpy as np

model = joblib.load("edh_staple_model.joblib")
app = FastAPI(title="EDH-Staple-Predictor")

class CardFeatures(BaseModel):
    manaValue: float
    numColors: int # 0-5
    isCreature: int # 1 = Creature, 0 = not
    rarityScore: int # 0-common … 3-mythic

@app.post("/predict")
def predict(card: CardFeatures):
    feats = [[card.manaValue, card.numColors, card.isCreature, card.rarityScore]]
    prob = float(model.predict_proba(feats)[0, 1])
    return {"stapleProbability": round(prob, 3)}

# for local dev fun\if __name__ == "__main__":
    import uvicorn; uvicorn.run(app, host="0.0.0.0", port=8000)

3 · Dockerise → ECR → Lambda

Next, we'll need to create a Dockerfile to package our FastAPI app and model into a container image that AWS Lambda can run.

# Base image: AWS Lambda Python 3.11 runtime
FROM public.ecr.aws/lambda/python:3.11

COPY app.py edh_staple_model.joblib ./
RUN pip install --no-cache-dir fastapi uvicorn gunicorn joblib scikit-learn pydantic mangum

# ASGI-to-Lambda shim
CMD [ "app.handler" ]

Heads-up: mangum provides the handler ASGI adapter. Add this to the bottom of app.py:
from mangum import Mangum
handler = Mangum(app)

Then, from the repo root:

# build & push (replace with your IDs)
docker build -t gg-staple-api .
docker tag gg-staple-api:latest <aws-id>.dkr.ecr.<region>.amazonaws.com/gg-staple-api:latest
docker push <aws-id>.dkr.ecr.<region>.amazonaws.com/gg-staple-api:latest

# one-liner Lambda creation
aws lambda create-function \
  --function-name gg-staple-api \
  --package-type Image \
  --code ImageUri=<aws-id>.dkr.ecr.<region>.amazonaws.com/gg-staple-api:latest \
  --memory-size 256 \
  --timeout 10

4 · Test the spell (curl)

Make sure your Lambda function is deployed and ready. You can test it using curl or any HTTP client of your choice.

curl -X POST https://<api-gw>.execute-api.<region>.amazonaws.com/predict \
  -H "Content-Type: application/json" \
  -d '{"manaValue":2,"numColors":1,"isCreature":1,"rarityScore":2}'
# → {"stapleProbability":0.73}

5 · Side quests & power-ups

Pain point	Quick fix
Cold starts ≥ 500 ms	Use ARM/Graviton base image or SnapStart + Provisioned Concurrency
Accuracy meh?	Try LightGBM (~200 KB) or XGBoost with `tree_method=hist`
Model getting chonky	Strip scikit-learn from runtime; ship pure-NumPy weights

Obviously this model had to be small for Lambda to be viable. There is a lot more optimisation you can do to improve accuracy, such as:

Feature engineering: Add more features like keywords, card text, or even historical price trends.
Model selection: Try more complex models like LightGBM or XGBoost, which can handle categorical features better and often yield higher accuracy.
Hyperparameter tuning: Use tools like Optuna or Hyperopt to find the best hyperparameters for your model.

Final Thoughts

With a pinch of feature engineering and
docker build && docker push, you've moved an ML model from dev box to globally-scalable Lambda endpoint. No K8s, no autoscaling groups, just a pay-per-invocation goblet of goodness.

Feel free to fork the repo, toss in extra features (e.g., keywords in rules text), or swap in a boosted tree. All the plumbing stays the same.

Drink deeply, code boldly, and may your deployments stay glitch-free. brb, brewing more coffee.

How to build a Lambda function that is triggered by S3

Kaemon Lovendahl — Tue, 03 Jun 2025 15:26:16 +0000

Need to react the instant a file lands in a bucket without babysitting a server? AWS Lambda + Amazon S3 is your peanut-butter-and-jelly combo. This how-to walks you through wiring the two together with Python, sprinkling in battle-tested tips (and a dash of Glitched-Goblet snark) along the way. I recently used this setup to automate a data pipeline, and it’s been a game-changer. So I thought I’d share the recipe.

Prerequisites (a.k.a. “Stuff you already have”)

What	Why
An AWS account with `Admin` or equivalent rights	You’ll create buckets, roles, and functions.
AWS CLI + configured credentials	Faster than clicking in the console.
Python 3.11+ locally (optional)	Handy for zipper-up deployments or unit tests.
A splash of IAM know-how	Least-privilege saves future-you from 3 a.m. alerts.

1 — Know your cast of characters

Piece	Role
Handler (`lambda_handler`)	The first line executed when Lambda fires. Think of it as `main()` for server-less. (AWS Documentation)
Event	A JSON blob describing why the function was invoked—bucket name, object key, etc.
Context	Metadata about this invocation (request ID, memory limit, log group, etc.). Great for tracing and perf metrics. (AWS Documentation)

tip: Dump json.dumps(event, indent=2) to CloudWatch on day 1. Future you will thank current you when the event shape inevitably changes.

2 — Spin up an S3 bucket

Create a bucket to hold your files. Use the AWS CLI for speed:

aws s3 mb s3://gg-demo-ingest-bucket

Optional filters: Use prefix (uploads/) or suffix (.json) rules to avoid noisy triggers.

3 — Craft a least-privilege execution role

Create an IAM role that your Lambda function will assume. This role needs permissions to read from S3 and write logs to CloudWatch.

aws iam create-role \
  --role-name gg-s3-lambda-role \
  --assume-role-policy-document file://trust.json

Attach policies:

AWSLambdaBasicExecutionRole (writes logs)
AmazonS3ReadOnlyAccess (or a tighter bucket-scoped policy)

4 — Write the Python function

Here's a simple Lambda function that reads JSON files from S3 and logs the contents. It uses structured logging for better observability. We'll use boto3 to interact with S3 and json to parse the file contents.

In order to get the file, we'll need to get the bucket and key from the event object. The key is URL-encoded, so we use urllib.parse.unquote_plus to decode it. We'll then read the file and parse it as JSON.

import json, logging, urllib.parse
import boto3

logger = logging.getLogger()
logger.setLevel(logging.INFO)

s3 = boto3.client("s3")

def lambda_handler(event, context):
    bucket = event["Records"][0]["s3"]["bucket"]["name"]
    key = urllib.parse.unquote_plus(event["Records"][0]["s3"]["object"]["key"])

    logger.info("Processing s3://%s/%s", bucket, key)

    try:
        raw_bytes = s3.get_object(Bucket=bucket, Key=key)["Body"].read()
        payload = json.loads(raw_bytes)

        # TODO: do something cool
        logger.debug("Payload: %s", payload)

        return {"statusCode": 200, "body": "Processed ✔️"}
    except Exception as exc:
        logger.exception("Failed on %s", key)
        raise

Here are the highlights of this function:

Uses logger instead of print ⇒ structured logs.
URL-decodes keys without choking on spaces.
Returns an HTTP-style response so downstream services can branch.

5 — Deploy & wire up the trigger

Package your function and deploy it to AWS Lambda. First, zip the code, then create the Lambda function using the AWS CLI. Make sure to replace <acct> with your actual AWS account ID.

zip function.zip lambda_function.py

aws lambda create-function \
  --function-name gg-s3-ingest \
  --runtime python3.12 \
  --handler lambda_function.lambda_handler \
  --role arn:aws:iam::<acct>:role/gg-s3-lambda-role \
  --zip-file fileb://function.zip

Attach the bucket notification:

aws s3api put-bucket-notification-configuration \
  --bucket gg-demo-ingest-bucket \
  --notification-configuration '{
        "LambdaFunctionConfigurations": [{
            "LambdaFunctionArn": "arn:aws:lambda:...:function:gg-s3-ingest",
            "Events": ["s3:ObjectCreated:*"],
            "Filter": { "Key": { "FilterRules": [
                { "Name": "suffix", "Value": ".json" }
            ]}}
        }]
  }'

AWS Console fan? S3 → Properties → Event notifications does the same thing with. (AWS Documentation)

6 — Test the flow

Now, let's test the whole flow. Upload a JSON file to your bucket and watch the magic happen.

echo '{ "hello": "glitch" }' > demo.json
aws s3 cp demo.json s3://gg-demo-ingest-bucket/uploads/

Watch CloudWatch → Log groups → /aws/lambda/gg-s3-ingest for your log lines.

7 — Triggering another Lambda (chaining FTW)

This step is extra credit. If you need to fan out work or keep your first function skinny, you can invoke another Lambda function from within your handler. This is useful for decoupling tasks or offloading heavy processing.

You can call another Lambda function using the boto3 client. You'll need the other lambda's name or ARN. Here’s how you can do it:

import boto3, json
client = boto3.client("lambda")

def lambda_handler(event, context):
    payload = { "CustomerId": "123", "Amount": 50 }

    resp = client.invoke(
        FunctionName="gg-payment-processor", # name or full ARN
        InvocationType="RequestResponse", # or "Event" for async
        Payload=json.dumps(payload).encode()
    )

    result = json.load(resp["Payload"])
    logger.info("Downstream result: %s", result)

Permissions check: Calling function needs lambda:InvokeFunction on the callee.

8 — Clean-up (so you don’t wake up to a surprise bill)

Now, because this was a test, let's clean up the resources we created. Run the following commands to delete the Lambda function, the S3 bucket, and the IAM role:

aws lambda delete-function --function-name gg-s3-ingest
aws s3 rb s3://gg-demo-ingest-bucket --force
aws iam delete-role --role-name gg-s3-lambda-role

Resources & further reading

AWS Docs – “Create your first Lambda function” (AWS Documentation)
AWS Docs – “Process Amazon S3 event notifications with Lambda” (AWS Documentation)
AWS Docs – “Define Lambda function handler in Python” (AWS Documentation)

Cool beans! You’ve now got a serverless pipeline that auto-reacts to bucket uploads, keeps your infra footprint tiny, and leaves plenty of headroom. Go forth and automate!

Outro

Thanks for reading! If you found this guide helpful, please consider sharing it with your fellow developers or bookmarking it for later.

Enjoy my content? You can read more on my blog at The Glitched Goblet or follow me on BlueSky at kaemonisland.bsky.social. I write new posts each week, so be sure to check back often!

Pandas for Data Wrangling

Kaemon Lovendahl — Tue, 27 May 2025 16:23:45 +0000

TL;DR
Learn core pandas tricks: creating DataFrames, indexing, filtering, grouping, joins, and more. Perfect as a quick reference for your next project.

Why Pandas?

If NumPy is a calculator, pandas is a spreadsheet on jet fuel. It lets you store, query, and mutate tabular data with ease. Two key objects drive everything: the DataFrame (2‑D table) and the Series (1‑D labeled array).

1. Creating Data

1.1 DataFrames

A DataFrame is like a spreadsheet or SQL table. It’s a collection of columns, each with a name and data type. You can create one from scratch, load from CSV, or even pull from SQL databases.

import pandas as pd

# Simple sales log
sales = pd.DataFrame({
    'Units Sold': [25, 42],
    'Returns':    [3,  1]
})

Output:

	Units Sold	Returns
0	25	3
1	42	1

Name rows for extra clarity:

pd.feedback = pd.DataFrame({
    'Alice': ['Great quality!', 'Arrived damaged.'],
    'Bob':   ['Fast shipping.',  'Color not as shown.']
}, index=['Order #1001', 'Order #1002'])

1.2 Series

A Series is a sequence of data values. Kinda like a List, but with a label for each value. You can think of it as a single column in a DataFrame.

pd.Series(['North', 'South', 'West'], name='Direction')

Output:

| 0 | North |
| 1 | South |
| 2 | West |

2. Reading Data

In real work you’ll load from files. Pandas makes this easy with read_csv, read_excel, and more. Here’s how to load a CSV file containing Population stats:

pop = pd.read_csv('data/world_population.csv')
print(pop.shape) # (235, 5)
pop.head()

Key read_csv options:

sep – delimiter (default ,)
index_col – set a column as the index (e.g., index_col='Name')
dtype – force column dtypes (useful for IDs that look numeric but aren’t)

3. Column & Row Access

Before you can use your data, you need to know how to grab specific slices of it. Pandas offers two paradigms:

Bracket Access: grab a column by name.
iloc: position-based indexing for rows and columns. (row #, col #)
loc: label-based indexing for rows and columns. (row label, column label)

employees = pd.DataFrame({
    'Department': ['Sales', 'HR', 'IT', 'Finance'],
    'Name': ['Ann', 'Ben', 'Cara', 'Dan'],
    'Salary': [65_000, 55_000, 75_000, 80_000]
})

3.1 Dot / Bracket Notation

You can access columns like attributes or dictionary keys.

employees['Salary'] # Series of salaries
employees['Salary'][0] # 65000

3.2 `iloc` (Position‑based)

Position-based selection is similar to how we access the elements of a list or dictionary. We can use the iloc method to access the rows and columns of a DataFrame using their index.

employees.iloc[2, 1] # Row 2, Col 1 ⇒ 'Cara'

3.3 `loc` (Label‑based)

employees = employees.set_index('Name')
employees.loc['Ben', ['Department', 'Salary']]

Note: Both loc and iloc are row-first, column-second. This is the opposite of how Python, which is column-first, row-second. This is important to remember when using these methods.

Choosing between `loc` and `iloc`

Use iloc when you want to select rows and columns by their integer index.
- ilocuses the Python stdlib indexing scheme, where the first element of the range is included and the last one is excluded. So 0:10 will select 0,....9.
Use loc when you want to select rows and columns by their label.
- loc uses the pandas indexing scheme, where the first element of the range is included and the last one is included. So 0:10 will select 0,...,10.

4. Conditional Selection

Build boolean masks to filter rows. This is like using a sql WHERE clause or a spreadsheet filter. You can chain conditions with and or or.

# Employees earning ≥ 70k
high_paid = employees[employees['Salary'] >= 70_000]

# Countries with population between 50 M and 100 M
mid_pop = pop[pop['2023'].between(50_000_000, 100_000_000)]

Pandas comes with a few built-in conditional selection methods. These are useful when we want to select rows based on a condition.

isin(): Select rows where the value is in a list.
between(): Select rows where the value is between two values.
str.contains(): Select rows where the value contains a string.
str.startswith(): Select rows where the value starts with a string.
str.endswith(): Select rows where the value ends with a string.
str.len(): Select rows where the value has a certain length.
str.match(): Select rows where the value matches a regular expression.
isnull(): Select rows where the value is null.
notnull(): Select rows where the value is not null.

5. Assigning & Transforming

Data isn’t static. You’ll often craft derived columns (e.g., a custom "Bulk" metric) or transform existing ones. Pandas lets you vectorize math for speed, or reach for map/apply when you need bespoke logic. It gains new capabilities without altering the original stats sheet.

# Salary after 5 % raise
employees['Salary_2026'] = employees['Salary'] * 1.05

Vectorized math is faster than apply.

5.1 `map` & `apply`

The function you pass to map() should expect a single value from the Series and return a transformed version of that value. map() returns a new Series where all the values have been transformed by the function.

apply() is the equivalent method if we want to transform a whole DataFrame by calling a custom method on each row.

avg_salary = employees['Salary'].mean()
# De‑mean salaries
employees['CenteredPay'] = employees['Salary'].map(lambda s: s - avg_salary)

# Row‑wise flag: long tenured?
employees['LongTenure'] = employees.apply(lambda r: r.get('Years', 0) > 5, axis='columns')

Note: map and apply return new, transformed Series and DataFrames, respectively. They do not modify the original Series or DataFrame.

6. Grouping & Aggregation

We'll often want to group data together, and then do something specific to the group. For example, we might want to group employees by a salary. We can do this by using the groupby() method. The groupby object acts as an iterator over these boxes, and aggregation functions (mean, count, max, custom lambdas) summarize each group.

# Avg salary by department
employees.groupby('Department')['Salary'].mean()

# Max population per continent
continents = pop.groupby('Continent').apply(lambda df: df.loc[df['2023'].idxmax(), ['Country', '2023']])

agg lets you mix multiple functions:

employees.groupby('Department')['Salary'].agg(['count', 'min', 'median', 'max'])

6.1 Multi‑Index

Pandas allows us to create a multi-index DataFrame. This is useful when we want to group data by more than one column. Grouping by two columns returns a MultiIndex:

g = employees.groupby(['Department', 'Role']).size()
g.reset_index(name='Headcount')  # flatten

Multi-indices have several methods for dealing with their tiered structure which are absent for single-level indices. They also require two levels of labels to retrieve a value. Dealing with multi-index output is a common "gotcha" for users new to pandas.

Note: To convert a multi-index back to a single index, we can use the reset_index() method.

7. Sorting

Sorting is a common operation in data analysis. Pandas provides a number of methods for sorting data. The sort_values() method is used to sort a DataFrame by one or more columns. The sort_index() method is used to sort a DataFrame by its index.

employees.sort_values(by='Salary', ascending=False).head(3)

8. Data Types & Missing Values

Pandas automatically infers data types when reading CSVs, but you can specify them with dtype or convert later. Common types include:

int64 – integers
float64 – floating point numbers
object – strings or mixed types
category – categorical data

It's possible to change the type of a column in a DataFrame. This is done by using astype().

Entries missing values are called NaN (Not a Number). These values are always float64 types. Pandas provides some methods for dealing with missing values.

isnull(): Returns a boolean Series indicating whether each value is null.
notnull(): Returns a boolean Series indicating whether each value is not null.

To help fix these values, pandas provides a few methods for filling in missing data.

fillna(): Fill in missing values with a specified value.

employees.dtypes
employees['Salary'] = employees['Salary'].astype('int64')

# Fill NAs in Years column with 0
employees['Years'] = employees['Years'].fillna(0)

isnull, notnull, and replace help clean data.

9. Combining DataFrames

Real-world projects often scatter info across multiple CSVs or APIs—stats in one table, moves in another, competitive tiers in a third. Pandas gives three progressively more flexible tools to stitch these tables together:

concat – Stack DataFrames vertically or horizontally when they share the same columns or index.
join – Align on the index, great when you’ve already set names or IDs as the index and want a simple left/right join.
merge – SQL‑style operation where you match rows on one or more columns (keys).

Choosing the right tool depends on how your data is keyed and whether you’re adding rows, columns, or a relational lookup.

9.1 `concat`

Use when: datasets have identical columns (or identical indices when concatenating columns) and you want to glue them end‑to‑end.

q1 = pd.read_csv('sales_Q1.csv')
q2 = pd.read_csv('sales_Q2.csv')
all_sales = pd.concat([q1, q2], ignore_index=True)

9.2 `join`

Use when: both tables share the index you want to join on, and you’d like a fast shorthand for merge(left_index=True, right_index=True).

cust = pd.read_csv('customers.csv').set_index('CustomerID')
orders = pd.read_csv('orders.csv').set_index('CustomerID')
orders = orders.join(cust, how='left')

9.3 `merge`

Use when: you need fine‑grained control—inner vs. outer joins, multiple key columns, suffix handling. Mirrors SQL’s SELECT … FROM A JOIN B ON ….

#products = pd.read_csv('products.csv')
order_items = pd.read_csv('order_items.csv')
full = order_items.merge(products, on='ProductID', how='inner')

10. Renaming & Re‑indexing

Rename lets you change the index and/or column names. You can do this by specifying index or column keyword parameters. It supports mutliple input formats, but the most common is a dictionary.

employees.rename(columns={'Salary': 'AnnualPay'}, inplace=True)
# Use employee ID as index
employees.set_index('EmpID', inplace=True)

Note: You will very rarely need to update index names. It's more common to update column names. Updating the index name is usually done with set_index().

Final Thoughts

Pandas is a powerful tool for data analysis and manipulation. It provides a wide range of methods for working with tabular data, making it easy to read, write, and transform data. Whether you are working with small datasets or large datasets, pandas can help you get the job done quickly and efficiently.

Outro

Thanks for reading! I know that this is the third reference sheet in a row. Next week I will be throwing everything together with a tutorial on predicting Magic: The Gathering card prices!

Enjoy my content? You can read more on my blog at The Glitched Goblet or follow me on BlueSky at kaemonisland.bsky.social. I write new posts each week, so be sure to check back often!

Forem: Kaemon Lovendahl

How to Be Smart and Offload Your Job to AI

1. Never understand the problem first

2. Treat the first answer as the best answer

3. Measure productivity by output size

4. Use AI before reading the docs

5. Let AI choose the architecture

6. Ship code you cannot explain

7. Replace debugging with repeated prompting

8. Use AI most aggressively where mistakes are the most expensive

9. Generate comments after the code so the lies feel official

10. Never clean up generated code

11. Confuse familiarity with understanding

12. Skip the human parts of the job

13. Generate tests you’ll never read

14. Keep prompting until the machine agrees with you

15. Forget that judgment is the actual job

So what should AI actually be doing?

Final sip

Provider-Agnostic Chat in React: WebLLM Local Mode + Remote Fallback

Intro

Setting Up / Prerequisites

Implementation Steps

Step 1: Create the app (Vite + React)

Step 2: Define a provider interface

Step 3: Implement the WebLLM local provider

Step 4: Implement the remote provider client

Step 5: Add a Next.js route handler for /api/chat

Running Next.js alongside Vite without CORS pain

Environment variables for Next.js

Step 6: Build the chat hook (provider-agnostic brain socket)

Step 7: UI component

Why this setup is worth having

1) Privacy-first features without a backend

2) Cost control and “free” demos

3) Graceful degradation

4) Offline-ish UX for specific workflows

Real Talk

Watch outs and gotchas

Token junk like <|start_header_id|>

Local models are not remote models

Possible Improvements

Outro

Designing for AI Browsers: When Your User Has a Copilot

What is an “AI browser” in practical terms?

Classic browsers with AI glued in

Agentic browsers

New AI-centric environments

How AI browsers “see” your site

Your Design goal

Make the structure boring and explicit

Use real landmarks instead of div soup

Give actions honest, descriptive labels

Feed AI some structured data

Make flows agent friendly

Anti-patterns that break AI copilots (and users)

How to test your site against AI browsers today

With Edge + Copilot

With Chrome + Gemini

Try an agentic browser

Security and terms: do not ignore the policy fights

The real takeaway

“Assign to Copilot” Explained: What GitHub’s Coding Agent Actually Does

Intro

What It Is (and how it behaves)

Where it actually helps

Guardrails you should know about

Costs, plans, and the “premium request” model

Limits and rough edges (so you don’t find them the hard way)

The Glitched Goblet take

Build a Desktop-Friendly Podcast App with Next.js

Intro

Setting Up / Prerequisites

Implementation Steps

Add Types

Search API (server) — proxy iTunes Search

Episodes API (server) — fetch & parse RSS

Audio Player component (play/stop/skip + a11y & keys)

Hook it up in the main page (search -> show -> episodes -> play)

Next Steps

Step 5: Add a Next.js route handler for `/api/chat`

Token junk like `<|start_header_id|>`

2 · Wrap the model in FastAPI (`app.py`)