markbao

This is great. People always talk about how important the harness is and yet we have so few harness benchmarks. Agree with sibling commenter that ‘harness x model’ is needed.

People always talk about how Cursor harness has some secret sauce; would like to see how that one stacks up.

Thanks for making this and filling a real gap!

I’ve never had an agent fail to write the actual implementation. Has it done so badly, yes, but not nothing but tests. This sounds to me like a rare case that doesn’t generalize.

If the general idea is that these agents write too many tests, sure I guess? ‘Too many tests’ doesn’t sound like a failure case of engineering to me; typically software has had too few tests. Also, a lot of the power of these agents is their ability to self-verify and correct, which the test loop is a part of.

Nobody is making you pay this supposed tax. Just tell it not to write tests.

Y'all need to try PR review tools that split PRs into chapters. Stage was the best product in this space, but Linear Review has it, Graphite has it, and some other tools too. You get the full contexts while each piece is still reviewable individually.

For me absolutely not. Fable 5 has been a step function change in the ability to hand off stuff to Claude. Opus 4.5 was itself a step function but I was still steering that significantly. Fable is one-shotting stuff that took multiple redirections in 4.5.

This is phenomenal. I know everyone is asking for their pet feature in this thread, but I would really like to see this in split keyboard format. They are much more comfortable to use since they put your wrist in a more natural position. And there are hardly any good split mechanical wireless keyboards – and certainly none this thin.

Great work on this and congratulations on the launch!

And to be specific, the METR study was using the Cursor harness with Claude Sonnet 3.5/3.7, along with other models of that era of the participant’s choosing.

Which is ancient at this point, and half a year older than the November 2025 inflection point when agentic coding got really good.

The original article is from August 2025, and the overall message to not trust ‘how it feels’ and rather measure outcomes seems right to me despite the outdated figures. On my team at least, we are seeing a noticeable inflection in work shipped with AI according to Weave.

And the comment you’re replying to, which is entirely a reasonable opinion, was flagged, proving their point. I’ve been here for 18 years and similarly alienated by the cynicism here.

I don’t think this is entirely wrong, in that there is a ‘class thing’ about riding the bus, but it’s more practicality than a class marker for a lot of people.

- In SF you can either walk 1-10 minutes to the bus, wait 0-15 minutes for the bus, tap on (while watching most other passengers evade the fare), get dropped off, and then walk 1-10 minutes to your destination… or spend an additional $5-10 to get Ubered door to door at a third of the time. First and last mile are real costs.

- In SF I Uber, unless Muni/BART is a straight shot. In NYC I take the subway. It’s not really a class thing. In NYC it takes longer to Uber much of the time and it costs several more times than the subway. You still have a 1-5 minute first and last mile problem, but headways on trains is decent and above ground taxis are incredibly inconsistent with traffic.

That about matches up with the experience with social groups in similar classes in these areas too. Most of my SF friends Uber. Most of my NYC friends take the subway.

I’m all for standardization but you could just use this argument to keep any suboptimal status quo in place. XML is good enough and a standard. SOAP is good enough and a standard. etc.

The claim is that Conventional Commits are good enough and standardized enough that having another structure isn’t really worth it. But “worth it” is subjective. I’d say that if you are making commits and reading PRs every work day, and the conventional commits format causes a little bit of friction, that friction can add up. Having another option other than seeing conventional commits as a law of nature gives options for teams who prefer it. (Most teams aren’t generating changelogs anyway.)

That seems a bit reductive. Even with humans, there’s a range of interpretations and ways that something can be built or a task completed. Engineers remember stuff so you don’t have to keep repeating yourself. Skills are a way to describe your outcome without similar repetition.

I don’t really buy that Claude Design will remove all the complexity around design. Vibe-coded apps using Claude look simpler because they are simpler. They’re not a gigantic product suite with extremely specific UI components tailored to each use case. The ‘simplicity’ is an illusion coming from conflating the complexity of a bicycle (a vibe coded app) with an airplane (an app like Figma).

Building the same design system component in code versus in Figma is going to be slightly more succinct in code; Figma’s primitives don’t have the sort of conditionals and control flow that code has. But code is much less malleable than drawing on a screen, and creative freedom is harder to achieve in code.

UI can fix the gap where code feels less malleable than Figma, but complexity comes largely from the worlds that humans create, and humans apparently want to create 8 modes for 4 products and 2 light/dark modes. If you want the same setup in Claude, it’ll be a little easier to maintain, but not much less complex.

Goody | Remote | $150–250K + equity and benefits | US and Canada | Full-time

I'm Mark, the technical co-founder and CTO at Goody. We're building a gifting product that every business can use to recognize employees, retain customers, and accelerate sales. Despite being something everyone does, gifting is one of the areas of commerce yet to be disrupted, and we're working on building the best and most delightful product in this space.

