trjordan

This is RL, right? Like, this is exactly why models have mostly converged around obvious style, because we train them literally on thumbs-up/thumbs-down data of what good behavior and good code looks like.

And that's why it's so hard to get a model to reproduce the specific taste of a person or an organization. My taste is different than yours, so if we dump our aggregate preferences into RL, in averages out to nothing interesting.

For the code-writing case, this means you end up reviewing every line of code, looking for places where you'd thumbs-down the code. Not every line of code contains a real decision, though, so it feels like a waste of time.

You can't unit test for taste if you haven't written down what you mean by taste. If you can externalize it, then you can.

Follow this line of thinking, and the AI-friendly answer is easy: we just have to externalize everything we know, so Claude can implement what I want.

Except that I can't fully externalize myself. Debugging a system takes more resources than running the system. If I could write down everything I know and hand it to a machine, I'd do that, but it impossible.

People aren't books or hashmaps. If you want to build something, you need to use the tools, not teach the tools to use you.

[edit: I'm trying to figure out if there's something to be done about this. Email me if you want to chat -- tr at tern dot sh]

If you didn't take the time to write it, why should I take the time to read it?

This is a band-aid. Maybe even a good band-aid, because it'll keep individual contributors from flooring the zone. But the core problem is Github's model that assumes code is worth reading.

I'm much rather see the agent logs stapled to PRs. Make it easy to understand if there's a brain behind the suggested changes before engaging.

I think there's 2 important, but separate, ideas in this post:

- Models are not good at or getting better at creating strong invariants, which his fundamental to good software

- It is unclear how to keep tabs on what the agent is doing, so you, a human, can intervene.

These are related, obviously: one of the highest-leverage things you can do is force you agent to use a strong, minimal set of types or data invariants or other constraints. They get much better when your codebase broadly supports this!

I do suspect they're separable, though.

If you had the right levers and visibility, you should be able to get the model to produce code that doesn't feel like slop. But every time I've had a model try to keep me in the loop, it inundates me with irrelevant decisions and busywork. Its inability to see what's structurally important still shows up, just differently.

[If the models get better at defining and respecting invariants, maybe there's a new flavor of slop, that's less obvious today.]

The worst thing that can happen at an early company is that it sort of works.

I like the deal where I roll the dice and don't have to work again if I win. I'm fine with the deal where I take a barely-passable salary and do something wacky for a year.

The worst deal I can imagine is that the startup slowly grinds its way to profitability over 3 years, can't raise, and grows 15% / year.

Every company I've seen do that never fixes the salary issue. Everybody's still making their seed-stage base, or maybe +25%, which is still a 30% pay cut from the last job they had. Their equity is worth nothing. There's no career advancement, because there's 2 staff jobs and 3 EM jobs and 1 VP job.

There's lots of ink spilled about how founders expect early employees to work hard, perhaps too hard for what they're paid. It goes the other direction, too: early employees should expect founders to succeed, because there's always another startup to join.

The core of the problem is that there are a million tools that make AI better, and no ways to measure whether AI is working better.

Big companies with popular products have it. They do something between normal product analytics and chatbot evals to figure out if users are being successful in their sessions. That's the job.

But any given dev, with between 3 and 50 sessions a day? Like, I have no idea what makes the LLM better. It's all vibes.

My company has a whole stack here. Preferred harnesses, preferred models, skills, the shape of our code, everything. There's gotta be a way to measure whether this setup is working for us, at 1 / 1-million-th the scale of a Claude Code.

Would love to chat -- ping me tr at tern dot sh

I think it's worse than that. At least if I dumped 5k LoC on somebody in 2021, you knew I spent the time to write it, so it's "fair" to ask you to read it. But I didn't write it in 2026, so you shouldn't read it.

I think it's less about "break it down" and more about "let's communicate at the same altitude."

I wrote a (bait-titled) post about it: https://tern.sh/blog/stop-reading-prs/

We're working on it, thought it's all early. I'd love feedback: https://tern.sh

First product compares the code to the prompts and highlights places the agent made decisions you weren't involved in: https://tern.sh/docs/tours/

> Those are not code problems. They are evaluation problems.

> Code becomes precious when it is the only place knowledge lives.

Reading AI code all day is _agonizing_. Just, a horrible way to live, and it melts people's brains at the moment you need them to be the most capable.

Manual programming has this really productive and gratifying feedback loop, where you read the code, write the code, and fix it until it compiles/runs/does what you want. AI code not only does half that for you, but it makes the "click" at the end uninspiring because you're never sure if it's cheated a bit to get to that moment.

Trying to operate with AI-generated code as the only durable artifact of programming is a dead end for the industry. Charity points to (and correct discards) architecture diagrams/specs as an interesting space to work in. My suspicion is that it's closer to the thing that's hand-written: prompts, markdown plans, and other nudges. Focus on the thing that you, as a human, produce, and that's the basis for both the core loop of "did the AI follow my instructions" and it's higher-leverage when you go to code review.

By the time you get to the PR, you've probably typed enough to Claude that you can regenerate the code, but the current industry default is to just throw away all those sessions and ship the code. That's backwards!

