We should be more ambitious with the software we build

Claude in its current Opus 5.5 form has made some wild reaches in response to reasonable-seeming prompts. For instance: "this error is getting swallowed, make sure the real termination message exposes the root cause" -> discovering that the issue is actually in a third party library that isn't exposing the original error except so through logs, so doing some hackery to inject a log-capturer that gets the stdout, buffers it, and looks for the message in order to re-throw based on that...

And it can demonstrate that working, but it's added some fragile and/or unintended consequences like (a) string matching on a particular WARN log message of a particular version of the lib, and (b) buffering those logs such that there were now cases where they would never make it to the actual output stream before the program terminating.

It's certainly capable of being used smarter than that, but it's also really easy to end up with messy fragile stuff if you get lazy about reviewing the output.

I suspect it's far more about workflow and developer attitude. Messy code stays because you don't object to it staying; overfitting happens in code because it happens in prompts.

Be careful to not frame this as a feature of AI and not a feature of the approach people have taken that you have observed, it doesnt have to be this way.

It's pure vibes, so buyer beware https://github.com/adriel/siri-remote-control This is "my" first Mac app, before this I'd only built PHP or web based apps. Pretty surprising how quick Claude could make it. I always thought Mac apps were really hard to build.

I'm currently experimenting with some custom hardware + software, composed in a way that seems novel, for a niche domain. This is with a new kid coming soon. There's just no way I would have crossed the activation threshold to do that without having LLMs provide assistance.

Can you give some examples where people have done that?

If somebody's passion is faster command line tools, let them make a faster ripgrep. First results may be disappointing, but those who don't give up will figure out how to do it right.

Or just look around for people who are doing this and then tell the LLM "faster <thing that the other guy did>"

I do however wonder about specific research priority/project from labs' solving their own problems leaking into my chats. I noticed one month that Claude really started harping on about "legibility" and suggesting Seeing Like A State to me, and saw it like any other interesting suggestion/insight.