Our product is used by Google, Stripe, Anthropic, Meta, NBCUniversal, Notion, and others, and we also offer a developer API for commerce. Tech stack is Ruby + React + TypeScript, though we're flexible on backend language if you know Python or Node.js better. All roles are full-stack.

We're coming off of a big year and planning for scale in 2026 with openings in our engineering team.

• Staff Software Engineer ($200–250K) — for those who ship at a startup pace and have a great eye for detail

• Senior Software Engineer, Customer Engineering ($150–200K) — if you like to hear a customer request in the morning and tell them it’s shipped in the afternoon

• Senior Software Engineer, Growth ($150–200K) — be the engineer who has the most direct impact on our growth

We're looking for people who have great startup energy, want to win, and bring great vibes to our tight-knit team.

https://jobs.ongoody.com/#hn

> What’s become more fun is building the infrastructure that makes the agents effective.

Solving new problems is a thing engineers get to do constantly, whereas building an agent infrastructure is mostly a one-ish time thing. Yes, it evolves, but I worry that once the fun of building an agentic engineering system is done, we’re stuck doing arguably the most tedious job in the SDLC, reviewing code. It’s like if you were a principal researcher who stopped doing research and instead only peer reviewed other people’s papers.

The silver lining is if the feeling of faster progress through these AI tools gives enough satisfaction to replace the missing satisfaction of problem-solving. Different people will derive different levels of contentment from this. For me, it has not been an obvious upgrade in satisfaction. I’m definitely spending less time in flow.

If you save 3 hours building something with agentic engineering and that PR sits in review for the same 30 hours or whatever it would have spent sitting in review if you handwrote it, you’re still saving 3 hours building that thing.

So in that extra time, you can now stack more PRs that still have a 30 hour review time and have more overall throughput (good lord, we better get used to doing more code review)

This doesn’t work if you spend 3 minutes prompting and 27 minutes cleaning up code that would have taken 30 minutes to write anyway, as the article details, but that’s a different failure case imo

Goody | Remote | $150–250K + equity and benefits | North/South America | Full-time

I'm Mark, the technical co-founder and CTO at Goody. We're building a gifting product that every business can use to recognize employees, retain customers, and accelerate sales. Despite being something everyone does, gifting is one of the areas of commerce yet to be disrupted, and we're working on building the best and most delightful product in this space.

Our product is used by Google, Stripe, Anthropic, Meta, NBCUniversal, Notion, and others, and we also offer a developer API for commerce. Tech stack is Ruby + React + TypeScript, though we're flexible on backend language if you know Python or Node.js better. All roles are full-stack.

We're coming off of a big year and planning for scale in 2026. We have a few new roles to accelerate our growth.

• Staff Software Engineer ($200–250K) — for those who ship at a startup pace and have a great eye for detail

• Senior Software Engineer, Customer Engineering ($150–200K) — if you like to hear a customer request in the morning and tell them it’s shipped in the afternoon. US and Canada only for this one

• Senior Software Engineer, Growth ($150–200K) — be the engineer who has the most direct impact on our growth

We're looking for people who have great startup energy, want to win, and bring great vibes to our tight-knit team.

https://jobs.ongoody.com/#hn

My email is open for any questions: mark@ongoody.com

An intuition for what people like.

Inherently subjective, but you can still approximate ‘more or less tasteful’ by how many people respond well to it.

That is exactly the type of awesome app that can now be built. I edited my comment to clarify that the grocery app and $5/month app are separate examples, but I think your example shows that someone with coding knowledge can build something extremely useful for n=1 users which I fully support.

I just don’t think most people will end up doing that just like how most people don’t 3D print their own desk drawer organizers even when Gridfinity does all the work for you. Automation doesn’t fully replace the volition to build a thing and make tricky decisions that are familiar to us software engineers but not others.

Yes, that’s a possibility! And for app types that have a limited ceiling of how much value they can provide, that will definitely be a thing as an AI app can saturate all of that value.

But for apps that have a lot of ceiling, people will still gravitate to apps that have had more care and attention than someone vibe coding it once and throwing it on the store, just like how people choose those well-built and maintained apps today over using their built-in Reminders app.

Everyone who has built software knows that the hardest parts involve making complex, tricky decisions with tradeoffs. Let’s say you make a grocery list app. Now you have to make decisions about all the different ways to specify quantity. Units, weight, dollars, bunches… oh, and fractional vs. decimal weight, etc…

The claim is that now every random person now will build their own app and have to make those hard decisions instead of paying $5 a month for someone else to do that work. Comparative advantage doesn’t just apply to the cost of writing code, but also the effort of making product decisions.

Edit: I don’t mean that a grocery app should cost $5/month, the grocery app was a toy example and the $5/month refers to an example of a separate app you’d pay for with much more value.

There’s a difference between abstracting away the network layer and not understanding the business logic. What we are talking about with AI slop is not understanding the business logic. That gets really close to just throwing stuff at the wall and seeing what works instead of a systematic, reliable way to develop things that have predictable results.

