We should be more ambitious with the software we build
ltratt
300 points
259 comments
October 24, 2026
Related Discussions
Found 5 related stories in 225.0ms across 10,486 title embeddings via pgvector HNSW
- How to be more ambitious: A tutorial for humans with models pretext · 24 pts · October 15, 2026 · 58% similar
- What I believe about the future of software development misternugget · 11 pts · September 21, 2026 · 55% similar
- The Ambition Project herbertl · 56 pts · August 09, 2026 · 54% similar
- Dear Software Makers speckx · 89 pts · September 30, 2026 · 53% similar
- When anyone can build software, who decides what not to build? younss · 44 pts · September 13, 2026 · 53% similar
Discussion Highlights (20 comments)
lukeify
Agreed. Perhaps we could start with some line length and text wrapping restrictions so we can be respectful of other people reading. Or even just a nicer font, maybe?
mindcandy
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.
Supermancho
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
tlarkworthy
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. https://taktile.com/blog/property-based-testing-claude
weinzierl
"[..] 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.
anonymous908213
> 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?
lijok
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.
nektro
body { max-width: 70rem; }
Lerc
>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. I understand being predisposed to expect a poor quality half arsed effort for projects like this. I don't really have a problem with that. There is a lot of crap out there. What I find rather offensive is when people declare something to be poor quality and half arsed before they have taken a good look at it. It's one thing to think something is probably crap so I'm not going to bother even looking. It is something completely different when you think something is probably crap so you tell people that it is crap without checking.
theturtletalks
I'm building an open-source Shopify for every vertical and built a software factory to do it. I envisioned this before LLMs, but LLMs are finally making it possible!
wccrawford
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.
__s
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
ChaseRensberger
I feel like I make this point a lot at work. We are not running out of problems. Let’s move the goalposts.
lubujackson
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.
2001zhaozhao
I think getting a good reputation for being able to build real, ambitious software with AI will be a really important thing going forward.
ChrisMarshallNY
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.
vishvananda
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
RomanPushkin
Not trying to be mean, but first of all, we should be more ambitious using CSS.
SoftTalker
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.
Buttons840
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.