all2

I had a prompt I used for this just using Claude Code:

    Let's review <filepath or specific file> for architectural issues. Spawn 10 agents, create personas for them, have them review the _api.go and write their review to reviews/<persona>-review.md, then have each agent do a round robin response to 3 of the reviews of their choosing (based on the abstract at the beginning of each review) and write the response to response/<original file name>-<agent persona name>-response.md. Then we do rebuttals to the responses in rebuttals/<response file name>-rebuttal.md. Finally, each agent should launch agents to review the reviews, responses, and rebuttals to their review, and compile findings to findings/<original file name>-findings.md. Finally, have another agent compile the findings and write that to review-findings.md. Present a concise version of the findings here.

This works well with frontier models and even locally hosted models (last I used it was with Qwen 3.5).

That's awesome! I've always been fascinated by superconductors, especially the so-called 'high temp' ones. There are some you can even make in a garage with a minimal setup. When I'm retired, maybe. :D

I really wish there was a way to filter out the soy-O-face thumbnails entirely. I do not like them. I do not want to see them.

I think you should try to go back to school for physics. Or teach yourself physics. If this idea still draws you, you should do it.

What sub-field were you going for?

I handle this by not dwelling too much on the past. Things undone do haunt me, but they are not and what is, is. The ephemeral is as useless as the emotions I have about them, and I treat it as such. Anything else is inviting agony and regret. I have enough of those and I don't need more of them.

A lot of this emotional anguish can be quashed with what might be considered "rude" pragmatism. Remove what is useless, ignore what intrudes and cannot be changed, get on with what you have and don't dwell too much on what you do not have.

Another way to frame this is from a Biblical perspective: be thankful for what good things you have and do not yearn for what you have not been given. Everything in this life is a gift. Every penny you earn, every breath you draw is more than you deserve. In that light, the life I have is wonderful, and full of joy and satisfaction. I have so much that I do not deserve, so many good things and many beyond the limit of my awareness. So I choose thankfulness before the pain of seeking that which is not, that which is unattainable, or that which is long past.

A mask and a Carrera will lend plenty of drama. The question is "what kind of mask will you wear while driving the Carrera?"

Both of those can be fixed with a minimal amount of daily work.

Both is good. I do both, and to get reasonable output from an LLM I _have_ to do both.

Best bet is tight integration with a language server and the zig docs as MD locally. You may also pull in the zig source code as canonical reference for best practices.

From there you can derive a set of tools and references that you can build skills on.

Any LLM can scratch together an MCP server, its basically FastAPI + functionality. Your goal, then, is to identify the subset of tools and data required to get 'good' output.

If you want to test your MCP server implementation, grab the source of several popular zig projects, rewind their git history, and have your LLM of choice attempt to address PRs for issues on those repos. Compare LLM solutions with the repo solutions, grade on token spend, LOC produced, variance from Zig best practices, and so on.

Tbh, we're pretty close to that. This would essentially be the following set of work cells:

- PCB etching/engraving

- Solder placement

- component placement

- solder oven

This gets you one layer populated PCBs out the other side. Commercial systems like this exist in various forms, and open source projects for all of these also exist. It would be up to you to integrate them together.

As it stands, the frontier models are actually pretty ok at firmware dev at a high level. If you need max performance, they won't be any good at all (learning from the dregs of the internet isn't exactly helpful here). You'll also need to bring at least a willingness to learn about what is involved so you can debug the machine's mistakes.

The immediate load (less than 200ms on my machine through a slow connection) is quite pleasant, tbh.

Indeed. A compelling one at that. I also vote for a 'demo' article so we can see what to expect if we subscribe.

BPF == 'Berkeley Packet Filter'

Here you go: https://github.com/pratyushanand/learn-bpf

Link is here [0]. The idea is to model cognitive states (how to think), and workflows (what to think about) as statecharts. The charts will be defined in YAML (version-able, hot-reloading). Context payloads are defined in an agent YAML file. Think of it as a map, like a drive map for a computer's HDD/SSD. You spec the order of context chunks, what goes into them, and then when the inference payload is built, it uses the context map definition (comprised of the chunks you defined), the agent definition (including model params like context length, temp, etc), cognitive state, and workflow state to build out the inference payload.

Agent cognitive states may add chunks to the system prompt. Workflows may add chunks to the system prompt. Tool access may vary by agent/workflow state (policy is last-defined-wins overlays to keep it simple to reason about).

Agents may run by themselves or be 'bound' to a workflow. Agents can detach from a workflow before it is finished, and either re-bind, or another agent may bind to the workflow (one implements, another reviews, for example).

Conceptually, this is all very simple, which is why I'm hand rolling it.

The goal is a minimal runtime that can support long-running agents in a 'zero human company' setting.

On top of the runtime will be a minimal change control workflow (if you've spent time in hardware engineering, these are standard processes governed by a company's quality system).

I've yet to wire in the economic pieces (token spend, power consumption, rollups that show performance of various agents based on inputs and outputs).

It is a bit far fetched, but I'd like to get this thing ISO9001 certified, and maybe AS9100 certified.

This is all to scratch my own itch, tbh. Most agentic systems are hard to reason about, bloated, lack visibility in the appropriate places, lack economic data of sufficient granularity, and so on. So I'm building this.

[0] https://github.com/zerohumancompany2/maelstrom-code

I'm practical terms, go to where the decision makers are and shmooz with them. It's a numbers game. Eventually someone will say yes.

I'm hand rolling a project right now because even frontier models I use bloat things beyond comprehension. Because I'm intimately familiar with the domain, I know the shape of things, how the data should flow, and so on, and if l even if I spec it clearly AI will write 2x to 5x the amount of code necessary to make something work.

