WilcoKruijer

The “ultra code” implementation of workflows in both Codex and Claude Code just don’t feel that good to me. They’re super implicit, with no clear overview of what’s going on. I’m working in this space to create a harness/platform where all workflows are automatically visualised and observable. This is really working for me.

This looks super interesting. I'm trying out the hosted app using "bring your own key", I've added an OpenAI key but it doesn't seem to let me generate a 3d model. It's still saying I need credits. Is this expected?

I hope the big labs will start using this benchmark in their RL pipelines. Reducing complexity in generated code should be the number 1 priority, in my opinion. The holy grail for me is models implementing features while reducing LoC (i.e., choosing the right abstractions).

What is also nice about this benchmark is that it can be used to iterate on prompts/skills for reducing code complexity.

I’ve seen people have success figuring out model reasoning by adding a required `reasoning` parameter to tool calls. Might be worth experimenting with this for the `write` tool call in a coding agent harness.

I find this a weird comment. Isn't this the same kind of out of touch? I could write:

> Kind of goes to show how out of touch and insular the Hackernews commenter sphere can be. Almost everyone I interact with in reality loves LLMs and their touted trajectory.

And it would hold mostly true for me. This goes to show we should all be aware of our respective bubbles.

I really hate the POST verb for RESTish APIs because it cannot be idempotent without implementing an idempotency layer. Other verbs are naturally idempotent. Has anyone tried foregoing POST routes entirely? Theoretically you can let the client generate an ID and have it request a PUT route to create new entities. This would give you a tiny amount of extra complexity on the client, but make the server simpler as a trade-off.

You could almost call the comparison between Clerk and Better Auth unfair. One is a service and one is a library, apples to oranges. Any third-party service integrated into a stack is a liability, libraries as well, but to a lesser degree. It’s about time for more services to be replaced by libraries. Better Auth really shows how to do that imo, it’s a library that integrates on the frontend, backend, and database. This is why it’s so good.

From the paper:

> Everyone learns many mathematical operations in school: fractions, roots, logarithms, and trigonometric functions (+, −, ×, /, sqrt, sin, cos, log, …), each with its own rules and a dedicated button on a scientific calculator. Higher mathematics reveals that many of these are redundant: for example, trigonometric ones reduce to the complex exponential. How far can this reduction go? We show that it goes all the way: a single operation, eml(x, y), replaces every one of them. A calculator with just two buttons, EML and the digit 1, can compute everything a full scientific calculator does. This is not a mere mathematical trick. Because one repeatable element suffices, mathematical expressions become uniform circuits, much like electronics built from identical transistors, opening new ways to encoding, evaluating, and discovering formulas across scientific computing.

Mounting S3 buckets seemed like a great way to make stateless applications stateful for a while, which sounds appealing, especially for agent-like workloads. Handling conflicts like this means you really have to approach the mounted bucket as separate stateful thing. Seems like a mismatch to me.

They have Durable Objects which should be enough for most use cases (it’s SQLite with no limitations). Have you tried that?