HN user
Very cool!! I'll give it a spin! I've been using a similar approach for building a tool for agents to drive a running instance of MS word. The closed-testing loops are very powerful with agents.
Lol 100%! It's become a monstrosity of a format.
Built this to feed documents into LLM pipelines cleanly. Supports 15+ formats via a unified CLI, MCP, and Python API.
In similar work we're conducting at NJIT, we've found similar results. (We call it "Contextual Quality Contagion") Some of the most interesting comments here are about some of the real-world scenarios that are commonplace in industry: "mixed" quality codebases, as well as codebases with a mix of legacy code patterns with newer "better" patterns, causing the agents to confuse the conventions.
The minimal-pair design is honestly one of the strengths, as it tries to isolate the cleanliness from other factors (e.g. architecture, dependencies, tests) which is more rigorous than comparing repos. However, using LLM-generated "sloppified" code (rather than some kind of mechanical or human-guided) is a bit questionable.
I'd say the biggest critique which others have correctly mentioned here is the authors' choice to not check the full test suite. The claim of "behavioral equivalence" is only as good as the tests and coverage.
This hypothesis is compelling for two reasons: 1) it makes sense (garbage in -> garbage out as it were) since LLMs will mimic what they see in the codebase; 2) it matches what many engineers feel somewhat intuitively over the last year or two of using these models. Greenfield is almost always easier than joining a busy codebase. The mess comes in complex integration, and maintaining a system for legacy purposes, etc.
I have yet to be able to get a single request that isn't downgraded to Opus-4.8 fairly quickly -- my most recent request (in Claude Desktop instead of Claude Code, hoping for better results) was "Please read and analyze my recent sessions, and let's discuss any themes and patterns you notice in my usage" -- somehow this was a threat.
I've found Claude and GPT have converged again. The LLMs are bound to be commoditized, in 6 months, some open-source LLM will step in.
Yes, this is definitely awesome.
In eukaryotic cells (your cells) the cytoskeleton is needed to shape the cell, position DNA, and most importantly for this study, separate daughter cells allowing replication. Think of the complexity here, you need to make compartments to separate the copies of the genetic material, physically separated during division. Microtubules assemble the "mitotic spindle" and then pulls the sister chromatids apart from each other. After the chromosomes separate, other cytoskeletal filaments (actin and myosin) form a contractile ring, which tightens to create a cleavage furrow. The membrane pinches inward until the cell splits in two.
Bacteria work slightly differently, since they don't have a eukaryotic cytoskeleton, but they do have cytoskeletal-like proteins (FtsZ), since they divide by building the cell wall inward (I am not an expert on bacteria lol).
SpudCell doesn't have a cytoskeleton, so instead it relies on a physical membrane-rupture strategy. It makes membrane proteins from its own DNA (a-hemolysin), which inserts into the membrane. They help fuse with feeder liposomes for growth. For division, these proteins crowd on the membrane surface, creating mechanical stress which leads to membrane instability, which then splits on its own.
This is a good idea - I've been manually doing something similar for almost a year now. It's interesting to find when GPT-5.5 will catch issues with Opus-4.8's code, and vice versa. Good thinking to make it a skill.