We should be more ambitious with the software we build

danluu.com

366 points by ltratt 11 hours ago


Amekedl - a minute ago

Would love to see the author actually go deeper into details: what did they eval with models implementing zstd?

Many such cases are benign in the sense they in practice are simply the model basically "git clone"-ing the code they need to complete the implementation.

The amount of recall and synthetic data slop makes it imho very hard to actually get the models to really do something more novel (where they fall apart more often)

apatheticonion - 12 minutes ago

Agreed. I started writing a desktop GUI harness in Rust using native desktop GUI APIs.

Claude, Codex, Opencode, everything is Electron. With agents and solid engineering fundamentals, I set out to prove that we don't need to take that shortcut any more and we can, in fact, ship high quality/performance applications.

It's still early days - but I got something basic working. I've embedded the Goose harness as a back end and am using the UI framework used by the Zed editor.

https://github.com/alshlabs/quill

I'm keeping the source closed for a little while. Also if anyone from the major labs is hiring, hihi, I make quality things.

Also I'm aware that this is a rip off of vscode's design. I like their UI, lends itself well to projects and so on. In a different life I might have ported vscode to Rust - but no one uses IDEs any more haha

bob1029 - an hour ago

Our processes around software should come first.

A lot of the AI discussion seems to be focused on what these tools mean for an individual developer, but in a team setting any gains are at risk due to coordination tax and ideological friction. In my experience the ideological friction is most of it right now.

Figuring out a way to accelerate the process in light of the code writing bottleneck being removed is essential. I've observed a development team regress back to fully manual development because their daily PR/code review process is too slow. It doesn't matter how fast you write code if you can't actually merge it and ship it to the customer faster too. PR stacks can only take you so far before the conflict monster gets too big to fight.

I don't think AI can fix the process, ideology or people issues. I've seen how long an average PR review actually takes. If these employees were simply doing their jobs at all we'd be 10x better off regardless of AI. A truly skilled developer who makes a genuine attempt should be expected to solve 99% of their tasks within the same business day as of October 2026.

Burning down the backlog to zero doesn't mean the development team will be subsequently laid off. Quite the contrary. It will create a vacuum that the business will fill with new work that may incidentally increase the developers' compensation packages. 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? That's right. They might hire even more developers. This is called a "win-win" scenario. Not every game must be zero sum, but I understand rejection of this possibility to be part of the aforementioned ideological issues.

thepoet - 41 minutes ago

More than ambitious, I can now build things I had no time for but had the idea and architecture in place since long. A cool side project for me recently has been to allow reading more than books on my Kobo reader. I built an SDK and apps that allows e-ink apps with sandboxing and permissions model, auto-updates, shared capabilities etc. to be built for Kobo https://github.com/BandarLabs/Cobalt

fy20 - 2 hours ago

I think it's worth remembering that outside of our bubble the quality of software is pretty bad. I had a Hitachi heat pump (not recommended) installed earlier this year, and the software is pretty disappointing. It mostly works, but there are so many undocumented features and hard coded values that should be a configuration option but are not.

For example when the heat pump reaches the target temperature it shuts off, then after 3 minutes switches on again. To prevent short cycling, I'd like to decrease the time between runs (so increase the 3 minutes) but that can't be changed. Somebody decided that 3 minutes is the correct value for everybody and that's it.

I bought a €400 interface box (basically just a serial to IP interface, I guess $20 of hardware tops) to try and improve it. The €8000 heat pump doesn't come with WiFi or ethernet out of the box, you need to buy an accessory for that. It's not made by Hitachi, but it's an officially recommended accessory. One of what feature I wanted it for - which is advertised in their marketing materials - doesn't work.

I emailed them, and they said it's probably because the display I have is a newer revision and doesn't allow access to the setting I need to turn on. And without turning that setting on I can't use the feature as advertised. They said I should email Hitachi and talk to them instead as it's not their part that's the issue.

I look forward to the world where all software is either open source, or at least reverse engineerable to the point where you no longer have nonsense like this.

