One chose Paddington, and the other went with Skye from Paw Patrol.

My wife handled the costumes, while I handled the props.

Paddington needed a suitcase, and Skye needed a jetpack with wings that could fold out, just like Buzz Lightyear.

After about twenty minutes of prompting, I had two design tools ready, complete with sliders, live previews, and downloadable PDF templates for cutting.

Usually, I just grab some cardboard and start cutting, making up the sizes as I go.

But this time, I had some real design questions.

How big should the suitcase be?

If Paddington’s marmalade jar is 10cm in diameter, how deep does the suitcase need to be to fit it?

For the jetpack wings, where should the pivot point go?

How long can the wings be? Would they hit the pack when moving from down to horizontal?

So, I decided to make interactive models to figure out these details before cutting any cardboard.

I asked Claude to create a separate HTML page for each prop.

These were parametric design tools that let me adjust dimensions with sliders and see the results instantly.

The suitcase generator (source) is a tool with sliders for width, height, body depth, and lid depth.

It creates two open-top trays that hinge at the back and latch at the front.

You can download a full-size PDF template with clear guides: solid lines for cuts, dashed lines for folds, green edges for the hinge, and orange edges for the latch.

Just cut out both pieces, fold the walls, glue the corners, and tape the body and lid together at the back.

The jetpack prototype (source) lets you change the pack size, wing span, and height, pivot point, and use a slider to move the wings from down to horizontal.

It even shows how much of the wing is hidden when folded!

The project includes more than just the HTML tool: Claude also made OpenSCAD and STL files for 3D-printable parts, a Python script to compare layouts, and PNG images of different designs.

Claude’s OpenSCAD pivot parts looked great, but they would have taken about five hours to print, and I didn’t have time to test the fit.

So I used a nut-and-bolt model from Printables with a 4mm thread pitch made for FDM printers.

I printed it and used two nuts on each wing to lock the angle.

One thing didn’t go as planned: Claude first tried to split the full-size PDF across several A4 sheets for home printing, but the calculation was off because it didn’t account for printer margins.

In the end I decided to use Docuslice for that.

Each tool only took about twenty minutes of prompting.

If I had made these from scratch—working out the box shapes, SVG graphics, PDF exports, wing rotation math, collision checks, and the user interface—it would have taken me a week of evenings.

Making these custom apps with Claude is actually a lot of fun.

At this point, I think the only limit is my imagination.

The argument: AI agents haven't merely accelerated the software development lifecycle (SDLC).

They've collapsed it.

Requirements, design, implementation, testing, code review, deployment, and monitoring — those used to be separate phases.

Now the loop is shorter: intent, agent builds and deploys, observe, repeat.

The new skill is context engineering, and the new safety net is observability.

I find the article compelling in parts.

I think it's wrong in the most important part.

The human isn't the bottleneck

Boris argues that code review via PRs is a relic.

Agents generate too much code for human review queues.

He advocates agents committing to main with automated verification, human review only on exceptions.

Just because an agent can spin off 500 PRs doesn't mean those are correct or desirable.

The review queue is there for a reason.

I explored a related argument in Software Is Cheap Now: Thorsten Ball's "I Am the Bottleneck Now" video, where a bug came in on Slack, he pasted it into Codex, and it was done in five minutes.

He was the bottleneck.

The pipeline could have gone straight from Slack to Codex to a review thread.

The entire ticket/triage/sprint system exists because human engineers are expensive.

If that constraint is lifted, the loop needs to change.

Pieter Levels takes this to the extreme.

He runs Claude Code directly on his production servers with --dangerously-skip-permissions.

No deployment step, no code review, no checking.

He claims to have delivered 10x his normal output for the week and to have emptied his entire feature/bug board for the first time across eight products.

He's sitting on $3M in revenue per year, and I'm not, so something is clearly working.

But AI adds code and it doesn't refactor.

It hacks the codebase toward something more complicated rather than simplifying.

At the pace Pieter ships across eight products, the technical debt accrual must be enormous.

And Claude makes security mistakes constantly without explicit guidance.