It’s like if you are building a production line. You need to use a certain type of steel because it has certain heat properties. You don’t need to know exactly how they make that type of steel. But you need to know to use that steel. AI slop is basically just using whatever steel.

At every layer of abstraction in complexity, the experts at that layer need to have a deep understanding of their layer of complexity. The whole point is that you can rely on certain contracts made by lower layers to build yours.

So no, just slopping your way through the application layer isn’t just on theme with “we have never known how the whole system works”. It’s ignoring that you still have a responsibility to understand the current layer where you’re at, which is the business logic layer. If you don’t understand that, you can’t build reliable software because you aren’t using the system we have in place to predictably and deterministically specify outputs. Which is code.

This is not hype-chasing. AI is a key part of software engineering now. For this to be absent from Xcode would be an existential risk for the future of the product.

TUI is easy to train on, but hard to use for users. Part of the reason it’s easier to have LLMs use a bunch of Unix tools for us is that their text interface is tedious and hard to remember. If you’re a top 5% expert in those tools it doesn’t matter as much I guess but most people aren’t.

Even a full-featured TUI like Claude Code is highly limited compared to a visual UI. Conversation branching, selectively applying edits, flipping between files, all are things visual UI does fine that are extremely tedious in TUI.

Overall it comes down to the fact that people have to use TUI and that’s more important than it being easy to train, and there’s a reason we use websites and not terminals for rich applications these days.

Goody | Remote | $150–250K + equity and benefits | North/South America | Full-time

I'm Mark, the technical co-founder and CTO at Goody. We're building a gifting product that every business can use to recognize employees, retain customers, and accelerate sales. Despite being something everyone does, gifting is one of the areas of commerce yet to be disrupted, and we're working on building the best and most delightful product in this space.

Our product is used by Google, Stripe, Anthropic, Meta, NBCUniversal, Notion, and others, and we also offer a developer API for commerce. Tech stack is Ruby + React + TypeScript, though we're flexible on backend language if you know Python or Node.js better. All roles are full-stack.

We're coming off of a big year and planning for scale in 2026. We have a few new roles to accelerate our growth.

• Staff Software Engineer ($200–250K) — for those who ship at a startup pace and have a great eye for detail

• Senior Software Engineer, Customer Engineering ($150–200K) — if you like to hear a customer request in the morning and tell them it’s shipped in the afternoon. US and Canada only for this one

• Senior Software Engineer, Growth ($150–200K) — be the engineer who has the most direct impact on our growth

• Data Analyst ($80–140K) — build models to help power decision-making across our business (not a dev role but thought I'd include it)

We're looking for people who have great startup energy, want to win, and bring great vibes to our tight-knit team. Great time to join since our offsite in London is happening soon (we're US-based, this is our third international offsite).

https://jobs.ongoody.com/#hn

My email is open for any questions: mark@ongoody.com

Is Postgres fast enough for job processing these days? We do hundreds of millions of jobs now and even years ago when our volume was a fraction of that, we got a huge performance boost moving from Postgres + Que to Redis + Sidekiq. Has that changed in the intervening years?

Not an academic, but I used LaTeX for years and it doesn’t feel like what future of publishing should use. It’s finicky and takes so much markup to do simple things. A lab manager once told me about a study that people who used MS Word to typeset were more productive, and I can see that…

This is a great option if you work outdoors a lot. As a designer though, I couldn’t get used to the “dusty” appearance of the nano texture (and yes, contrast loss – glossy displays are just more punchy) at least on the Pro Display XDR. You mostly get used to it if you aren’t doing design, I’m guessing.

Def a tradeoff that depends on your lifestyle if you work outside a lot (or want to). It does look nice there in the mountains

Yeah, I think designing a system for the LLM to check its own work will replace prompt engineering in key LLM techniques (though, it itself is a form of prompt engineering, but more intentional.) Given that LLMs are doing this today already (with varying success), it might not be long until that’s automated too.

That’s not the point of this. This was an exercise to measure the strengths and weaknesses of current LLMs in operating a company and managing operations, and the video game was just the simulation engine.

+1. There’s also more upstart motorcycle makers than car makers willing to take a bet on new tech. Plus the difficulty of scaling manufacturing to serve much larger capacity car batteries.

Hi randomsofr, this posting has been continually posted since we are hiring on a rolling basis, not just for a single position. We have made hires for this position over time and continue to have openings.

We mention in our post-submission message that we only reach out if there’s a match, to spare applicant inboxes from negative messages (though perhaps we could make this messaging clearer). This follows what some companies such as Anthropic do and some of the reasoning in this post https://pablofernandez.tech/2023/02/03/you-should-not-send-r...

But I know that different people have different opinions on this, and we might shift to sending notification emails after resume review. I appreciate the feedback and I’m sorry about your experience here.