hedgehog

From what I've seen the more complicated the deployment and the more tedious the investigation the more useful the automation is. The agent shouldn't be interpreting the alert much beyond gathering symptoms and identifiers for drilling down into all the underlying data and code. The security side of this is very tricky because the speed that makes the tooling useful also makes it hard to supervise.

I'm very happy to let the robot handle any incidental React or other extraneous tools that end up adjacent to the core work I'm doing. It avoids getting blocked without interrupting teammates or spending time and cognitive capacity on stuff that has no lasting value in my work.

Is it really that complicated to set up? A basic version is make everything work from a CLI in terminal coding agent of choice (probably already mostly there), hook it up to alerts, and let it run in a corner?

That's a certain kind of taste... I checked out your home page, game dev, check, and this work of art is worth linking (no irony, I love it):

http://maulingmonkey.com/brainfuck/

That was almost certainly my problem. If there was a warning about this I could have missed it.

Weirdly I know for sure there was an article behind that first link earlier today but now it's showing no body, just the update boxes. The second doc link is quite clear though.

Interesting could be a bug on my end. I'll look and see if it's a problem with how I set up my sandboxes, or something related to the precedence when both are available in the environment. With all the back and forth on their messaging at the time I took it as a cue to remove the Claude Code dependency from my workflow and start using other providers' models more.

The wording is ambiguous but empirically when I last ran claude -p as part of a job it drew from my $200 API credit.

Not true any more, read the note at the top of that page. They give you API credits but it's limited.

What's the rough approach? Do you support mixed fixed/variable, like could an editor show mono for code and variable for prose?

Either of those with the 2.5L hybrid drivetrain is about as boring of a car as you can get (in a good way).

If you're conservative and buying something as critical as a daily use car it makes a lot of sense to get second or later model year of the second or later generation since a major redesign. Preferably a model that has been sold in high volumes and used heavily as a taxi or something. Then at least you will know the most likely problems before you buy.

I didn't touch JIT (complexity and footprint way beyond what I can use or manage myself in any case) but the AOT path is pretty much what you'd get if you wrote naive C by hand. The emitted code is readable, in some cases you probably do better because more efficient algorithms are easier to code or reuse, but with the current refcounting that will have some overhead. I do want to try some ideas like supporting an @soa decorator for a List of DataClass type that keeps the visible interface but changes the memory layout. If someone wanted to sponsor tokens I could probably pure robot through a stage of fleshing out enough to port a few representative libraries and tune against the results.

My understanding is that almost all deals are built on floating rate debt, with some hedging. I don't work in PE though, maybe someone here knows the market in more detail.

As I understand it the situation is much worse than that, the existing debt is floating rate so in some situations can put previously sustainable companies into the red. This of course also affects their ability to refinance so it can spiral from there unless they take drastic measures (which still might not be enough).

I did some experiments translating a typed subset of Python to C for small system use, certain features like lists of primitive types, generators and comprehensions, frozendict, simple classes, generic functions, etc, map with little or no cost but are so much cleaner than the equivalent code in plain C. You also get to write test harnesses using all the tools available to full Python. The main issue is unsurprisingly memory management, Obj-C / Swift style automatic reference counting works but has drawbacks, and it gets much more complicated if you want to mix the static and CPython code.

The static + AOT approach has a lot of promise now that type annotations are widely adopted, predictable behavior and good performance on code that is mostly idiomatic Python seem like a good alternative in many situations to the weight of Rust.

See my other comment, this is likely only for the prefill GPU pool, a normal 1M token session would work fine. I think Cloudflare should probably link an explainer on how model serving works at the top of the post because a lot of people are not familiar at that level of detail.

I read that as you can only do a single prefill up to 681k tokens, separate from cache hit or generation. I think people try pretty hard to avoid a cache miss on sessions that long and rarely do standalone requests that big so the situation triggering this condition is rare. If you run a normal coding session with many turns it would get to 1M ok.

I am happy to YOLO stuff into my -dev branch unread but even for private tooling nobody else will ever use I then let things mature a little bit before extracting an explainably and clearly-scoped change to add to main. It's going to be really interesting to see how different team cultures deal with this stuff.

Have you tried Zuban? The last time I looked at the options I preferred it for similar reasons to why you like Pyrefly, though I haven't re-evaluated recently.

Ah, interesting. I went with Ghidra p-code which seems ok but what I didn't really appreciate going in was how much of the platform API surface you have to describe before you can prove pretty much anything at all.

I'm curious about your workflow (or the one in the blog post), I have been doing some experiments proving things about existing binaries and it's been extremely slow progress.

I've always found that quite strange. Clearly the information is present because they're not signed with the same keys.

Thanks, that's helpful. Do you still have the full data of pass/fail for each test and model? It would be interesting retrospectively to see if there is such a subset.

I built some tools for personal research projects that could potentially help success rates on long dev tasks, empirically it seems to but I've never actually done a quantitative evaluation. SlopCodeBench looks promising for all the reasons you point out in your post.

Is there a reasonable way to run a representative subset myself?

Edit:

> For folks who want to try to repro these findings: I used the pinned v1.0 catalog, the stock just-solve prompt, seed 42, the any-case runner pass policy, and Docker with Python 3.12 and uv.

And https://github.com/gabeorlanski/scb-problems/

I think the reason so many people hit this in particular is enabling Sequoia beta channel is the only way to prevent the machine from wanting to upgrade to a newer major release.

The problem is that as far as I know the only way to pin a Mac to an older major version is to put yourself into the beta stream, so people (including me) are getting these not because they want developer access but just because they don't want to upgrade.

I've never seen a case where mucking with the prefix to a long context pays off. Append a message to the session, do a compaction/truncation in the current session, or launch a sub-agent, all ways to inject new information from the harness without a big uncached read. I don't think that cache hit rate is very a useful metric to optimize for, much better to come up with an approximate cost model and benchmark task completions.

Compaction for sure, but putting git status in the system prompt? Why? (also I'm not sure about common approaches to compaction, they make context window management tricky and cost more generated tokens)

The thing that surprises me is that any of the popular harnesses break cache this way. Is it just an artifact of too much LLM code and not enough tests?

Weird. Hopefully they converge, I don't miss the days of wildly divergent browser engine behavior.