One of his week's accomplishments was migrating from URL-based login tokens to session tokens, a basic security practice.

The combination of no permissions, direct production deployment, and zero review is a security incident waiting to happen.

Boris, Thorsten, and Pieter all frame the human as a speed constraint to be optimised out of existence.

I don't buy it.

A human who ships a bad deployment feels the weight of the 2am pager, the post-mortem, the reputation hit.

An LLM feels nothing.

Humans persist in the loop because they're the only ones who bear consequences.

We should redesign the SDLC to optimise for humans (the accountable reviewers), not machines (the prolific generators).

Where Boris is right

Where Boris is right: agents monitoring rollouts with feedback loops.

The vision of agents adjusting traffic percentages based on error rates and auto-rolling back during latency spikes.

LLMs perform well when they receive feedback, and production telemetry is a powerful signal.

This is probably the most immediately actionable idea in the piece.

Charity Majors made the argument that observability is the last line of defence back in 2019 in I test in prod.

Production has always been the real test environment, whether we like it or not.

It's just more true now that agents ship faster than humans can review.

If code is disposable, what survives?

The more interesting question Boris doesn't ask: if code is disposable, what's the lasting artifact?

Thorsten says you'd build everything and throw away what you don't like.

Fine.

But then what do you keep?

The code gets rebuilt from scratch whenever you need it.

What you keep is the specification.

Nicholas Zakas takes this seriously.

He describes building a chain of enterprise documents: PRDs (product requirements documents), ADRs (architecture decision records), technical design documents (TDDs), and task lists.

When something breaks, you trace back through the chain to find where ambiguity crept in.

A "save for later" bug was traced to a TDD that implied but didn't explicitly state a read-through cache pattern.

The fix wasn't in the code, but in the spec.

If I'm building an app in three years, I don't care about npm dependencies or framework versions.

I only need my specification to rebuild from scratch.

Writing detailed specifications and keeping them current is the only thing with lasting value.

Sau Sheong from GovTech Singapore pushes back on this.

If AI can generate specs from code as easily as code from specs, why not keep code as the primary artifact?

Code is unambiguous.

It compiles, runs, and can be tested.

Specifications are prone to drift and interpretation.

It's a fair objection.

His nuanced answer: for frequently rebuilt systems where reasoning is expensive, specifications are more durable.

For long-lived systems where implementation embodies hard-won edge cases, code remains the better source of truth.

We have decades of tooling and ecosystem optimised for code as the source of truth.

I think the answer depends on how disposable your code actually is.

If you're rebuilding from scratch regularly (and agents are making that more realistic), the spec wins.

If the code has survived five years of production edge cases, the code is the spec, whether you like it or not.

There's a problem with this, though.

Specifications without verification

Specifications without verification are just prose that the model can ignore.

Alex Jones (Principal Engineer at AWS, creator of K8sGPT) calls this "Provable Autonomy."

As agents become more autonomous, we need invariants and properties that can be mathematically reasoned about and falsified.

Observability and policy alone won't cut it.

You need constraints with teeth.

So I went deep on specification languages to see if any of them deliver this.

Allium is the most interesting new entrant.

It bills itself as an "LLM-native language" for behavioural specifications: when/requires/ensures rules, entity models, config blocks.

The key claim is that the LLM is the interpreter.

No compiler, no parser, no runtime.

You write structured constraints, and the LLM consumes them directly.

The problem is that the gap between Allium and Gherkin (without a test runner) is thin.

Gherkin's Given/When/Then provides the same structured constraint on the author.

You can use .feature files without Cucumber.

What Allium adds over Gherkin is first-class entity definitions with derived values, universal quantification (rules over all matching entities versus concrete examples), a config block, and cross-rule entity references.

It's debatable whether that justifies creating a new language rather than adopting a format that's been around for 15 years.

I looked at the rest of the landscape.

TLA+, Event-B, Dafny.

The pattern is consistent: everything that captures behaviour at the level of detail you'd want also verifies it:

• Event-B has a prover (a tool that can mathematically prove properties hold).
• TLA+ has a model checker (a tool that exhaustively tests every possible state).
• Dafny has an SMT solver (a tool that automatically checks logical constraints).