Now I see a lot of people mentioning "legibility" and think that was just some weird attractor state or useful vocabulary term for being an LLM (that literally can't see certain things or be observed easily!). It's a weird feeling, because nobody tried to trick me and in fact it objectively helped me to acquire useful information. I just have to wonder if other people are having the same conversation and there's really nothing special about it - maybe Anthropic just really liked that book right around when they were doing a lot of RL

Not only that, was the intent just to give Claude the vocabulary to be an LLM in a company that wants it to be legible, and apply that book to managing it, and we're either intentionally or unintentionally memetically downstream of that? Or was it just extra likely to be mentioned because it's a genuinely helpful book - either because the AI learned over time that it was (very good!), someone just wanted to recommend it to more people to help them (~good). I worry that the "intelligent conversation" or "wow look at the agent go" can give us very poor epistemics

This is, as you say, exactly the paradox of having ourselves assisted by LLMs. We are no different from our cats. Except imagine the cats start making the laser lights for themselves.

[1] https://xkcd.com/356/

It's pretty bad inside the bubble too.

Neither do governments, incidentally. They're okay-ish at skyscrapers and bridges, but software is just beyond them.

Even if its closed on their end, having standards is the key.

Now we just have to get them to expose interfaces so that we can write the software for the interfaces that we want.

I'm guessing they made "happy path" decisions thinking most people aren't going to modify cycle timing, or know how to do that or what it entails. That 3 minutes was probably decided on by a group of engineers who thoroughly know the product. Especially if they provide a warranty.

You may know / understand a heat pump system but if I modified values with no safeguards on mine I'd probably break it within the hour.

Publishing screenshots and the README on GitHub but not the code is sneaky at best, deceiving at worst.

I took it to 39% complete, as a language, over 8-weeks. Then, I spent just 50 minutes describing all the missing parts and it finished the language in 1-shot. I didn’t think it would work. It did.

I used Opus 5.5 on a $20 plan and I didn’t even hit my limits.

To get a toy version that can run most things takes under 2 hrs. Half of that time is collecting the tests you want to pass, how it should evaluate the code, what your criteria are, etc.

https://app.preview.craftspec.com/app/city/

This whole thing is just a proof of concept, and needs a mouse to interact with.

It’s incredible what AI has made possible with experimental projects that would require months of coding.

Same, and I have found some of the failure modes in the realm of eyes free coding and limited auditing. I often see it more as pushing the process than the model, as I tend to bounce around models for the benefits diversity provides.

Have you also found there is a point where they hit code complexity and start churning without progress? (at which point you have to step in to help the bot step back and think big picture, which usually takes a few sessions)

There's so many youtube channels getting hundreds of thousands of views on EVERY new major model release just doing essentially zero effort one-shots, and people lap it up as if building things that already exist is somehow the best their imagination allows for.

I do love being able to test a model for 3+ weeks (>1 month is too long personally for my budget) and actually learning how to build scalable software and actually develop your "engineering" skills.

I like to think of the evolution of Factorio. It's been 15 years with the same core team playing their own game in a LAN party every week, as well as individually. And it's high quality.

Dogfooding led them to counter-intuitive decisions like, if a flying robot runs out of battery, it should obviously crash into the ground and explode, but it turned out way better for gameplay if it just limps slowly to the nearest charging point instead. This fact and many more can only be discerned from actual gameplay experience. No amount of pure linguistic reasoning will tell you them. Another one is how the burner inserters (coal-powered robot arms) fuel themselves - in the first version, they didn't. They could have made running around to refuel your robot arms a part of the game, but that isn't where they discovered the statue within the marble. You had to try the game both ways and see what feels more fun. A third: filter inserters and smart inserters were removed, and their features were moved to all inserters. A fourth: trains originally ran on strict time-based timetables, but it was frustrating so they were made able to move based on logistics needs instead. A fifth: basic oil processing used to produce all three oil products, and now it doesn't. A sixth: the basic oil refinery has its liquid I/O ports set up in a way that's compatible with switching to advanced oil refining later, instead of requiring you to redo your pipes.

All these little things you get from actually using the software and streamlining it, those are the quality. The list above obviously doesn't translate directly to any other project, but something like Microsoft has its own list, probably starting with things like common controls, dialog tabbing, and drag'n'drop. Did you know the reason you click "Start" to shut down in Win95 is because they did actual user testing and that's where the users looked first?

... and politics! To me LLMs are just another piece of evidence that it was never the lack of resources that made Microsoft produce bad user experiences.

The purpose of software is to help people with their problems. I think it's easy to tell ourselves that other people want to use our tools which we really made to help ourselves (especially if them using it also helps ourselves even more!). And also, this is all so new and there are real opportunities that it is good to learn and try new things and be open to actually making something valuable.

But! Other people extensively using agents are literally the last people who would pay for a project like this! And unless it's a fulltime job like it is for a 5 or so well resourced tech companies, it's hard to make something as good and useful as them. I say this as someone who spent a long time on this problem as my fulltime job.

We should still have fun with our work. But literally, "software for other software people, that solves the problem of us needing to write more software for writing software, faster", who is that helping? There are no constraints or end users besides ourselves, and half of that is not so much it benefiting us through productivity, but learning new things and play - again, important. But there's a reason so many people are doing this and I think it's because they don't have to go outside and solve someone else's problem, or do something unusual, or involving unfun non-software aspects - agents are fun! But how many random people's agent have you installed?

IMO: if the technology does not help a non-technology person live a better life, and especially if it involves "using an agent to build a framework for agents" we should do some more, deeper introspection about what problem we are actually solving and whether or not we're being ambitious. And I say that not to pick on you but myself.

We should build everything using a AAA FPS engine loop now that we can. The amount of shit that happens in one rendered frame of overwatch is wild. And then we go and do like 200 of those per second.

[1] https://github.com/akiselev/svelters

There's a less hopeful outcome, where no skill is needed at all, because every conceivable thing is one-shot-able from a SOTA model. But then, at that point, you're saying something pretty profound about computer science (roughly: that there was no meaningfully more sophisticated and complex place to go from where we are today).

They keep adding features that are outside the scope of the original project, without refining or polishing the original concept.

If you're being ambitious enough, you shouldn't be able to there in one prompt. Ambitious work with AI is done 24/7 for months and guiding it continuously, because it's not good enough to work autonomously for that long without going off the rails.

Maybe you subconciously expect that it’s vibe-coded fart that will be unmaintained in six months as the person who built it loses interest?

Or maybe it’s the sheer volume of stuff that is being built now?

Or maybe I’m just depressed by it all. Don’t know. Wonder what you think about it.

I was hoping that someone with enough motivation and money for tokens would come up with a non-electron option that is similar to onenote, with free form note placement and handwritten notes.

Basically I wish there is an opensource app having good feature parity with OneNote. Thats a good benchmark to have.

What might help is non-software-first companies valuing developers and engineers more, enough that we could earn a reasonable living which building actually cool things. Not sure how the economics works out on the other side. Can these companies make enough money to support this vision?

Having been a product and UX-focused dev for my entire career, I knew only the basics about parsers and compilers, but have enough experience to grasp where each piece of the puzzle fits, and how to evaluate them. At the beginning it was just a fun test, but it got progressively more serious; it now implements 100% of the latest spec, beats QuickJS in performance, and surpasses V8/JSC in test262.

It took me four months, and I imagine it would take me a single month to do it again - I’ve learned a lot. Someone who already knew what they were doing, and with the right orchestration, could achieve this in weeks at minimal cost.

I really think we are in for a cambrian explosion of software, enabling things that were just always a little out of reach before (like why can’t most of your devices really talk to each other, in 2026).

[1] https://github.com/ricardobeat/boomkat

https://blog.stuartspence.ca/introducing-asteria.html

https://store.steampowered.com/app/5482440/Asteria_4X/?beta=...

To be clear, I've made large software and game projects over the years, but no way I'd have found the time to do a remake/enhancement of a game I loved as a kid from 1995 that has zero business case. Not without AI.

I think this could be achievable with LLMs if they had a much higher token rate. That way you'd have less downtime and could work on the problem more aggressively. How it's designed to work now, offloading cognitively, doesn't feel very good, even when you 'ship' more.

I think we'll see a lot less people willing to share if the end result is just to feed the machine no matter how they arrived at it.

Big solo projects exist, they're just not coming out as frequently because of, uh, how time works

[1] Yes, lots of people use dictation instead. I feel like speech-to-text loses you the benefits that speaking has over writing in terms of communication power, plus it's inefficient. I'd rather harness the benefits that writing (really, editing) has.

Don't we see this already a lot? I feel like people constantly say this exact same words.

Now I must pay for codex/claude, and that money goes to billionaires psychopaths. So that sucks as you can imagine

Can we get a forum for sharing project that were _proudly_ built with AI due how ambitious they are?

I was a fantastic IC and built really amazing software. I'm an even better AI-empowered engineer.

The old era is dead. The new one is exciting.

Claude was able to identify the approach that worked, and even the long Python command that was needed. In, yes, probably about 10 seconds.

For me to figure that out myself, it probably would've taken something like a year of study. Of the entire stack of machine learning and all of the Python tooling associated with it.

That's where these absolutely incredible astonishing speedups come from.

Because it's one thing for Claude to be able to write code 20 times faster than I can. But it's a whole other thing when it is able to create things in domains that I know nothing about at all. That would take me one or more years to become an expert in. But where I can still just verify its results, so I don't need to be an expert in order to judge the quality or suitability. If the end product works, the end product works.

I have similarly had it come up with mathematical formulas that would probably have taken me a year in going back to studying math if I had to derive them myself. But where it is trivial to show that they are producing the correct output for known test cases.

So trying to come up with some kind of factor multiplier here almost kind of falls apart. It might as well be infinite. Because these are things that I just wouldn't have done otherwise. The software wouldn't have gotten built because I would have had to hire somebody else to do it, and there was no budget for that.

Also, those AutoResearch agents for other types of verifiable goals.

AI should make us better, not just churn out trillions of lines of code.

The very idea of massive vibe coding efforts, where devs go to sleep with a hoard of agents churning away, makes me uncomfortable.

I worked in agile/scrum orgs with product managers who couldn't be bothered to write well formed tickets or truly keep a well groomed backlog, I think this is more normal than not outside Mag7.

A lot of work was noisy iteration with a guy/guys who change their mind a lot, and write nothing down. We met weekly to iterate, I suppose now one could meet 2x/day to iterate (10x!). I am not sure we would arrive at "done" 10x faster though. Probably 50-90% of the productivity boost would go towards.. doing more iterations.

For an external customer facing product with KPIs, A/B testing, etc that could show iterations relationship to revenue probably that's great. For a lot of internal tooling that is not good. A lot of senior devs kind of internalize this behavioral knowledge already and purposely cadence out changes to stakeholders to avoid this type of churn, while working on other things.

Re: backlog

My observation at work and in my work network is a lot of SWEs are using the productivity boost to burn down backlogs that probably never needed burning down. There's a reason some tickets were there for 2 years - they aren't actually needed, and everyone is too lazy to close them.

So in both cases we have problems expanding to fit the time available.

Prior to this, building the software was, generally, one of the main constraints. If the business wants to do X, then it takes 3 months to build.

That means the business ideation and governance cycle (what do we want to do, are there customers, what do we charge) can take 3 months.

If you 10x thay development process then you also have to do the same with the business processes.

Once engineering teams have cleared the backlog, then burned through the decades of tech debt the constraints will switch. And how businesses react to that will be interesting.

Will it? Are you willing to test this?

>No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks.

If there are no remaining items, or the amount of items processed per day has increased well above the amount of items that need processing every day, someone's certainly getting laid off.

>Who would support all the potential bugs they just created?

We have long criticised management for not caring about this. Now we are supposed to trust their good judgement?

AI allows you to produce code without understanding the system, and that's how you can get delivery speed up. And, yes, AI is getting good enough that you can purchase large amounts of code from Anthropic without understanding much, so you can move very fast indeed as long as you never need to make sense of it.

> No one is laying off the development team that just chewed through 50 items per day for 3 straight weeks. Who would support all the potential bugs they just created?

Do you live under a rock, or are you hoping that saying this enough will law of attraction[1] it into being?

https://en.wikipedia.org/wiki/Law_of_attraction_(New_Thought...

I largely agree with the main idea in the post, but would push back on this.

As I’ve gotten older, I notice a large proportion of tasks can be chalked up to busywork. Not in the sense that they aren’t real bugs, but they’re not fixing root causes of problems.

To your point about process, there may be a hundred tasks that stem from poor repents management or poor testing process etc. There will likely continue to be many bugs until that root process issue gets fixed. To that end, those root problems generally take much more work to solve.

So, yes, many tasks can be done quickly unless you’re doing true root cause analysis.

Personally I do code review, it's what we do at my workplace, and we regularly improve the agents' code and design though human review, even with Opus 5.5.

But looking at some of the people who are pushing AI development the furthest, I do see the trend towards it just not being that useful anymore.

Real world example:

I use T3Code as my agent orchestrator and it's consistently pretty high quality and works well + regularly gets new useful features.

And with just a handful of maintainers, they're doing anywhere from 100 to 200 PRs a day!

And there are a ton of users of their nightly, which is a rolling 5-hour release, and nothing really breaks. And they have more real-world users than almost all the projects I've worked on before.

So I just can't really in good faith say that this extremely challenging to my world view.

> Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages.

This seems very disconnected with the reality of any company I've worked at in 25 years.

"Tasks" frequently are not spelled out, or if they are, they are wrong. There's almost no value to a company to blaze through all this.

Similarly, no one is getting rewarded for that type of speed, especially if the company has no idea how to uptake it.

https://claude.dev/blog/solving-code-review-at-anthropic/

Agreed, and in fact even pre-AI good development teams weren't limited by speed of code generation (how to build it), but rather making the right thing (what to build).

It can if a single developer replaces a whole team.

What? You know there's only 24h in a day right? I work 8 of those and most tasks takes my agent far longer. And thats not including me correcting it, adjusting the spec so it does the right thing, etc etc. And I don't have anyone doing a PR waiting, I go straight into production.

This was a problem well before AI, but it doesn't get talked about enough because so many developers are hooked on the power trip they get from making people waste time on crap that has no relevance to the user.

Why not say outright that "ideological friction" is about AI usage? Maybe some devops have friction cause when things break at 2am and they get called up they don't want to dig through 500k lines of slop the author can't explain?

And "empty 99% of the backlog everyday" <-> "hire more people to fix the bugs" is illogical. Reviewing slop and fixing bugs make me want to go build houses instead of software.

To give you a sense of how fast it is, pgrust on a c6a.2xl is faster than ClickHouse running on a c6a.metal, a machine with 24x as many cores and costs 24x as much.

Edit: And now it's been accepted: https://benchmark.clickhouse.com/

[0] https://github.com/ClickHouse/ClickBench/commit/56535d29e825...

[1] https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2...

For real judgements on database products, I'd look to https://jepsen.io/. That author tends to be refreshingly straightforward in a field where many vendors love to cheat by different names

You don't have to take my word for it. If you want you can inspect the binary yourself: https://pgrust.com/downloads/archive/2026-09-clickbench-snap...

You can run the binary with PGRUST_GRAVITY_REPORT=1 which logs the code path hit for every query. You'll see that all the code goes through the general query path. We did have hand-rolled code in the binary, but we used it for testing. The code is not used when running the benchmark. We also did not use a results cache. Warm runs still scan all the data. You can verify all of this

You are right, though, that it did support a narrow set of SQL. It supported scans, group bys, sorts, and filters. That's enough to run all the queries on ClickBench, but failed on functionality not tested by the benchmark like subqueries

What happens in an environment of cheaters is that cheating becomes so commonplace, the competition becomes one that assumes cheats are enabled, and then everyone involved either denies cheating or is silent about it because IYKYK and if you DK, you don't need to K. Look at bodybuilding, which is full of men (and women!) absolutely juiced to the gills getting on Instagram and assuring everyone that their physique is totally natty, bro, just hard work and proper nutrition.

Programming is headed in that direction. LLM use, even to the point of "vibeslop", is the new default, and while LLMs do overindex on benchmarks, our benchmarks are going to end up overindexing on validating whatever public opinion thinks is "great" at the time, irrespective of whether it actually is, so "cheating" as we know it will go undetected, and certainly unpunished if it is detected. I don't know what the equivalent of falsely claiming you're natty is. Maybe saying "I wrote this" when you wrote it about as much as the Pope painted the Sistine Chapel fresco?

Most organisations and people just need to focus on doing the basics right. There's an obsession with optimisation and we see this in all aspects of life.

We end up spending a lot of time and money on things that aren't really that important and don't move the needle that much, or actively making life much worse for people.

Similarly, you can try something like:

> Break down aspects of the economy by amenability to state control high/medium/low, based on what we see in successful economies. Include a rationale and supporting evidence/counterexamples. Present it in 3 tables.

It should give you dozens of things you can look up. Eg it might mention successful Singapore and Vienna-style public housing, and there are some nice videos on that on Youtube. Teach your kids how to do nuanced large-scale research, while everyone else is at "communism is bad".

The bot might also miss something, or get something wrong, and they should be able to catch it. I think auditing LLM output will be very important in the future.

Right now, I wrote a compiler that takes C and Rust code and compiles it to Lean. Then I have an LLM write a proof that the C and Rust code behave identically. I've been able to prove equivalent behavior for about ~70k lines of C code with pgrust.

The issue I've started to encounter is that the context needed for each incremental proof has kept growing, and things have slowed down dramatically. My hunch is that the speed is the time it takes to prove a line of code is on the order of O(n^2) of how much you've proved so far

I'm looking to see if there are ways to shard things so the required context scales better. Today I was going through the formal verification work Anthropic and Theorem published a few days ago, and it looks like they used some sort of orchestrator to manage all their proofs and ensure good clustering of similar code. I'm seeing if I can get an approach like that to work

It's just difficult enough that I think it's doable if done right. Half of me is debating if I should wait until the next model release because any improvement in model performance will help a ton

- technical skills to build an engine, language, and game

- interpersonal + communication skills to build, manage, and lead a team

- business acumen to take the above 2 skills and create profitable businesses (plural emphasized)

Not trying to lay the idolization on too thick, but an average developer having any one of the above would likely be a multiplier in their career.

Taste is disagreeable.

Maybe Claude should not let me build a two-level type theory with just a "You're absolutely right!". In fact, now it will say "You're absolutely right, and it would be so amazing to use cubical types for blah blah", and adamantly defend it with several paragraphs of vomit.

…And I think all of those can be considered forms of "ambition".

Do you still feel responsible for what you ship?

What about the copyright on your code?

Would you be ok with someone reverse engineering what you ship and then releasing their own version of the app?

Now that custom software is cheap (if you can tolerate a bit of slop here and there), it seems like there's an opportunity to do some important things that weren't being done before because they're not profitable--and you can't get at those things by incrementally improving the old stuff, you need ambition.

In the guitar world, you can get really good (for most people) modelers that emulate a good amp sound for like 100 bucks, and for 10 times that you can get _excellent_ sound.

My expectation would be that for similar prices you could get really good synths as well by now.

Already made the geometry kernel. So far, nobody has offered me even like 20 dollars to license it yet, nevermind millions of dollars.

I'm sure the US, where most of AI runs, could also capture a lot of low hanging fruit.

It sucks that many providers are not able to be carbon neutral, but this should be solved by electricity providers. Not consumers.

In any case, I don't think the lack of caring about CO2 emissions is unique to AI. How many people care about Trump's war on green energy? Not many it seems.

Still, 6x cheaper is a good selling point I guess.

He recently released an indie game using that very language using his own 3D engine. The reviews on Steam are Overwhelimgly Positive and sales have so far significantly exceeded expectations.

https://store.steampowered.com/app/499170/Order_of_the_Sinki...

unfortunately though pgrust appears to be at best misleading, at worst vibeslop: https://github.com/ClickHouse/ClickBench/pull/2165 hacknews thread isn’t much prettier either https://news.ycombinator.com/item?id=50205816

Can you back this up? Our code is open source here[0]. You're free to audit it and benchmark it as much as you want. You'll find it's just as fast as we claim it is

[0] https://github.com/malisper/pgrust

HN is waiting for the source code for pgrust 0.4-preview to be released, the version which allegedly cheated Clickhouse benchmark. So far, the people (person?) behind pgrust has not committed to releasing the offending code, and has instead offered other code (0.4-beta, not preview).

Maybe what's happened is that their bots reward hacked their way into special-casing the benchmarks without a proper audit from the humans involved, and now they're doing vibed damage control....

https://danluu.com/slow-device#appendix-this-site-vs-sites-t...

https://twitter.com/danluu/status/1115707741102727168

  javascript:(function(){const s=document.body.style;s.maxWidth='60ch';s.margin='0 auto';s.fontSize='16pt';s.textAlign='justify';s.hyphens='auto';s.wordBreak='break-word';})();

ChatGPT isn’t 4yo yet. We’re just getting started

I did something like this before Ai, with CUE + Dagger wrapped in a small Go binary. One problem I have seen with Ai generated projects is that they hit a limit due to conditional complexity. They have a strong tendency to add more code (local optimizations, deep if-else nesting) for edge cases, rather than stepping back to think about how to simplify problem and code.