I'm building an agent framework in golang and it is extremely light weight. Startup time is under 1/2 second, and RAM usage is really low. I have a 12 year old laptop and it happily runs without slowing down.

There's no reason what is essentially a string concat engine should be slow on any hardware, including old hardware.

I'm on the opposite end of this spectrum. Puppets are absurd, hysterical, and it used to be a family thing to get together and make puppets every Christmas. I'd try to make the goofiest looking puppet possible. The last one I made has a wide brimmed hat, blond hair, glasses, and the weirdest looking braided mustache. Oh, and ping pong balls for eyes.

It makes me chuckle every time I see it.

This is so good. Wiring in small models for a variety of tasks would make this absolutely sing.

I'm working on Maelstrom, an agent framework with only the basics:

- 'agent' as cognitive state, ie, what to think about

- 'workflow' as 'what to think about

- 'session' as immutable agent history

- 'timers' as a way to kick off an agent on a schedule (with or without a workflow attached

I've been working on this since just before OpenClaw dropped at the end of January. Currently it weighs in at around 20k lines of code. There is still a significant amount of work to be done on polish, but the core appears to be functional, and almost to the point where I can replace opencode as my daily driver (I'm very much looking forward to this).

From [1]:

---

I've been working on a framework since the end of January or so. I'm on my 7th draft. As I've gone along, each draft gets markedly smaller. The overlaps between what I'm building and openclaw are significant, but I've realized the elements that make up the system are distinct, small, and modular (by design). There are only a few primitives:

1. session history

1a. context map + rendered context map (think of a drive partitioning scheme, but for context -- you can specify what goes into each block of context and this gets built before being sent out for inference).

2. agent definition / runtime

3. workflow definition / runtime

4. workflow history

5. runtime history (for all the stuff session and workflow history fail to capture because they are at a lower level in the stack)

That's it. Everything else builds on top of these primitives, including

- memory (a new context block that you add to a context map)

- tool usage (which is a set of hooks on inference return and can optionally send the output straight back for inference -- this is a special case inside the inference loop and so just lives there)

- anything to do with agent operating environment (this is an extension of workflows)

- anything to do with governance/provenance/security (this is an extension of either workflows and/or agent operating environment... I haven't nailed this down yet).

I suppose I should say something about how agents and workflows work together. I've broken up 'what to do' and 'how to think' into the two primitives of 'workflow' and 'agent' respectively. An agent's context map will have a section for system prompt and cognitive prompt, and an agent can 'bind' to a workflow. When bound, the agent has an additional field in their context map that spells out the workflow state the agent is in, the available tools, and state exit criteria. Ideally an agent can bind/unbind from a workflow at will, which means long-running workflows are durable beyond just agent activity. There's some nuance here in how session history from a workflow is stored, and I haven't figured that out yet.

Generally, the idea of a workflow allows you to do things like scheduled tasks, user UI, connectors to a variety of comms interfaces, tasks requiring specific outputs, etc. The primitive lays the foundation for a huge chunk of functionality that openclaw and others expose.

It's been fun reasoning through this, and I'll admit that I've had an awful lot of FOMO in the mean time, as I watch so many other harnesses come online. The majority of them look polished, and are well marketed (as far as AI hype marketing goes). But I've managed to stay the course so far.

I hope you find your ideal fit. These tools have the potential to be very powerful if we can manage to build them well enough.

---

[1] https://news.ycombinator.com/item?id=47784743

This is literally the Whitest Kids You Know moon bears skit. If you haven't seen it, watch it.

It's a distraction, a means to control the narrative. That's it.

Oh, good to know. I haven't used them much, so I'm a bit ignorant as to how they work in larger projects.

Can't you prevent pushing from the client side with pre-commit hooks? I would expect a hook to fire on the developer's computer that prevents them from even committing/pushing (unless they nuke the hook in their local repo copy).

I know this is a tongue-in-cheek response, but this brings me great pain. The spaghetti begins quickly, and your unit/functional tests won't help you unless you hammered out your module API seams before you even began. Oh, your abstractions are leaking? Your modules know too much about each other? Multiply the spaghetti!

I won't argue with that.

But, there is plenty of open source stuff out there to enable people to have their own models, running on their own hardware. Business does not need to go to the big 3.

We're moving into the 'industrial age of software'. You exact issue, of bespoke, well thought out and well-crafted code is one that craftsmen felt at the beginning of the industrial age. Now, parts are designed and churned out by machines that no one sees or cares about (generally speaking). This is where we are going with software, and production at a truly industrial scale has its place.

And so does well-crafted bespoke software.

The engineers who built the foundation for the industrial expansion of our forefathers went through the same exact thing we're going through now. They look at what existed, and use it to inform their efforts. This is what LLMs do.

I'm not attempting to moralize here, just comment on the parallels. Do I agree that a craftman's work is consumed by the juggernauts and no second thought is given? No. I think its a shame. But I also think the output will never match the artisans that practice now. By the very nature of the machines we employ, we cannot match the skill or thought that goes into bespoke code.

This is like arguing we should only have manual looms because the mechanical looms suppress wages and destroy the livelihoods of those expert loom operators.

The tech is here. We can fight it, or adapt and embrace it.

If previous examples from the industrial revolution are anything to go by, fighting automation is a losing battle.

I'd be curious to hear more about your work on the 'Sovereign AI Stack'. I'm also working on a project that prioritizes governance and verification and I'd love to compare notes.

Importing git history is ugly but do-able. I had to do that at a previous job (splitting a git repo in two pieces or importing commit history from SVN).

I can take a look and try to create a PR around this if there is interest.

Ah! You got this before I did. I wasn't thinking Marvin, I was thinking of the other one. I forget her name.