There's a neat / weird ladder that I keep seeing friends go through as they work through this.

- Volume. Kill the backlog! 8 agents in terminals, frantically!

- Ambition. Do the things you always want to do! You have the power!

- Clarity. Oh god I have to figure out what to do next.

That last one is honestly super-hard, but it's also the most valuable. Like, do you want to wake up every day and find new work, because you understand the machine better than everybody else? I know a bunch of people that love that stuff, but also a bunch that don't. I totally get that the transition is hard.

https://tern.sh/blog/volume-ambition-clarity/

Totally. Every "we're losing our craft" article has the same gloomy shape. That's enough of a bummer, but they also argue against themselves halfway through.

This one, for instance:

> But exactly which details are deemed “unimportant” is a very consequential and sometimes subjective decision. And eventually, the details always leak through.

Right, so you're saying this new technology will still reward deep technical understanding, because there's no way around it. I agree. Why is the whole tone of this thing "AI is making my craft a cheap commodity?"

Websites are largely better, technically, than they were 10 years ago. They're more full-featured, they're faster, SSL/a11y/responsiveness are stronger defaults. Content mills / SEO / news sites are a separate, terrible failure mode of ads and corporate incentives. That's not React's fault!

It feels like we're far past the point of where having AI do more faster is helpful.

It's telling that they used "rewrite Bun in Rust" as the proof point here. It's cool! But the vast majority of software engineering doesn't start with tens of thousands of tests, where making them pass is the whole job.

In my experience, AI still drifts from what I meant it to do on anything bigger than building a widget. My time is spent suspiciously reviewing output for changes the agent snuck in, or invariants it broke. I talked with a friend recently where the agent broke the test harness badly enough that none of the tests mattered for 3 weeks. They did pass, though, so CI never complained.

There's something at the intersection of context engineering, managing that sloppy pile of markdown plans, and good old fashioning system understanding that's the real bottleneck.

From the verge: https://archive.is/kU4Zg

> Gartner forecasts that large AI companies would need to earn cumulatively close to $7 trillion in AI-driven revenue through 2029, which is close to $2 trillion per year by the end of the period. In order to achieve “historic returns,” the providers would need to earn nearly $8.2 trillion in the same period.

They've got, ballpark, $5t to $10t to make back in the next 5 years, or the hardware buildouts will start getting written down.

This means we're going to need $1t+ per year in spending, per year, on tokens. 200m knowledge workers in the world, 30m developers. We're talking about a world where you need 5% of every knowledge workers salary to go into tokens. 20% if you're a developer.

That's a _huge_ shift. Most people I know cite +20%-40% velocity with these tools, against the actual work their company cares about doing. +20% speed for +20% spend isn't going to motivate a trillion dollars a year in spending.

We're not there yet. This is still the upswing of the hype cycle, and unless we figure out how to make developers 2x, 5x, 10x as productive on stuff that matters, this isn't going to play out well.

This is ... not new at all?

App-bundling apps existed. Apple rejected them.

Low-code apps existed. Terminals existed. Apple rejected them.

LLM apps exist. Apple allows them, because they render text, pictures, and video, but they don't run arbitrary code.

Running arbitrary code is flatly forbidden, because users can't reason about them. I see absolutely no evidence that software is moving away from versions, any more than it was when apps could first search the internet, render recommendations, or deliver messages.

Yes, but: writing code always teaches you something.

I've worked at founder-sized startups and $xxb dollar public companies. I've never read a product spec, a pitch deck, or a PRD that describes a solution that, if implemented in the way described, would solve the problem. Building the thing teaches you how it should behave.

Software is a complex, interactive medium. Iterating in the code, with people who understand the problem and care to see it solved, is the only way I've seen valuable products get created. Meetings and diagrams help, but it's not until you write some working software that you know whether you have something.

Color me unsurprised.

Anthropic ran a weeks-long roadshow on how powerful Mythos is. They pointed to the danger, their controls, the capabilities, and practically begged the world to be scared of it.

Simultaneously, the current US regime realized there was a way to demand fealty from the AI labs. If they're so dangerous, don't we need to see them first? That will cost you, obviously. Standard extortion from the government, at this moment in time.

The labs get their marketing; the white house gets its pseudo-bribe. I hope nobody involved is confused about how we ended up here.

Nah. Worse is better.

The reason agents work is because they have access to stuff by default. The whole world is context engineering at this point, and this proposal is to intermediate the context with a bespoke access layer. I put the bare minimum into getting my dev instance into a state where I can develop, because doing stuff (and these days: getting my agent to do stuff) is the goal.

This makes slightly more sense if you're building a SaaS and trying to get others to give you access to their code, their documents, and the rest so you can run agents against it. But the easiest, most powerful way is to just hook the agents up to the place that's already set up.

> figuring out if the company can afford this level of productivity at scale

This is the thing that boggles my mind. They spent their budget. They have 4 months of data. What do they have to show for it?

I'm not a hater; I'm not a luddite. I have a $200 Max plan and I use it.

