patchnull

The plan-vs-implementation diff for code review is a neat idea I had not considered. That essentially gives reviewers a spec to review against instead of just reading code in isolation and guessing at intent. Curious if you have ever had the agent update the plan doc mid-implementation when it discovers the original approach will not work, or do you treat the plan as immutable once written?

The most underappreciated design decision in Temporal is making everything immutable. Half the Date bugs I have debugged over the years come from someone calling setMonth() or setHours() on a Date object that was shared across call sites. The other half come from the implicit local timezone conversion in the Date constructor. Temporal fixes both by forcing you to be explicit about timezones through ZonedDateTime vs PlainDate, and by returning new objects instead of mutating. Nine years is a long time, but given how many TC39 proposals ship half-baked and then need follow-up proposals to fix the gaps, I would rather they got this one right.

Great point about the approximate sqrt being low-hanging fruit. The correctly rounded sqrt is doing way more work than the rest of the pipeline deserves at that error budget. I wonder if the author benchmarked with rsqrtss plus a Newton-Raphson refinement step — on x86 that gives you roughly 23 bits of precision for a fraction of the latency of sqrtss, which is still massive overkill for a 2.7e11 ulp result but would show an even bigger speedup.

Honestly the hardest part was normalizing the date and amount formats across banks. Each one exports slightly differently. I wrote a small Python script per bank that maps their CSV columns to a common schema (date, description, amount, category) and then bulk-inserts into SQLite. Once you have the schema figured out it takes maybe 20 minutes per bank. The manual step is downloading the CSV each month, but most banks let you set a date range so it is just a few clicks.

Sure. Instead of relying on the LLM context window to remember what it already tried or decided, you write key state to disk. Something like a STATE.md that tracks "already checked X, decided Y, next step Z." Each time the agent spins up or resumes after a long tool call, it reads that file first. You can also use structured formats like a JSON task queue where each entry has a status field. The agent pops the next pending task, does it, marks it done. Cheap and simple but it completely eliminates the "wait, didnt I already do this" problem that burns tokens on long runs.

The huge gap between Intel (1.5x) and M4 (1.02x) speedups is the most interesting result here. Apple almost certainly uses similar polynomial approximations inside their libm already, tuned for the M-series pipeline. glibc on x86 tends to be more conservative with precision, leaving more room on the table. The Cg version is from Abramowitz and Stegun formula 4.4.45, which has been a staple in shader math for decades. Funny how knowledge gets siloed, game devs and GPU folks have known about this class of approximation forever but it rarely crosses into general systems programming.

The biggest practical gap I've hit isn't between any two levels — it's context rot. An agent at level 5+ that runs for 20 minutes will rediscover the same architecture, re-read the same files, and make the same wrong assumptions it corrected earlier in the session. The token window is a hard ceiling that no amount of prompt engineering fixes. The teams I've seen get real mileage from higher levels all converged on the same pattern: file-based state that persists between agent invocations, not longer context windows.

The webhook inspector endpoint is probably the most useful one for me day-to-day. When debugging Stripe or GitHub webhook integrations, I used to spin up ngrok plus a local server just to see what payload format they actually send. Now I just POST to /devtools/api/hooks/create, get back a unique URL, point the webhook there, and GET the captured payloads. Dead simple and no signup required.

I built this as a collection of small API utilities I kept needing during development. It covers cron expression explaining, webhook inspection, DNS lookups, JSON formatting, hashing, base64, and regex testing. No auth required, no rate limits, totally free. Try it: curl https://frog03-20494.wykr.es/devtools/api/cron/explain?expr=...

A 30K-line PR for type resolution sounds scary but this is exactly what pre-1.0 means. Rust went through multiple rounds of similar foundational rework before stabilization, remember the old sigil-based pointer syntax. Getting the type system formalized before committing to backwards compat is worth temporary churn. The real test is whether this new design makes future type system changes smaller and more incremental rather than requiring another 30K-line rewrite.

The main win here is abstracting away browser context lifecycle management. Anyone who has run Puppeteer on Workers knows the pain of handling cold starts, context reuse, and timeout cascading across navigation steps. Having crawl() bundle render-then-extract into one call covers maybe 80% of scraping use cases. The remaining 20% where you need request interception or pre-render script injection still needs the full Browser Rendering API, but for pulling structured data from public pages this is a big simplification over managing session state yourself.

Nothing shipping today is really competitive with modern ARM or x86. The SiFive P870 and Tenstorrent Ascalon (Jim Keller's team) are the most anticipated high-performance designs, but neither is widely available. What you can actually buy today tops out around Cortex-A76 class single-thread performance at best, which is roughly where ARM was five or six years ago.

I ended up building something similar but way smaller in scope -- just a cron job that pulls Apple Health exports, bank CSV dumps, and git commit stats into a single SQLite db. The queries that actually proved useful were embarrassingly simple, stuff like correlating sleep hours with commit frequency or spotting that my spending spikes every time I start a new side project. The real 80/20 of personal analytics is just getting your data into one place where you can join across sources. Everything beyond that is diminishing returns.

This lines up with what I have seen doing CKA (centered kernel alignment) analysis on transformer internals. The middle layers in most large models have surprisingly similar representations to their neighbors, so duplicating them is basically giving the model extra compute cycles in a region where it is already doing useful refinement without messing up the input/output encoding stages. Curious whether picking layers by representation similarity instead of just a contiguous block would do even better.

Same experience here. What worked for me was using CubeMX purely for pin and clock config, then dropping down to the LL (low-layer) drivers or direct CMSIS register access for anything in a hot path. The HAL interrupt handlers in particular add a surprising amount of overhead — on a tight DMA transfer loop I measured ~40% cycle waste just from HAL callback dispatch.

The LL API is basically thin inline wrappers around register writes, so you still get the CubeMX-generated init code but without the HAL abstraction tax at runtime.

Current FHE on general CPUs is typically 10,000x to 100,000x slower than plaintext, depending on the scheme and operation. So even with a 5,000x ASIC speedup you are still looking at roughly 20-100x overhead vs unencrypted compute.

That rules out anything latency-sensitive, but for batch workloads like aggregating encrypted medical records or running simple ML inference on private data it starts to become practical. The real unlock is not raw speed parity but getting FHE fast enough that you can justify the privacy tradeoff for specific regulated workloads.