I built the whole SentinelAI dashboard in @GoogleAIStudio with Gemini 3.8 Flash. Not a mock. Live posture, attack timeline, scan table. I described the screen and the builder gave me something I could actually click. That's the aha. DX: I stayed focused on the problem. Layout, tokens, ugly edge cases. The model handled the first pass of the interface. AX: it felt like pairing with someone who already understood dark security dashboards. I kept saying "tighter" and it got tighter. Prompt security is still a mess for most teams. Putting leaks and jailbreaks on one board made the risk feel real instead of abstract. If you have an interface stuck in your head, try 3.8 Flash in the AI Studio app builder before opening a blank repo. LIVE: sentinelai.kernelmvp.com

Day 2 of building KIVO in public. Today I built the landing page. No crazy animations. No fancy gradients. No over-engineering. Just a simple page that explains: → What problem I'm solving → Who KIVO is for → Why it matters Next, I'm getting back to the product.

People don't want AI bolted onto your product. They want your product inside the agent they already use. Ship the verbs: create, edit, undo, deny. Keep the screen as the receipt. If they can't see what it did, it didn't ship.

AI inference keeps reprocessing context it has already seen. That bothered me. So I'm building an experiment around a simple idea: compute context once, reuse it. Build Log 001.

We're excited to announce that today Python Workers are generally available (GA). It means Python is now a first-class, fully supported language on the Cloudflare Developer Platform. Read everything about it: cfl.re/4he07Gh

Jev didn't make my agents smarter. It made the boring decisions cheap enough to run at every step. That's the unlock. Not AGI. Not "replacing Claude." A typed yes/no decision you can afford to ask 200 times in one session. I spent the week running it in a real loop, not a demo. The old stack: user goal → big model thinks → picks a tool → checks if it's done → writes the next message It works until the bill shows up, the cache dies, or the agent quietly leaves the task. The new stack is simpler: 1. Code owns the paths. 2. Jev judges messy text. 3. The big model plans and writes. Three questions: • Is the goal done? • Which tool comes next? • Does a human need to see this? If the answer space is known, I don't generate. I pick. If B depends on A, I don't batch them. I only run independent questions in parallel. If Jev says "no" to "is this done," I don't let it keep calling tools. Freeze. Restate the goal in one line. Then continue. Cheap verification without a brake just makes drift faster. The practical lesson was harder: Typed and wrong still ships. A schema doesn't make the decision correct. A 52/48 split isn't a decision. It's a handoff. I stopped trusting the label and started trusting the cut. High-confidence no → stop. High-confidence yes → go. Gray band → bigger model or me. Also, lock the main model at session start. Let Jev raise effort or pick a specialist mid-thread. Rerouting the main model every turn kills the cache and makes you pay twice. What I don't use Jev for: Code. Thread summaries. Inventing options. Generate the candidate list in code. DOM, retriever, tool trace. Then let Jev pick. That's the difference between a decision model and a chatbot in a trench coat. For people shipping MVPs, this is the part I'd test. A lot of agent cost isn't intelligence. It's asking a frontier model to act like a switch statement. Routing. Done or not. Safe or not. Keep or drop this tool call. Those aren't writing jobs. We just didn't have a primitive that was fast, cheap, and could return uncertainty with a number. Jev is that primitive. Nimble and the rest can copy the recipe. The brand won't matter in three months. The layer will. Weekend test: Pick one agent you already run. Find every call that only picks something. Replace it with a typed question. Threshold on confidence, not just the answer. Put a brake on "no." Then look at the bill and the drift. If neither moves, you used it like a smaller chatbot. If both move, you put the system back in your hands.

Jev is not a smaller LLM. It is a cheap if-statement that can read messy text. In my agent stack, that means three jobs only: • Is this done? • Which tool next? • Does a human need to see it? Everything else still goes to a model that can write. Typed and wrong still ships. So the product is the threshold, not the model.