fritzo - 2 hours ago

We should be more diverse with the software we build.

Any prompt jockey can make a faster ripgrep. The spec is "faster ripgrep".

What is the one thing that only you can specify, where your competitive advantage is maximized? Find that thing and pursue it with all your energy!

blueblazin - 6 hours ago

With every new model I've been attempting to build something that takes at least 1 month and really pushes the model. So far I've done:

- Python interpreter in Rust (fail): https://github.com/BlueBlazin/pyrs

- Low-poly Google Earth like engine (success): https://github.com/BlueBlazin/lowpolyearth

- Codebase -> 2d infinite-zoom visualization (success): https://github.com/BlueBlazin/blockviz

I have never understood or liked all the obsession with one-shot builds.

Supermancho - 9 hours ago

This statement stood out to me.

> I have a similar thought about "there's no reason for software to be slow" BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize, perf-wise, for all the use cases you should care about, nor will be maintainable upon future changes.

LLMs have hardened hundreds of apps where I work.

Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.

Ofc, if you have:

- Functional tests - you'll be able to see it in the execution times of specific APIs

- Stress testing - performance profiling is the most important output artifact

okamiueru - 13 minutes ago

Surely I'm not alone in finding it disturbing how little regard people seem to have for the use of energy.

__s - 8 hours ago

LLMs are great for being nerdsniped. I started work on walshadow (reading pg wal into clickhouse) to demonstrate the project's infeasibility, but pieces started coming together into something reasonable & order of magnitude faster

The project would've been impossible for me without LLMs. & even with them there's an argument that this project is pushing complexity limits too far. But at least with ETL there's a clear feedback loop to build on

davedx - 19 minutes ago

Yup.

I am currently throwing a lot of tokens exploring various theories of speeding up matrix multiplication on Metal.

If you won't be ambitious why do you assume somebody else will?

lubujackson - 8 hours ago

We should be more ambitious, but we need to learn how we can be ambitious with AI, and what value we can create.

AI can take us from 0 to MVP in a prompt. It can fill in gaps of knowledge and allows someone who knows half of the stack to build the whole thing nearly seamlessly. These are superpowers but don't by themselves lead to new products.

What AI cannot do is remove the world of complications that happen after the MVP - product feature tradeoffs and choices, how to handle integrations and customizations, how to serve multiple types of users, how to communicate and market the app, how to handle security and data storage, how to deal with customers and bugs, etc. All of these need to be considered and acted on by a human in some fashion. AI can help with each concern but can't solve them without understanding the concern and determining how to frame it in a prompt.

This is why we have a glut of amazing demos that go nowhere while we figure out how to build software differently. This will take some time and I imagine the result will be software heavily-structured with a bit of AI reasoning woven throughout, not an army of agents and sub-agents burning infinite tokens.

darkmatriarch - 3 hours ago

I think there are many of us working on projects with LLMs that'll take months more to reach full production. These will feel very out of left field and we'll have another paradigm shift. I think the real momentum will hit when more of us leave the dull products we're working on, start our own companies, and build the products we're actually excited about.

I encourage everyone else to at least build a privacy first version of a product you actually like.

I don't think the centralized internet will survive this change. We can build something much better.

j2kun - 5 hours ago

I get what the author is saying, but his examples like "a ripgrep fork that ... is faster for my codex ripgrep workloads" don't strike me as particularly ambitious.

Perhaps we should be more ambitious in the types of problems we try to solve, and the types of value we try to provide with the software we build.

mgaunard - 18 minutes ago

So by "more ambitious", people really mean "waste more tokens"?

mindcandy - 9 hours ago

Agreed.

I've been seeing too much "I've been coding for decades and what I've always done has be reduced to telling AI to do it for me."

and not nearly enough "I've been coding for decades and recently worked hard for months with AI's help to make something I would have never considered possible before."

Much easier to complain that you are bored than to step back up to high-effort with your new fancy tools.