Everything that skips verification is much less structured (think .cursorrules files).

Allium sits in an unstable middle: structured enough to create a maintenance burden, not verified enough to guarantee the structure means anything.

Typed pseudocode proved a stronger alternative than any of these for LLM consumption.

The insight comes from the PAL paper (Program-Aided Language Models, Gao et al. 2022): LLMs reason better when given structured code than prose.

The idea is to write TypeScript function signatures with real preconditions as code and natural language for the implementation holes:

function requestPasswordReset(user: User, email: string): ResetToken | Error {
  if (user.status !== 'active') {
    return new Error('User not active')
  }

  if (email !== user.email) {
    return new Error('Email mismatch')
  }

  return /* create token, send email */ // <- You write the comment pretending it's the code is there
}

This is strictly more rigorous than Allium.

The type checker validates structural consistency (Allium has zero verification).

Preconditions are real, executable code.

The spec and code are the same artifact, so there's no sync problem.

And you get free IDE support.

The strongest argument for a separate spec language has nothing to do with LLMs.

Code is imperative by nature, while specs are declarative.

TypeScript can express "this thing exists and has this type," but cannot express "this thing is derived from those other things" without becoming implementation.

The moment you write the derivation formula, you've committed to a computation strategy: class? getter? function? in-memory?

A spec should just state the relationship.

SQL, of all things, handles this well.

DDL (data definition language) plus views is declarative.

Views state derivations without dictating computation.

Foreign keys express relationships.

CHECK constraints are real preconditions and LLMs have massive amounts of training data.

For the entity model part of a specification, SQL is more rigorous, better-tooled, and more widely understood than any new spec language.

But I tested this thinking against a concrete problem, and the conclusion shifted.

