mrothroc

7 ms·

1.
by mrothroc 21d ago
Several comments here touch on the core problem: agents are writing more code than we can review. Seniors have never had enough time to review, and the prolific output from coding agents is making it worse. Moreover, the code is almost alwa
2.
by mrothroc 2mo ago
Relevant passage from Jarred's post: "At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single
3.
by mrothroc 2mo ago
Drilling into the original article where Jarred explained the reasoning behind the change, It's pretty clear that under zig the team was doing things by hand that are automatic in rust. Humans and agents share one thing: they are both
4.
by mrothroc 2mo ago
Agents are fast and powerful, and that is a double-edged sword. The volume you can produce is breathtaking, but they make far too much for you to review every line of output. Personally, I focus my limited attention on the places that give
5.
by mrothroc 2mo ago
You have to have a multi-layered approach. This is the "Swiss cheese" model of prevention: individual layers may have holes, but if none of the holes in the stack line up, nothing makes it all the way through. I approach this by t
6.
by mrothroc 3mo ago
I break this up into two parts: assets and workflow state. All assets go in the repo, this is the context that all agents read to be able to understand what we're doing and how we do it. The workflow state is the release train with all
7.
by mrothroc 3mo ago
The biggest strength of "would this get merged" is that it is actually a compound property: does it work, does it match convention, is it maintainable. And of course: does the reviewer actually want to take ownership of it. A sing
8.
by mrothroc 3mo ago
Yes, at some point AI will be fully integrated into society so that there are entire autonomous sections. But society doesn't move at the same pace as technology. The output of agents has to have economic value, and for the foreseeable
9.
by mrothroc 3mo ago
Let me ask you this: would people accept a nuclear power plant whose safety control software is vibe coded? Would a CFO of a public company sign off on financial statements created entirely by AI? I'm fully into agentic coding, and I&#
10.
by mrothroc 4mo ago
The easy decision is to just go with the biggest SOTA model you can afford. But this overlooks the other critical part of getting the most out of these things: the harness. I run an autonomous plan/design/code/build/test
11.
by mrothroc 4mo ago
Some of it can be busywork, but for me the intermediate artifacts (plans, design docs, etc) serve a real purpose: they create a verification surface where you can check that the agent is creating the right thing before it goes all the way.
12.
by mrothroc 4mo ago
Thanks, glad you find it useful! Feel free to ping me if you have any questions.
13.
by mrothroc 4mo ago
I've been specializing in distributed systems for nearly 35 years. I've read your work, and it's shaped my thinking. When you say you have a person in mind when you write, I am that person. Thank you for what you've done
14.
by mrothroc 4mo ago
Definitely stacks. The thing that made it clear for me was being explicit about the stages, and where/what you can verify with a guardrail, or gate. I wrote up the framework I use here: https://michael.roth.rocks/resear
15.
by mrothroc 4mo ago
Yes, "guardrails" is a squishy term. But it gets clearer if you ask what transition is being guarded. Some of this is inside the model, like topic refusals. Forge sits at the tool call level. My personal workflow uses guardrails a
16.
by mrothroc 4mo ago
I fully agree with the idea: above a model capability threshold, the power comes from the harness far more than the model. Engineers can get tremendous power from learning how to do CICD and automation. If you view the models and agentic co
17.
by mrothroc 4mo ago
I have the same experience. I've been running sequential agents in my own harness that is a standard SDLC pipeline (plan, design, code, build, test). It has gates between each stage to control quality. The big benefit of automating thi
18.
by mrothroc 4mo ago
The "blurring" framing makes Simon's tension sound intrinsic when it is actually structural. Vibe coding and agentic engineering aren't on a continuum. They're distinguished by the process. Engineering is always abo
19.
by mrothroc 5mo ago
The list in the article looks like verification practices. Document intent, develop taste, find the hard stuff, etc. It assumes that when code is cheap the bottleneck shifts to knowing whether what you generated is actually right. e2e tests
20.
by mrothroc 5mo ago
From a verification-topology angle, what makes algotune.io contamination-resistant? Is it because the correctness oracle is a performance metric (which can't be memorized) rather than a fixed test that can?
21.
by mrothroc 5mo ago
Simple example to show how configs are defined: { "name": "plain_3L", // Minimal causal transformer baseline: 3 attention layers plus 3 SwiGLU layers. "model_dim": 128, "vocab_size&quot
22.
Show HN: Mixlab, an ML arch lab in Go. JSON config, Metal and CUDA, 1.6s builds(github.com)
2 points by mrothroc 5mo ago|1 comments
23.
by mrothroc 5mo ago
I addressed this in my reply to kelseyfrog above. The short version: the production work is proprietary, the tooling I used to do the analysis is open source.
24.
by mrothroc 5mo ago
Hi, I'm the original author and I can clarify a few things. The 543 hours are the agent compute hours, not me at the keyboard. The pipeline runs autonomously, the agents execute in parallel, and the gates verify the output. Most of the
25.
by mrothroc 5mo ago
Thank you for your feedback. These are fair points. I get that "top performer" is off-putting. You're right that authority has to be earned in the text (and I hope I do that), not declared. On the structure: yes, it's a
26.
by mrothroc 5mo ago
I'm the author of that post. Thank you for your feedback. The production code is proprietary work for clients, so I can't link to it directly. But the tooling I built to support the pipeline is open source: the log analyzer that c
27.
by mrothroc 5mo ago
I did the same with my own orchestrator. That's where I get my data. It's amazing the power a simple workflow with automatic gate enforcement brings to agenting coding.
28.
by mrothroc 5mo ago
I created my own framework. Long ago it started as shell scripts that I used in conjunction with aider. It was a very manual process. It's grown over time to be a full MCP and CLI with stages and gates defined in YAML. I was thinking a
29.
by mrothroc 5mo ago
Agreed that full consensus is overkill. But I think the coordination problem is subtler than version control implies. In the (plan, design, code) pipeline they aren't collaborating on the same artifact. They're producing different
30.
by mrothroc 5mo ago
I've been running a multi-agent software development pipeline for a while now and I've reached the same conclusion: it's a distributed systems problem. My approach has been more pragmatic than theoretical: I break work into s

More ›