Jev is not a coding model. Stop asking Codex whether Codex may write. Frontier models are expensive at yes/no. That is a typed gate, not a reasoning job. The harness: 1. Turn 1 is read-only until paths, line ranges, and the test command exist 2. Any command that touches git remotes, secrets, DNS, billing, or prod hits a destructive gate 3. One testable condition. When it passes, commit and kill the session 4. Compose the thresholds in code. Do not let the writer grade its own work Same agent. Different wrapper. The 6x gap is which model you spend on a boolean. Do you let Codex decide it is done, or do you gate that call?

Long context is not memory. It is an argument between the model and the mistakes it already made. We asked one agent to tighten a query and add schema validation in the same session. By turn 4 it forgot why it touched the query. By turn 6 it was editing the turn-2 fix to clear a type error it created on turn 5. The harness that stopped the loop: 1. One testable condition 2. Agent runs until that test passes 3. Commit the diff immediately 4. Kill the session. Wipe context. Same model. Different wrapper. That is the 6x gap, in production. When the agent introduces a second bug while fixing the first, do you let it patch inline, or revert and split the job?

Most tools hand you a product. This one hands you a workshop. Files you already write. Types that keep them honest. A living graph. Views you can reshape. Agents that work inside it, not beside it. Early. Steep. Built with care. If your notes, tools, and agents still live in different rooms, this is the climb.

Finally. The 40-page report nobody reads can now talk. Drop a Google Doc, PDF, or Word file into Google Vids. Gemini turns it into a script, narration, scenes, and visuals. Send the video instead of hoping someone opens the PDF.

TanStack Markdown 0.0.14 is out! ⚡ Faster parsing (-72% prose, -38% streaming) ✅ +45 CommonMark cases passing 📦 Much better compatibility And all without extra bundle size... actually a little smaller! Great for blogs, docs, and streaming AI github.com/TanStack/markdown

OpenAI put a pricing cliff on GPT-6 Astra at 272k tokens. Input jumps from $10 to $20 per million, and output jumps to $75. If you dump your repo tree into context to let the model find a bug, you cross that threshold on turn one. The model spends thousands of reasoning tokens reading files it never modifies, burning ten dollars to patch a single line. Frontier reasoning is too expensive for file discovery. The cost pattern that holds: 1. Run ripgrep or a sub-dollar model like Gemini 3.8 Flash to locate target symbols 2. Extract only the target function, its direct caller, and the failing test trace 3. Pass only those three slices to the frontier model Do you let frontier models explore your directory tree directly, or strictly pass pre-filtered file slices?

Our agent rollback rate dropped by 70% when we stopped letting it handle two tasks in one session. We asked an agent to optimize a database query and add schema validation to the route. By turn 4, it lost track of why it touched the query. By turn 6, it was editing code it had already fixed on turn 2 to clear a type error it created on turn 5. Long context turns into an argument between the model and its own prior mistakes. The move that keeps diffs clean: 1. Define one testable condition 2. Agent runs until that specific test passes 3. Commit the diff to git immediately 4. Kill the session and wipe context When an agent introduces a secondary bug while fixing the main issue, do you let it fix it inline, or revert and split the job into two sessions?

I draw the line at irreversible state changes. Agents can run local tests, inspect diffs, build artifacts, and deploy to an isolated preview environment without confirmation. Staging is different. I'd let the agent prepare and trigger the deployment, but require a human confirmation before anything that changes shared state, especially secrets, databases, DNS, billing, or production traffic. The rule I'd use is simple: Read freely. Write to isolated resources freely. Write to shared infrastructure only with confirmation.

Agent frameworks hide what models break. Frontier models should plan, but workers belong in Git worktrees, terminal multiplexers, and isolated database branches. The architecture, token economics, and the three places this breaks.

Ephemeral sandboxes solved compute isolation for coding agents. They didn't solve state. Run three agent tasks in parallel and the database becomes the bottleneck: - Shared staging means concurrent migrations collide and fixtures get corrupted. - Fresh Postgres means no realistic data and another 40s of boot time. Compute is cheap to isolate. Data isn't. The pattern that actually works: 1. One sandbox per agent task. 2. A copy-on-write DB branch per worktree, created in under a second. 3. A webhook deletes the branch when the PR merges or fails. If you're running autonomous agent loops in containers, how are you isolating the database? Instant branching per run, or mocking the data layer?