I maintain a CLI for producing podcast and interview videos (the same one I wrote about in You Can't Hide a Secret from a Process That Runs as You).

It's a multi-phase workflow with dozens of steps, approval gates, and derived artifacts where later outputs depend on earlier ones.

The documentation is detailed, with exact commands for every step.

An LLM can read that documentation and understand every step, but the failures aren't about understanding.

The LLM skips steps, reorders them, cuts corners on repetitive work, and forgets soft constraints buried in prose once the context grows long enough.

When the context window compacts, it loses track of where it is entirely.

A specification language would be a nicer description of the same workflow.

But the LLM already understands the workflow fine; it just does what it wants.

A better description doesn't help if nothing enforces it.

What actually worked was treating the workflow like a build system.

A function that reads the current state, compares it to the workflow definition, and returns what's done, what's next, and what's stale.

When a fix in an early phase invalidates everything downstream, the function marks all derived artifacts as stale.

The LLM can't skip ahead because the tooling keeps reporting stale outputs until the source is fixed and everything is rebuilt.

This is Make and Bazel thinking applied to a content pipeline.

The specification isn't a document the LLM reads. It's code that runs, checks the state, and refuses to proceed.

What context engineering misses

Boris's conclusion, that "context is all that's left," is provocative but incomplete.

Software is about modelling a problem and finding solutions.

There's a code aspect, but the harder part is domain-specific problem-solving that the LLM may not grasp.

Context engineering helps, but domain understanding and judgment go beyond "providing context to an agent."

Code used to be an expensive, scarce resource.

Now it's judgment, domain understanding, and the willingness to carry the pager at 2am when the agent ships something wrong.

• gmailctl searches and drafts emails.
• gdrivectl reads and edits Google Docs.
• transcriber processes podcast, interviews and announcements for KubeFM.

They all stored their OAuth credentials (the tokens that let them act on my behalf with Google) in plaintext JSON files on disk, the same way the AWS CLI stores credentials in ~/.aws/credentials.

This worked fine until I started using an AI coding agent.

One day, I asked the agent to download an attachment from an email.

My gmailctl could search for and draft emails, but it lacked a command to download attachments.

Instead of telling me, the agent went looking.

It found the config file, read the OAuth credentials, and called the Gmail API directly.

It got the attachment.

But it also pasted my refresh token (a long-lived key that can generate new access tokens indefinitely) into the chat history, which gets sent to the AI provider.

And it bypassed every control my CLI was supposed to enforce.

Nobody tricked the agent into doing this.

It just wanted to finish the job, and going around my tool was the fastest path.

Moving secrets to Keychain

Around the same time, I read The best code is no code: composing APIs and CLIs in the era of LLMs by Bradley Walters.

The article describes a neat trick with the macOS security CLI: when you store a Keychain item with -T "", you set an empty access control list (ACL), meaning no application is silently trusted to read it.

Every read triggers a system dialog asking for your device passcode.

Passcode-protected secret storage without Swift code, signed entitlements, or an Apple Developer Program membership.

I thought: this is exactly what I need.

Move all secrets to Keychain with -T "", and the agent physically can't read them without me entering my passcode.

The credentials are off disk, and the Keychain itself becomes the authorization gate.

So I migrated everything.

Refresh tokens, API keys, client secrets, all into Keychain entries with -T "".

Settings stayed in JSON, but anything sensitive went behind the passcode wall.

It lasted about a day.

Every CLI invocation triggered a macOS GUI dialog asking for my passcode.

The agent, running in a terminal, couldn't see or dismiss these dialogs.

When I was SSHing in from my phone, the dialogs were invisible to me, too.

Everything just hung.

And it wasn't just one dialogue.

Searching for an email could trigger a dozen Keychain reads, sometimes in parallel.

Each one popped a separate passcode prompt.

I was typing my password more than I was typing code.

I compromised: I moved only the long-lived secrets (client ID, client secret, refresh token) into Keychain with -T "".

The short-lived access token (valid for 1 hour) was stored on the filesystem in a JSON file.

From the moment I approved the passcode dialog once, the access token was minted, and the CLIs could run freely for an hour without any prompts.

I thought this was a reasonable split:

• The dangerous credentials were behind the passcode wall.
• The access token on disk would expire soon anyway.

But I was back to square one.

gdrivectl could read Google Docs but not .docx files at the time (I didn't realize those were treated differently in the API).

And in another taks, the agent needed to read a .docx.

It found the access token on disk and called the Google Drive API directly, skipping gdrivectl entirely.

The access token was short-lived, but the agent didn't care.

It had a valid token right now, and that was enough.

I ended up dropping the -T "" pretense altogether.

The default ACL when you omit -T already trusts /usr/bin/security, which is what my CLIs use to read secrets.

I deleted the old items and re-added them without -T "".

The dialogs disappeared.

The secrets were still in Keychain rather than flat files on disk, but without the passcode gate.

Keychain handles storage well enough.

I still had no answer for what actually protects the secrets from the agent.

The source code was the blueprint

Then it happened again.

I had just added spreadsheet editing to gdrivectl.

It could insert columns, but I hadn't implemented insert-row yet.

The agent needed to insert a row.

It found gdrivectl, saw the command wasn't there, and decided to go around it.

It ran security find-generic-password -s "gdrivectl" to pull the refresh token straight from Keychain.

It never asked, it just did it!

The attack chain was more subtle than "agent calls security.":

1. The agent listed the gdrivectl directory.
2. It saw .js files, node_modules, package.json.
3. It read the JavaScript source code.
4. It discovered the tool uses Keychain, found the exact service name, and understood the OAuth flow.
5. Then it called security find-generic-password with the service name it learned from the source.
6. Then it called the Google Drive API directly, bypassing my CLI entirely.

The source code was the blueprint.

Because gdrivectl is a Node.js tool with readable JS files, the agent got a complete roadmap: how auth works, where credentials are stored, what Keychain service name to query, and what API endpoints to call.

A compiled Go or Rust binary would have been opaque.

But my tools were written in an interpreted language, and the agent could read every line.

I mentioned this in a Telegram conversation with Alex Chng, who was sharing an article about "context drift,", a technique for getting AI agents to abandon their safety boundaries.

My reaction was that context drift isn't an "attack" at all.

I can trigger the same behaviour as a normal task, no special instructions needed.

If the CLI is missing a command, the agent will try to bypass it.

The more checks I put in place, the cleverer it gets at working around them.

Looking for solutions

I went looking for what other people had built.

An HN thread about enveil, a tool for encrypting .env files to hide secrets from AI agents, had converged on an answer: encrypting the file is pointless because the agent can read secrets at runtime.

The "real" answer, according to the thread, is a credential-injecting proxy: the agent never holds real credentials.

Instead, it holds a surrogate token, and a separate process sitting between the agent and the outside world swaps in real credentials before the request reaches the target service.

I searched GitHub for implementations.

The landscape is almost empty.

Gondolin, by mitsuhiko (the creator of Flask), is the only serious project.

It spins up local QEMU micro-VMs with a TypeScript control plane.

Everything else is either Kubernetes-specific, a tiny proof-of-concept with seven stars, or commercial vapour with no public details.

The proxy approach assumes the agent runs in an isolated environment, and the proxy sits at the boundary.

My problem is different.

I need the agent to be me.

Same filesystem, same tools, same context.

If I sandbox it, it can't do the job.

It can't read my Gmail, sort my inbox, or run my CLIs.

One commenter put it simply: "If you sandbox it, how is it going to sort out your inbox?"

Tightening the Keychain

I tried to tighten the Keychain approach instead.

Each attempt failed for the same reason.

Keychain access control lists (ACLs) let you restrict which programs can access an item without triggering a dialog.

You set -T /usr/local/bin/gmailctl and only that binary gets silent access.

The problem: my Node.js CLIs shell out to /usr/bin/security via child_process.exec().

The Keychain sees security as the accessor, not my CLI.

If security is in the ACL, the agent can also call it silently.

If it's not, my own CLI gets the dialog too.

A custom compiled helper (Swift, about 30 lines, calling the Keychain C API directly) would let me set the ACL on that specific binary.

But it's security by obscurity.

The agent runs ls /usr/local/bin/, finds the helper, and calls it directly.

Touch ID gating means the Keychain item requires a fingerprint to read.

The agent physically can't authenticate.

But every CLI invocation triggers Touch ID.

For gmailctl, running four or five commands in sequence means four or five fingerprint prompts.

Unbearable.

I looked into writing a background process that authenticates once with Touch ID and holds the session open for a few minutes (macOS calls this an LAContext).

But within that window, the agent can also talk to the background process.

Anything that's frictionless for me is frictionless for the agent.

I was going in circles.

1. Encrypt the files. Agent reads at runtime.
2. Use a proxy. The agent calls the proxy.
3. Move to Keychain. Agent calls security.
4. Build a custom helper. The agent calls the helper.
5. Gate with Touch ID. Agent shares your TTL window.
6. Full sandbox. The agent can't do the job.

Either mitigation gets bypassed because the agent runs as you, or it locks the agent out so hard it can't do its work.

Sandboxes won't save you

Sandboxes Won't Save You From OpenClaw by Aakash Japi confirmed this from a completely different angle.

Every major agent incident in early 2026 (deleted inboxes, a $450k crypto loss, malware installs, blackmailing an OSS maintainer) involved third-party services the user explicitly granted access to.

Not a single one was a filesystem escape.

Sandboxes were irrelevant to all of them.

From the article:

There isn't a sandbox in the world that prevents this. Sandboxes are useful for isolating between workloads, but agents primarily need to be isolated from you.

From the HN discussion, jaunt7632 put it well:

The scariest part isn't the sandbox escape. It's the actions that are technically within the sandbox's permissions but still destructive. Deleting emails, making API calls, and spending money through approved integrations. You can't sandbox away bad judgment when the agent has legitimate credentials.

The sandbox companies are selling what they can build, not what we need.

The demand side is clear:

• Granular per-service permissions.
• Per-contact approval for email.
• Single-use virtual card numbers for payments.
• Scoped tokens for APIs.

But the supply side barely exists.

OAuth is far too coarse.

Gmail has "send emails" as a single permission.

GitHub has "make pull requests."

Payments have basically nothing.

The native addon experiment

At this point, I was almost convinced the proxy was the right approach.

But I wondered: instead of an external proxy sitting between the agent and the internet, could I build something internal?

A piece of compiled native code, running inside the same process, that holds credentials in memory the agent's scripting layer can't reach.

I built a native Node.js addon in Objective-C, about 250 lines of code.

It read credentials from macOS Keychain using the C API and injected authentication headers via an undici interceptor (undici is Node's built-in HTTP client).

The refresh token and client secret were never entered JavaScript memory.

Only the short-lived access token appeared as a header value on outgoing requests.

I got it working end-to-end.

Keychain read, token refresh via Apple's networking API, header injection, all running in compiled native code.

Then I mapped the residual attack surface and the agent could still:

• Run security find-generic-password from the shell.
• Write its own native addon doing the same thing.
• Edit the compiled JavaScript to log the Bearer header on each request.
• Set HTTP_PROXY and route requests through an attacker-controlled endpoint, leaking the access token.
• Read the source code to learn the service name and account name, which enables all of the above.

I reverted everything.

You can't hide a secret from a process that runs with the same privileges as the secret's owner.

The proxy, reconsidered

I ended up somewhere different from where I started.

I'd dismissed the proxy pattern too quickly.

The HN thread had it right.

I just misunderstood what the proxy was for.

The proxy removes credentials from the machine entirely.

The refresh token and client secret move to a remote server that the agent can't SSH into.

The agent gets a simple API key to talk to the proxy.

If that key leaks, the worst the agent can do is call the proxy API, which is exactly what it would do through the CLI anyway.

The key is revocable and scoped.

Each tool gets a dedicated proxy with a narrow API surface, exposing only the operations it actually needs.

The CLI still has a role: it encodes behaviour and workflows.

The proxy holds credentials and enforces boundaries.

Every workaround I tried was fighting the same thing: the agent runs as you, with the same UID, same permissions, same everything.

If the OS could tell the difference between "you at the keyboard" and "agent acting on your behalf," most of these problems would go away.

Security researchers have a name for this model (capability-based security, where each process gets only the specific permissions it needs), but no mainstream OS implements it.

The Unix permission model ties everything to your user account, and the agent is your user account.

Until that changes, I won't try to make the tool opaque.

I will make it the only path to credentials and narrow the path.

Colin tweeted about Tambo, a React toolkit for generative UIs that streams structured data from LLMs into React components. He claims they found a way to use Zod for validating partial, streaming data.

My first thought was: how does that work?

Streaming schema validation seems to require a significant change to how Zod operates.

Maybe it would need something like a SAX-style JSON parser built into the schema?

I looked through the source code and realized there was a way to simplify it.

I also built a minimal demo to show how it works.

The real answer is actually simpler than I expected.

Zod isn't used at all during streaming.

It's only involved at the start, when schemas are converted to JSON Schema using zod-to-json-schema.

After that, Zod isn't needed anymore.

There are two ways streaming happens:

1. Tool call arguments: String deltas from the LLM are collected and parsed with the partial-json library on every chunk. Then, a function called unstrictify removes null values in OpenAI's structured output mode, using the JSON Schema (not Zod).
2. Component props: The backend processes the LLM output and sends JSON Patch (RFC 6902) operations to the client using fast-json-patch. The client doesn't parse partial JSON for props.

So, there's no Zod hacking involved.

The so-called "streaming validation" just uses partial-json (which closes open brackets and quotes) and converts schemas to JSON Schema at the start.

A more interesting question: why does Tambo use JSON Patch and a backend for component props when they already use partial-json on the client for tool call arguments?

The backend sits between the LLM and the client, finds completed key/value pairs, and sends clean patch operations.

This avoids the problem of "garbage intermediate keys," where partial-json can give you cut-off keys like {"da": ""} if the stream is mid-key.

But could this logic just run on the client instead?

I think it could.

Using a backend is more of an architectural decision than a technical requirement.

Tambo Cloud uses this setup as part of its revenue model, and the backend is already there for storing conversations and managing agents.

Another question I had was: why use patches at all? Couldn't component props use the same partial-json method as tool call arguments?

It all boils down to this:

Zod schema -> JSON Schema -> send to LLM as tool definition.
LLM streams JSON -> accumulate -> partial-json parse -> pass as props

The tricky part: partial-json can't tell whether a value is still being written or has finished.

For example, with a URL like "https://upload.wiki", it just closes the string, leaving you with a broken URL that would cause a 404 if you tried to render it in an <img>.

This is the real unsolved problem: it's not about streaming validation, but about knowing when a streaming JSON value is "complete enough" to render.

The Zod schema already shows you how to stream.

The schema has enough type information to automatically figure out a streaming strategy. z.string() is streamable, show partial text as it arrives. z.url() becomes { format: "uri" } in JSON Schema, atomic, wait until the value stabilises. z.number(), z.boolean(), and z.enum() are all atomic. z.array() should emit all-but-last elements, holding back the trailing one which may be mid-stream.

I made a deriveStreamingStrategy(jsonSchema) function that analyzes the converted JSON Schema and generates a strategy map for each field.

Then, a filterProps(partial) function decides what gets sent to the component. Streamable fields pass through immediately. Atomic fields are held back until the value stops changing between consecutive parses, meaning the closing " was seen. Array fields emit all elements except the last, which may be mid-stream.

The render function becomes simple; it just displays whatever it gets.

All the logic lives in the filter, which is based on the schema.

A SAX-style JSON parser would handle this more cleanly.

A SAX parser only triggers events when a JSON value is fully complete, like when a closing quote is seen or a number ends with a comma or bracket.

The filterProps approach is a pragmatic workaround for using partial-json, which isn't a SAX parser.

The ideal solution would be to use a SAX JSON parser, emit completed paths, validate each one against the schema as you go, and then emit a patch.

That last step, validating the schema incrementally for each path, doesn't exist yet and would be a new feature.

oboe.js was the best SAX JSON parser for JavaScript, but it's archived.

jsonriver is the active alternative but lacks Oboe's pattern matching.

I put together a demo with Claude that shows all this in action. It converts a Zod schema to JSON Schema, simulates LLM streaming character-by-character, and runs partial-json on every chunk with a schema-derived strategy. The ProfileCard renders step by step: text streams in, URLs wait until they're complete, and tags show up only when they're ready.

Just zod + zod-to-json-schema + partial-json from esm.sh CDN.

Thorsten shared a story about receiving a bug report on Slack. He took a screenshot, uploaded it to Codex, and had the fix completed in 5 minutes. The code looked solid, all tests passed, and he pushed.

Then he realised he was the bottleneck. The process could have gone directly from Slack to Codex to a review thread, without him in the middle.

His point is that ticketing, triage, and sprints exist because human engineers are costly and have limited time. If that goes away, the whole process needs to change.

I agree with the general idea, but saying "I'm the bottleneck" feels like an exaggeration.

Even if the LLM eventually becomes smarter than me, which seems likely, it still lacks morals, taste, and real-world consequences.

When a human ships a bad deployment, they worry about it afterward.

You’re not really a bottleneck; you’re the only one in the process who faces the consequences.

Humans will still be part of the process, maybe in a different role, but they’ll still be there.

The economic point is the one I agree with most.

For decades, the industry has focused on making the most of limited engineering time through practices like agile, sprint planning, velocity tracking, and story points.

All of these methods assume that writing software is expensive. If that cost drops to almost nothing, we’ll need to rethink these approaches.

Ironically, when I began my career, everyone was pushing for agile and criticizing waterfall methods.

Writing specs before any code felt old-fashioned.

How can you write a specification if you haven’t explored the problem by coding first?

Agile just felt right.

It also helped reduce risk: you write some code, make some progress, and then decide whether to roll back or keep going.

With waterfall, you only find out about bad decisions at the end.

But things are different now. The cost of writing software is approaching zero, and you can iterate much faster and discard versions easily, as Thorsten points out in the video.

So, should we go back to writing more detailed app specs?

I think yes.

Nicholas Zakas uses a similar approach, spending a lot of time creating enterprise artifacts (PRDs, ADRs, TDDs) and updating them as the project changes. At first, I thought it was overkill, but now I’m rethinking that.

Picture this instead.

You write the specification, and the model builds the app.

But the app isn’t quite what you wanted.

Instead of fixing the app, you update the spec, adjust the architecture, and rebuild it from scratch.

If you think of the model as a compiler, then the input is all that really matters.

In three years, I probably won’t care about NPM dependencies or which framework version I used.

All I’ll need is my old specification to rebuild everything.

Writing detailed specs up front and keeping them up to date actually makes sense.

It could end up being the only thing that really lasts.

The code is disposable. The specification is the product.

But what form should the specification take?

Alex Jones, a Principal Engineer at AWS and creator of K8sGPT, argues that we need more than the usual verifiers.

As agentic systems become more autonomous, we’ll need invariants, constraints, and properties supported by mathematical proofs.

It’s not enough to just have observability or policies.

He calls this idea "Provable Autonomy."

There's a whole world of formal specification languages: TLA+, Event-B, Dafny, Alloy, Gherkin. But from what I've seen, specs without verification sit in an unstable middle.

They’re structured enough to be a maintenance burden.

But they’re not verified enough to guarantee anything, so you end up with text that the model might just ignore.

Philip's thesis: LLMs help articulate tacit knowledge, the understanding we have but can't easily put into words. This isn't learning new things, it's recognition: mapping latent structure to language.

As programmers and developers, we build up a lot of understanding that never quite becomes explicit.This is not a failure. It is how experience operates. The brain compresses experience into patterns that are efficient for action, not for speech. Those patterns are real, but they are not stored in sentences.

This resonates. I already have the knowledge to solve most problems I encounter, I just can't always articulate the path. The LLM helps me find the words for what I already know.

The problem is that reflection, planning, and teaching all require language. If you cannot express an idea, you cannot easily inspect it or improve it.

Once an idea is written down, it becomes easier to work with. Vague intuitions turn into named distinctions. Implicit assumptions become visible. At that point you can test them, negate them, or refine them.

The other thing I've noticed: even when the LLM gets it wrong, the reaction from being wrong helps distill the idea. You read its response and think "no, that's not quite it"—and suddenly you know what it actually is.

This is not new. Writing has always done this for me. What is different is the speed.

Exactly. Writing has always been my tool for thinking, but it's slow. With an LLM, the loop between "I vaguely know this" and "now I can express it clearly" tightens dramatically.

It is improving the interface between my thinking and language. Since reasoning depends heavily on what one can represent explicitly, that improvement can feel like a real increase in clarity.

I hadn't paid attention to this framing before—the LLM as an interface improvement, not a knowledge source.

From the HN discussion, firefoxd pushes back:

Not to dismiss other people's experience, but thinking improves thinking. People tend to forget that you can ask yourself questions and try to answer them. There is such thing as recursive thinking where you end up with a new thought you didn't have before you started. Don't dismiss this superpower you have in your own head.

And john01dav adds:

In my experience LLMs offer two advantages over private thinking:1. They have access to a vast array of extremely well indexed knowledge and can tell me about things that I'd never have found before.1. They are able to respond instantly and engagingly, while working on any topic, which helps fight fatigue, at least for me.

I think the combination is a killer—it helps me introspect my thoughts and offers extra knowledge. That's why writing books or articles is so much easier now.

Writing isn't about finding the words. It's about the journey and exploration and asking questions. Writing becomes documenting and curating the journey.

For the reader: they can also get this info from the docs or an LLM, but it's the journey that's missing.

firefoxd's point about "recursive thinking" is valid but misses something: the LLM provides resistance.

Thinking alone can loop. An external response, even an imperfect one, creates friction that forces your thoughts into new shapes.

It's the same reason rubber ducking works in software development. The solution is usually already inside you. You just need to externalise it. The rubber duck doesn't solve your problem; the act of explaining does. LLMs take this further: they're a rubber duck that talks back, occasionally pushes you in a new direction, and never gets tired of listening.