alt Hacker NewsWe should be more ambitious with the software we build
Comments
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
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
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!
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.
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.
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
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
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.
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.
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.
Surely I'm not alone in finding it disturbing how little regard people seem to have for the use of energy.
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.
You gotta edit your posts!
> But I know Malis well enough to trust his work without looking into it
> If I didn't know Malis, I would make the same assumption, because who has the time to look into all of these projects? Because I know Malis, I didn't bother to look at it; I just trusted him
First and third paragraphs are highly redundant (surrounding ideas are the same too).
It's not nice to read something that appears like the author never read it.
I don't want to hear that from someone who has no ambition to make the site look readable enough to even care.
wtf is up with the site.
Software is already too ambitious. It's beyond our ability to write correctly, reason about or manage securely. When we can get to a point where we don't have a level 10 CVE every other week or millions of people's private information leaked constantly, maybe we can talk about getting more ambitious.
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?
"[..] the last time I taked to him about pgrust verification, he mentioned using Kani to verify some parts of the code. He's since switched to Lean and has been using Lean to verify things that are too complex to do in Kani. This would be another topic for another post,"
I'd love to read that post!
I understand how to use Kani. I suppose Rust with Lean involves Aeneas, but this is over my head. I'd love someone to write this up, not only the mechanics but also exploring the current practical limits of it.
Should be more ambitious with the websites we build to host blogs... geez
I made a new spreadsheet https://omasheet.org based on a wish list of the things I wanted:
- ease of use
- markdown friendly
- strongly typed
- exact maths
- columnar data (Apache Arrow)
- fast queries (Polars)
- code oriented
- AI driven
Happy 41st birthday Excel
So by "more ambitious", people really mean "waste more tokens"?
> I find it understandable that, every time I see pgrust discussed on a news aggregator, most people dismiss it as vibeslop garbage because almost all of these rewrite projects are slop. If I didn't know Malis, I would make the same assumption, because who has the time to look into all of these projects? Because I know Malis, I didn't bother to look at it; I just trusted him
Perhaps a poor choice, given just yesterday pgrust was removed from ClickBench for cheating the benchmark in three different ways (hand-rolled code specifically targeting each of the benchmark queries, caching, and being unable to execute queries outside of the ones tested by the benchmark).
---
Edit: I see Luu actually acknowledged this, buried in the footnotes, but it feels kinda hand-wavy. It mostly reads as "I know he would never cheat, he's better than that!", which is not very convincing to other people. The article insinuates people only think it was cheating because they don't know better, but I've looked into the details. I've seen his explanation. I don't find it convincing, at all. Cheaters denying they cheat is a matter of course. Granted, I don't think it was actually intentional or malicious; it's just what happens when you go maximum vibeslop, because LLMs are themselves reward-trained into cheating benchmarks. In the same breath of saying you trust him as a founder because he doesn't make outrageous claims about his product, you acknowledge he "prematurely" sent in a preview that had no purpose to be sent in as-was for anything other than generating hype. What does it say for your allegedly rigorous Lean-verified testing if you're sending in a database to a benchmark while it is incapable of being actually used as a database?
I find posts like this interesting because it seems to show the true bottleneck which is good ideas. Faster regex is cool but is it ambitious?
We can rewrite existing libraries and software all we want, but the true test is if we can create something new.
The thing I learned about myself with AI is that now I have time to work on every idea that pops into my head —- my ideas aren’t that great.
Make a synthesizer that can accurately recreate all orcastra instruments convincingly. People will pay hundreds of dollars for it--maybe thousands.
Make a reliable and robust geometry kernel. People will pay thousands--or maybe millions for it.
I redid Dan's zstd rust rewrite benchmark for Anthropic models and was shocked to find haiku 5.5 can do it. The latest models are nuts.
AI has made me way more ambitious. I'm building reai.no, an accounting system, POS system, e-commerce system, WMS, OMS, email marketing and much more in one app. It has replaced over 10 systems/apps for some customers.
Only for Norwegian businesses as the accounting is core.
I think these kind of applications that replaces 10 different systems will be much more important than the "we vibecoded an internal tool that does exactly what we need"
As we've been saying: because you can do so much more with software now, and there is no moat, the top 5% of software will compete amongst itself on UX + raw quality. If Ant/OAI can copy your product in <1 week, then you need to constantly stay innovating, listening to customers, and really really pushing the bar on quality to keep your market share.
There is so much software to still be built!
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)
Speaking only for myself, I have found that using an LLM has allowed me to add significant utility to the apps that I ship.
I am not thrilled with all the coding decisions that it makes. I would definitely do stuff differently, but I have learned not to pop the hood and mess with the engine, myself. If I really don't like something, I ask the LLM to change it.
It's worked for me, but YMMV. I'm just one guy, shipping relatively small apps.
It’s never been better to hill climb on problems especially deep systems problems. If you have the expertise and desire to carefully design goals, identify salient metrics, and recursively improve with rigor, modern AI can provide a massively powerful toolkit.
I think we should focus on writing the existing software better before being more ambitious. The absolute wave of "ai slop" is from people who are "more ambitious" now. Why do we want more of that?
I'm being more ambitious in that I'm working on projects that I had sidelined for literal decades because I didn't have time for them. But I'm writing the same things, just faster. And probably better, rather than just what I'd have done before.
And I'm being slightly more ambitious in that I'm using languages I haven't used before, like Rust.
But when I hear that a non-programmer wrote a new ai-assisted (vibe or not) thing, I walk away and wait for the it to mature, be surpassed, or find out it's an absolute shitshow. An unsurprising number of them were shitshows and it came out fairly quickly after I decided to wait and see.
So the article starts with a quote from the pgrust guy from the cheating debacle https://news.ycombinator.com/item?id=50205816
> Funnily enough, for coding, on many tasks, if you actually use one of their SOTA models and compare it to what you get from Anthropic, the actual speedup isn't all that large because of time spent on things like compiling Rust.
That's why I bet that fast compilers are the future. See this other thread that reached the front page a few hours ago about the Roc language [1]
I’ve been coming around to the same conclusion. We are really just scratching the surface of what we can do with these new tool1. The windmill I have been tilting at is creating a c++ compiler[1] and the most recent version is able to compile about 7x faster than gcc[2]. I don’t know that this is super-useful because people aren’t writing much in c++ these days, but as the article mentions, faster rust compilation would accelerate agentic coding considerably. I’ve just started tackling rust and I don’t have a confirmed result yet but early testing makes me think I can find a 4x+ speed up here.
[1]: https://github.com/vishvananda/cppgm-extended
[2]: caveats here include only c++11, only x86, and potential for bugs, but 7x is pretty darn significant even with caveats
Tangential thought when reading the code formatting bit in the examples appendix: Inject a comment with fmt-start-{unique-token} and a corresponding -end-, and you could get away with a much simpler parser and hopefully far fewer edge cases, assuming it doesn't influence the lines in between. It's a bit roundabout, but the pressure of 'figuring out AST position the direct way'd be too fiddly to do by hand' inspires 'so make an easy-to-spot landmark that'll remain in place' when you can't delegate all the details to an AI model.
I feel like I make this point a lot at work. We are not running out of problems. Let’s move the goalposts.
I took this advice to the heart.
- Lovable alternative, but x6 cheaper https://peachjam.dev
I'm building a fan site for a Japanese baseball team on my own. Besides news and videos, it pulls player stats from more than ten sites, from the league's official site to Wikipedia. Writing that many scrapers by hand would have been impossible for me, so I wouldn't have even tried without Claude Code.
Chitown26.com
My website is a from scratch arcade room + added some roms to it
It’s sad the amount of times I’ve heard super talented programmers say “ofcourse we’re not gonna build another X” then proceed writing a wrapper around X and pretend that’s a product.
I think we should be more ambitious with the font size we use…
The best way to improve your solutions is to study ever worse problems.
I think getting a good reputation for being able to build real, ambitious software with AI will be a really important thing going forward.
Not trying to be mean, but first of all, we should be more ambitious using CSS.
I really liked this talk about how the premise of "software is eating the world" is incorrect. I think AI coding tools proves the point that software part is easy, its the hardware that is the important part. We can't really be more ambitious with software when ultimate pure software is limited in what is possible.
Bryan Cantrill: Andreessen’s Folly - The False Dichotomy of Software and Hardware https://www.youtube.com/watch?v=v0JjG0Qfwi8
If only you invested a tiny fraction of the effort it took to write this to make it easier for us to read. It's a serious discourtesy.
```
.reading-container {
/\* Automatically caps the container at 65 characters on desktop,
but scales to 100% minus a 2rem padding buffer on mobile devices \*/
width: min(65ch, 100% - 2rem);
margin-inline: auto;
amazing
You know what would be really ambitious? Software that exists in a stable form without breaking for more than 15 years. Truly ambitious would be a stable, non-changing common linux base (like how Nintendo NES emulation target is stable) of packages that just gets supported for decades.
Perhaps that's too ambitious. But it would be of incredible utility not having to re-make the same things over and over in pepertuity with ever more abstraction layers. So much work on computer is just the constant churn and future shock of libraries adding new features which require updates which break other things. I'm tired of building castles on sand.
Behind the link "slow software that the creator is claiming is fast" is the following text:
"funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved)"
This aged like milk. pgrust was caught cheating on all benchmarks this week.
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.