But are you saying that Uber made this tool available, urged everybody to use it, and is confused about what happens when it worked? It's one thing if they decide AI isn't productive enough to be worth the cost.

Are they out of ideas on what to build next, or something?

It's an honest surprise that this isn't spun as "internal AI efficiency gains." They want the efficiency, of course there's AI component, but they're not pre-claiming victory. Neat.

It's worth remembering that there's an _actual_ underlying economic problem here. Interest rates are up. AI spending is expensive. A dollar invested in a company needs to do _more_ than it did 5 years ago, relative to sitting in treasury bills. And Meta isn't delivering on that right now.

But IMHO: that's no excuse. This is admitting defeat, deciding to push the share price higher while they give up. Meta has the user data, the AI ambitions, the distribution, and the brand.

They could do anything, and the world is re-inventing itself. They're ... laying off people, maximizing profits, and giving up.

Cowards.

lol sorry, I just spend to much time on LinkedIn, I think. I promise this was 100% human-written.

As a pratical lens on this advice: people are excellent at giving feedback on their problems. They are terrible at identifying how to fix it.

"It felt too long" was right. The solution was not to make the story shorter. The solution was to look at the parts that felt long, and believe that feedback.

If you're building something, and your users tell you it's complicated or it's slow or it's not useful, they're right! The fix may or may not be to make it simpler, faster, or more useful. Maybe it needs to be organized better, or to create deliberate moments of action, or to be used at a different time. The problems are real, but the obvious solutions are not always right.

> Wait for a beloved brand to hit financial trouble. Buy the intellectual property out of bankruptcy: the name, the logo, the trademarks.

The alternative is to shut down. That's how this whole system works: the brand can be sold, because the alternative is to cease existing.

I hate that the brand is worthwhile on its own. But: that's the point! The company invested in making the brand worth something by having it represent a promise. That promise isn't worth anything when the brand can be sold separately from the process of making the thing. The brand continues to be worth something, though.

This mechanism is a core feature of capitalism. Companies can be sold for parts, and those parts can lie to consumers. There's almost certainly a regulatory answer, but the behavior of the roll-up firms isn't unique to any particular firm. It's exactly the kind of value extraction the system is designed to support.

I'd offer a different approach: think about how you're going to validate. An only-slightly-paraphrased Claude conversation I had yesterday:

> me: I want our agent to know how to invoke skills.

> Claude: [...]

> Claude: Done. That's the whole change. No MCP config, no new env vars, no caller changes needed.

> me: ok, test it.

> Claude: This is a big undertaking.

That's the hard part, right? Maybe Claude will come back with questions, or you'll have to kick it a few times. But eventually, it'll declare "I fixed the bug!" or summarize that the feature is implemented. Then what?

I get a ton of leverage figuring this out what I need to see to trust the code. I work on that. Figure out if there's a script you can write that'll exercise everything and give you feedback (2nd claude session!). Set up your dev env so playwright will Just Work and you can ask Claude to click around and give you screenshots of it all working. Grep a bunch and make yourself a list of stuff to review, to make sure it didn't miss anything.

I utterly love Hammerspoon.

It's fun to combine with qmk [0], which gives you a bunch more options for hotkeys on your keyboard via layers. I've ended up with a layer where half the keyboard is Hammerspoon shortcuts directly to apps (e.g. go to Slack, to Chrome, etc.) and half of it is in-app shortcuts (like putting cmd-number on the home row, for directly addressing chrome tabs).

Between this and one of the tiling window manager-adjacent tools (I use Sizeup), I can do all my OS-level navigation directly. "Oh I want to go to Slack and go to this DM" is a few keystrokes away, and not dependent on what else I was doing.

[0] https://qmk.fm/

A similar argument to OpenAI: https://www.latent.space/p/ainews-why-openai-should-build-sl...

The push for simplicity can't be at the time of recognition. It has to be during the building, so that by the time the thing gets built, it's the simplest thing that met the need.

Can you actually imagine a promo committee evaluating the technical choices? "Ok, this looks pretty complex. I feel like you could have just used a DB table, though? Denied."

Absolutely not! That discussion happens in RFCs, in architecture reviews, in hallway meetings, and a dozen other places.

If you want simplicity, you need to encourage mentorship, peer review, and meaningful participation in consensus-building. You need to reward team-first behavior and discourage lone-wolf brilliance. This is primarily a leadership job, but everybody contributes.

But that's harder than complaining that everything seems complicated.

"Red lines" does not mean some philosophical line they will not cross.

"Redlines" are edits to a contract, sent by lawyers to the other party they're negotiating with. They show up in Word's Track Changes mode as red strikethrough for deleted content.

They are negotiating the specifics of a contract, and Anthropic's contract was overly limiting to the DoD, whereas OpenAI's was not.

Having recently set up sentry, at least one of the ways they use this is to auto-configure uptime monitoring.

Once they know what hosts you run, it'll ping that hostname periodically. If it stays up and stable for a couple days, you'll get an alert in product: "Set up uptime monitoring on <hostname>?"

Whether you think this is valid, useful, acceptable, etc. is left as an exercise to the reader.