Outside of the PQ algorithms not being as thoroughly vetted as others, is there any negatives to shifting algorithms? Like even if someone were to prove that quantum computing is a dud, is there any reason why we shouldn't be using this stuff anyway?
they are much more thoroughly vetted than other schemes. They're more thoroughly vetted than elliptic curves were before we deployed them. Much more vetted than RSA was ever.
Practically though, there are some downsides. Elliptic curves tend to have smaller ciphertexts/keys/signatures/so are better on bandwidth. If you do everything right with elliptic curves, we're also more confident in the hardness of the underlying problems (cf "generic group lower bounds", and other extensions of this model).
The new algorithms tend to be easier to implement (important, as a big source of practical insecurity is implementation issues. historically much more than the underlying assumption breaking). This isn't uniformly, e.g. I still think that the FN-DSA algorithm will have issues of this type, but ML-DSA and ML-KEM are fine. They're also easier to "specify", meaning it is much harder to accidentally choose a "weak" instance of them (in several senses. the "weak curve" attacks are not really possible. there isn't really a way to hide a NOBUS backdoor like there was for DUAL_EC_DRBG). They also tend to be faster.
Post-quantum algorithms tend to be slower than existing elliptic curve algorithms and require more data to be exchanged to provide equivalent security against attacks run on non-quantum computers.
This page lists some figures for ML-KEM-768 (which is the PQ key exchange algorithm that's most widely deployed today): https://blog.cloudflare.com/pq-2025/#ml-kem-versus-x25519 This one is actually faster than X25519 (a highly optimized ECC algorithm) by about double but requires 1,184 bytes of data to be exchanged per keyshare vs 32 for X25519. In practice everyone today is using a hybrid algorithm (where you do both ECC and PQ in case the PQ algorithm has an undiscovered weakness) so an ECC+PQ key exchange will be strictly slower than an ECC-only key exchange.
This page lists some numbers for different PQ signature algorithms: https://blog.cloudflare.com/another-look-at-pq-signatures/#t... Right now the NIST has selected three different ones (ML-DSA, SLH-DSA, and Falcon a.k.a. FN-DSA) which each have different trade-offs.
SLH-DSA is slow and requires a large amount of data for signatures, however it's considered the most secure of the algorithms (since it's based on the well-understood security properties of symmetric hash algorithms) so it was selected primarily as a "backup" in case the other two algorithms are both broken (which may be possible as they're both based on the same mathematical structure).
ML-DSA and Falcon are both fairly fast (within an order of magnitude of Ed25519, the X25519 curve signature algorithm), but both require significantly larger keys (41x/28x) and signatures (38x/10x) compared to Ed25519. Falcon has the additional constraint that achieving the listed performance in that table requires a hardware FPU that implements IEEE-754 with constant-time double-precision math. CPUs that do not have such an FPU will need to fall back to software emulation of the required floating point math (most phone, desktop, and server CPUs have such an FPU but many embedded CPUs and microcontrollers do not).
The net result is that TLS handshakes with PQ signatures and key exchange may balloon to high single- or double-digit kilobytes in size, which will be especially impactful for users on marginal connections (and may break some "middle boxes" https://blog.cloudflare.com/nist-post-quantum-surprise/#dili...).
I wasn't too upset with Bram's article, but I do think people should be citing specific claims, even in blog posts.
If you make an assertion in a blog post, I have no idea if you got the information from a respected scientific journal, or Reddit, or InfoWars, or the writing of a bathroom stall. It's hard to know if the assertion is grounded in reality or just something you made up.
The response I get to this is universally "LOL just look it up yourself man!", but that feels like a cop out. When I write blog posts, I put inline links all over the place to try and justify my assertions to show where I'm getting this information. If I sourced some bad information from a bad source, it's clear to know where I got it from and you can either notify me or disregard the assertion.
This is a FreeType issue - it uses auto-hinter by default on Linux and doesn't run the TT bytecode. No fix from CSS side unfortunately. Works on Windows/macOS where DirectWrite/CoreText run the bytecode
Back in 2015 I worked for a startup. I turned down a job at a more stable company because this startup had me doing Erlang and I really wanted to work with that.
The job worked fine for about six months, and then one week my paycheck (which usually was on the second and fourth Wednesday of the month) wasn't in my bank account. I go the CEO of the company and mention this and he said something like "Oh yeah, something got fucked up with payroll man, don't worry we'll give you a double paycheck next time, with interest man".
I was young enough in my career to just accept that, and so I waited two more weeks and again, no money in my checking account. I confront the CEO about this, and he says the payroll stuff is still fucked but don't worry man I got you, next paycheck will be a triple paycheck, and an extra two grand for everyone.
Two weeks later, the building's doors are locked, and none of us are able to get into the building. One of the other engineers called one of the investors and apparently the CEO "could not be found", and all of us were laid off on the spot.
This began one of the worst times in my life. I was already not the best at managing money, and because I had naively believed him about eventually getting all my backpay I hadn't been saving especially. I hadn't been conservative with my money, and I had gone a month and a half without a paycheck, and as such I was completely broke.
This led to a lot of terrible stuff happening; my landlord filed a lawsuit against me for back rent, my wife started having medical issues with her eye and we didn't have any insurance or money so we couldn't get it looked at, and I had to call a friend and beg him to loan me $400 to pay some bills and so I could get groceries. He's a very good friend, and he did help me out and I did eventually pay him back, but it was unbelievably depressing to me.
The part that sticks out to me was when I had to fly to Seattle for an interview with Amazon, and while they would happily reimburse everything for the trip, I realized that I didn't have enough money on my debit card to do the "pre-charge" thing that hotels do, and my credit card was maxed out. I was afraid that I was going to be stuck being homeless in Seattle for two days because of an interview that I knew I would not get, and I felt so bad that I let my life get this way. Fortunately in this case, I was able to call my mom once I got there, lied and said I "lost" my credit card and I was able to get her to call in a credit card to the hotel, so I wasn't homeless, but that didn't occur to me until about five minutes after I arrived at the hotel.
Eventually I was able to get my stepfather-in-law to loan us enough money to get my landlord to drop the lawsuit, and eventually I found the job at Jet.com, which was a great job that paid well and ended up being a huge stepping stone in my career and where I met a ton of ridiculously smart and cool people that I still chat with to this day.
I will never forgive that CEO for that period of my life. While it did end up working out, I still occasionally have nightmares about that time in my life, and how upset I was, and how I wouldn't wish that feeling of worthlessness on my worst enemy. In some senses I'm kind of grateful for the experience because it did really force me to grow up and learn how to take care of myself, but ultimately I still wish it hadn't happened.
This wasn't YC, but it was still a VC-funded megalomaniacal CEO, which is why this reminded me of it.
During my MBA we were taught about the FedEx founding story [0].
The founder of FedEx got low on cash. So he took all the remaining cash (including what he owed in payroll) to Vegas and gambled it. And won, and paid his staff, and the rest is history.
We were taught that this was a great example of "entrepreneurial hustle". I was horrified.
How many founders copied this lesson? How many employees couldn't pay their mortgages because the CEO had learned the wrong lesson from this story?
This kind of nightmare irresponsibility needs to be punished, not glorified.
[0] https://en.wikipedia.org/wiki/FedEx_Express: "However, the company began to experience financial difficulties, losing up to a million USD a month. While waiting for a flight home to Memphis from Chicago after being turned down for capital by General Dynamics, Smith impulsively hopped on a flight to Las Vegas, where he won $27,000 playing blackjack. The winnings enabled the cash-strapped company to meet payroll the following Monday. "
It's actually unbelievable that this would be taught as anything but a cautionary tale of survivorship bias.
The FedEx founder got lucky. The countless others who tried a similar gamble didn't and unfortunately their story doesn't seem to be taught because "desperate founder gambled the employees salary and lost" just doesn't have the same ring.
I've heard that story, though I always kind of thought it sounded like bullshit. Obviously I have no way to prove that, I guess I'm just usually skeptical of gamblers bragging about their big winnings.
But yeah, even if it is true, then it's hardly a good lesson. "CEO took all remaining money to Vegas" isn't exactly something to idolize.
Why was your mom your last resort? And why did you lie to her?
Is this that American thing, where kids move to a different city at 18 and only visit their parents once a year for Thanksgiving?
I'm in pretty much daily contact with my parents and siblings. They always know what I'm up to, what my financial situation is, and they would be my first contact in case of any difficulties.
> and then one week my paycheck (which usually was on the second and fourth Wednesday of the month) wasn't in my bank account. I go the CEO of the company and mention this and he said something like "Oh yeah, something got fucked up with payroll man, don't worry we'll give you a double paycheck next time, with interest man".
> I was young enough in my career to just accept that
This reminded me of two much smaller-scale events from my personal life:
1. I engaged a Chinese tutor. After several weeks of lessons, one day I found that I had forgotten to bring my wallet to the lesson and couldn't pay her. I considered this a huge faux pas, but she treated it as a non-event, brushing it off with "no problem, just pay me next time". (Which I did. The inability to pay that week was just an accident on my part.)
2. Living in China, I arranged for someone I knew through a board game club to help me order an air purifier online. She would buy and receive the air purifier and then hand it over to me.
She notified me that she had received the air purifier and I went out to pick it up from her. We had a short conversation and I took it away. As I was riding home, I got a message from her: "It seems we both forgot the money."
So I offered that I could either come back right away to hand over the money, or give it to her the next time I saw her (presumably at a meeting of the club). She wanted me to come back right away.
I did, because obviously I have the obligation to pay for my thing. But in that case I was slightly hurt by the implied lack of trust.
---
The incident with the tutor occurred in a context where I had already built up some payment-related trust, so I can understand why things happened that way.
Maybe she just needed the money. Paying later always has the risk that it will never going to happen. And she helped you, did she get anything in return?
Yeah, an issue with startups, especially extremely small startups, is that you often become very close with everyone. This isn't inherently a bad thing, it's good to like your coworkers, and when the startup does well it's kind of fun to trade "war stories" after the fact.
The problem is that if/when the startup goes bust, it is a double whammy; not only do you lose your job, you feel betrayed by someone who has become a close friend.
I liked this CEO, he was a really nice guy (until he apparently ran away with money), and since he had become (what I thought was) a friend, I felt inclined to believe him when he deflected my questions about the paycheck. Obviously I was wrong to trust him, but I was in my early twenties and hadn't become the cynical old man that I am now (and that I am actively trying to fight against now).
I used to blame myself for being so naive and believing him, but I don't anymore; being trusting and assuming the best of people isn't a disability. The guy lied to me, he's at fault, I'm not at fault for trusting someone that I thought was a friend.
Just happened with my dad, with one of his rental tenants. One of them lost his job (didn't get the job after the probation period), so he had booked a flight back home. Except because of the war in the Middle East, the flights were delayed constantly so he couldn't go back - and given that his flight was on a budget airline, it would take ages until normal operations resume (they still haven't resumed). The guy kept telling my father that he would pay once his ticket was booked, up until the very last minute when he revealed that he was broke and could not pay, burnt bridges and all. He incurred a significant expense after booking a flight with a non-discount carrier airline.
The irony was that had he revealed that he was broke from the start, my father wouldn't have minded as much about the rent (he has forgiven rent in such cases in far too many situations), but would have also helped him get the ticket for cheap.
No argument that I was extremely fortunate to have the people I was able to reach out to and get help from. My friend, my mom (though she didn't actually spend any money in this case, just called in a credit card for the hotel prebill), and my stepfather-in-law made what would have been an extremely terrible situation to just a very terrible situation.
I'm sorry you don't feel like you get the help you need, though I think just based on this comment you would benefit from talking to a therapist. This isn't a dig, I see a therapist.
Therapy is much more than just bitching about your problems, and I'm afraid that if you think that whining on Hacker News is going to do anything to help you, then you're either deluded or stupid.
I also don't know what "you types" means? My parents were super against therapy and wouldn't let me go to a therapist or psychiatrist. I sought it out when I was 26 years old.
I think what's sad is to find a long post about being ripped off by a startup and then using it extremely tangentially as an excuse to try and tell everyone to feel bad for you. "Woe is me, I would try to do something to improve my life but alas all I can muster is typing on a keyboard to a bunch of uncaring strangers on an internet forum full of software engineers."
I don't really know what I should be "aware" of; I stand by that you should consider seeing a therapist, because clearly you are dealing with some stuff that is far beyond the scope of what you're going to get on Hacker news.
I probably am mentally deprived in some way, but at least I'm self aware enough to actually try and improve my life instead of, you know, bitching about how the world is rigged against me.
Also, I find it telling and cowardly that you keep making throwaway accounts instead of owning your opinions. I can't say that I think you really stand by your convictions.
Gotta admit that I do like the name "tomtard", I might steal that.
Yes, I'm the idiot in this conversation. Clearly the pinnacle of intelligence is someone going on Hacker News and interjecting a weird thing about how no one cares about them and how the world is rigged against them.
The problem is that I'm so stupid that I didn't realize the immense genius of such a maneuver, and as such the shear magnitude and girth of your intelligence went over my tiny head. Some day I hope to have even 1% of your giant brain and maybe then I will have the intelligence to bitch to strangers about how the world hates me and that therapy is stupid, but alas I fear I am not ready for that yet.
Oh by the way, it's still cowardly to keep making throwaway accounts because you're too much of a wuss to actually own what you say.
I didn't go to an Ivy League school. I was a college dropout (dropping out from a perfectly-fine-but-not-remarkable state school) for the first decade of my career, and my degree now is from WGU, hardly some elite fancy school.
I assure you I can wipe my own ass without my mom's help, and I haven't needed any financial help since that episode where I asked her to call in a credit card so they could do the pre-bill at the hotel, which again didn't actually cost any money.
You are really stretching this because you really want to be a victim and you really want to paint me into some yuppie trust fund kid, when that simply isn't the case. Sorry, life is more complicated than stereotypes you saw on television as a child.
Everyone knows it's rigged, but the amazing part from your comments is that it's rigged specifically against you. You said as much in your first reply. That's amazing. You're a very special person, the entire world has conspired to specifically make your life bad.
I may be an idiot, but at least I'm not a coward like yourself.
> systemic financial inequality doesn't exist, people just like being victims
Ok well then I hope your house is burned down in riots and then your family are killed before your eyes, and then I'll just say you want to be a victim since that's the natural response to attitudes like yours
Literally won't even care when it happens, because I'll remember how you thought about it
I didn't say that systemic equality didn't exist. Of course it does, you can feel free to go through my post history if you want to see where I've argued that very point in the past. There's a million reasons why there exists inequality, like race, religion, ethnicity, and of course poverty. Obviously things should be done to help with that.
You said, and this is a quote, "don’t know anyone else in the world except for me who doesn’t have any help" which seems to suggest that you are being singled out.
I have no idea about your life and frankly I don't really care. You derailed something in order to complain about how the world hates you, and bizarrely tried to make me feel bad for being able to call my mother to call in a credit number for a hotel pre-bill, and it sure seems like you're trying to make yourself seem like a victim.
If you had your house burned down in a riot and had your family killed before your eyes, then I think you should see a therapist instead of fishing for...whatever the hell it is you're fishing for on Hacker News.
I have a smartwatch, I like it just fine, but I kind of think that smartwatches are actually pretty bad at being a watch. I had a Casio G-Shock for about a decade that I wore nearly every day [1], and I never had to change the battery. My Garmin Instinct Crossover, which is considered to have very good battery life, has to be charged every two weeks, which despite that seeming like a long time, I manage to forget about it every time until the battery is dead.
[1] I have a few fancy wind-up watches I wear to formal occasions.
Yeah, I mean, the Instinct Crossover has been my favorite smartwatch that I've used, and two weeks is a decent lifespan for these things, but I do kind of miss never having to worry about charging it.
I'm pretty sure that will be true with AI as well.
No accounting for taste, but part of makes code hard for me to reason about is when it has lots of combinatorial complexity, where the amount of states that can happen makes it difficult to know all the possible good and bad states that your program can be in. Combinatorial complexity is something that objectively can be expensive for any form of computer, be it a human brain or silicon. If the code is written in such a way that the number of correct and incorrect states are impossible to know, then the problem becomes undecidable.
I do think there is code that is "objectively" difficult to work with.
There are a number of things that make code hard to reason about for humans, and combinatorial complexity is just one of them. Another one is, say, size of working memory, or having to navigate across a large number of files to understand a piece of logic. These two examples are not necessarily expensive for computers.
I don't entirely disagree that there is code that's objectively difficult to work with, but I suspect that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has much less overlap than you're suggesting.
Certainly with current models I have found that the Venn diagram of "code that's hard for humans" and "code that's hard for computers" has actually been remarkably similar, I suspect because it's trained on a lot of terrible code on Github.
I'm sure that these models will get better, and I agree that the overlap will be lower at that point, but I still think what I said will be true.
I wouldn't expect so. These machines have been trained on natural language, after all. They see the world through an anthropomorphic lens. IME & from what I've heard, they struggle with inexpressive code in much the same way humans do.
What do you think about the argument that we are entering a world where code is so cheap to write, you can throw the old one away and build a new one after you've validated the business model, found a niche, whatever?
I mean, it seems like that has always been true to an extent, but now it may be even more true? Once you know you're sitting on a lode of gold, it's a lot easier to know how much to invest in the mine.
It hasn't always been true, it started with rapid development tools in the late 90's I believe.
And some people thought they were building "disposable" code, only to see their hacks being used for decades. I'm thinking about VB but also behemoth Excel files.
I guess the question is, are the issues not worth fixing because implementing a fix is extremely expensive, or because the improvements from fixing it were anticipated to be minor? I assume the answer is generally a mix of the two.
Someone has to figure out how to make the experiences of the two generations consistent in the ways it needs to be and differ only in the ways it doesn't still.
The tl;dr of this is that I don't think that the code itself is what needs to be preserved, the prompt and chat is the actual important and useful thing here. At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store that in Git.
> At some point I think it makes more sense to fine tune the prompts to get increasingly more specific and just regenerate the the code based on that spec, and store that in Git.
Generating code using a non-deterministic code generator is a bold strategy. Just gotta hope that your next pull of the code slot machine doesn’t introduce a bug or ten.
We're already merging code that has generated bugs from the slot machine. People aren't actually reading through 10,000 line pull requests most of the time, and people aren't really reviewing every line of code.
Given that, we should instead tune the prompts well enough to not leave things to chance. Write automated tests to make sure that inputs and outputs are ok, write your specs so specifically that there's no room for ambiguity. Test these things multiple times locally to make sure you're getting consistent results.
> Write automated tests to make sure that inputs and outputs are ok
Write them by hand or generate them and check them in? You can’t escape the non-determinism inherent in LLMs. Eventually something has to be locked in place, be it the application code or the test code. So you can’t just have the LLM generate tests from a spec dynamically either.
> write your specs so specifically that there's no room for ambiguity
Using English prose, well known for its lack of ambiguity. Even extremely detailed RFCs have historically left lots of room for debate about meaning and intention. That’s the problem with not using actual code to “encode” how the system functions.
I get where you’re coming from but I think it’s a flawed idea. Less flawed than checking in vibe-coded feature changes, but still flawed.
> Write them by hand or generate them and check them in?
Yes, written by hand. I think that ultimately you should know what valid inputs and outputs are and as such the tests should be written by a human in accordance with the spec.
> Less flawed than checking in vibe-coded feature changes, but still flawed.
This is what I'm trying to get at. I agree it's not perfect, but I'm arguing it's less evil than what is currently happening.
Observability into how a foundation model generated product arrived to that state is significantly more important than the underlying codebase, as it's the prompt context that is the architecture.
Yeah, I'm just a little tired of seeing these pull requests of multi-thousand-line pull requests where no one has actually looked at the code.
The solution people are coming up with now is using AI for code reviews and I have to ask "why involve Git at all then?". If AI is writing the code, testing the code, reviewing the code, and merging the code, then it seems to me that we can just remove these steps and simply PR the prompts themselves.
You don't actually need source control to be able to roll back to any particular version that was in use. A series of tarballs will let you do that.
The entire purpose of source control is to let you reason about change sets to help you make decisions about the direction that development (including bug fixes) will take.
If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners, or are they still using it because they don't want to admit to themselves that they've completely lost control?
> are they still using it because they don't want to admit to themselves that they've completely lost control?
I think this is the case, or at least close.
I think a lot of people are still convincing themselves that they are the ones "writing" it because they're the ones putting their names on the pull request.
It reminds me of a lot of early Java, where it would make you feel like you were being very productive because everything that would take you eight lines in any other language would take thirty lines across three files to do in Java. Even though you didn't really "do" anything (and indeed Netbeans or IntelliJ or Eclipse was likely generating a lot of that bootstrapping code anyway), people would act like they were doing a lot of work because of a high number of lines of code.
Java is considerably less terrible now, to a point where I actually sort of begrudgingly like writing it, but early Java (IMO before Java 21 and especially before 11) was very bad about unnecessary verbosity.
> If people are still using git but not really using it, are they doing so simply to take advantage of free resources such as github and test runners,
does it have to be free to be useful? the CD part is is even more important than before, and if they still use git as their input, and everyone including the LLM is already familiar with git, whats the need to get rid of it?
there's value in git as a tool everyone knows the basics of, and as a common interface of communicating code to different systems.
passing tarballs around requires defining a bunch of new interfaces for those tarballs which adds a cost to every integration that you'd otherwise get for about free if you used git
A series of tarballs is really unwieldy for that though. Even if you don't want to use git, and even if the LLM is doing everything, having discrete pieces like "added GitHub oauth to login" and "added profile picture to account page" as different commits is still valuable for when you have to ask the LLM "hey about the profile picture on the account page".
Also, the approach you described is what a number of AI for Code Review products are using under-the-hood, but human-in-the-loop is still recognized as critical.
It's the same way how written design docs and comments are significantly more valuable than uncommented and undocumented source.
I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked. I've worked at BigCos and startups, and a lot of the terrible code that makes it to production was shocking when I first started.
This isn't a dig at anyone, I've certainly shipped my share of bad code as well. Deadlines, despite my wishes sometimes, continue to exist. Sometimes you have to ship a hack to make a customer or manager happy, and then replacing those hacks with better code just never happens.
For that matter, the first draft of nearly anything I write is usually not great. I might just be stupid, but I doubt I'm unique; when I've written nice, beautiful, optimized code, it's usually a second or third draft, because ultimately I don't think I fully understand the problem and the assumptions I am allowed to make until I've finished the first draft. Usually for my personal projects, my first dozen or so commits will be pretty messy, and then I'll have cleanup branches that I merge to make the code less terrible.
This isn't inherently bad, but a lot of the time I am simply not given time to do a second or third draft of the code, because, again, deadlines, so my initial "just get it working" draft is what ships into production. I don't love it, and I kind of dread of some of the code with my name attached to it at BigCo ever gets leaked, but that's just how it is in the corporate world sometimes.
To my believe there was not a goal to write good code. The goal was maintainability and to keep it simple, so that people understand. People come and go, you constantly get to see foreign code and you have to do something with it.
Anyways, i see the maintainability hell coming onto us. I still wonder how i organize this with AI. I definitly do not want to touch it what is written by AI.
I think the industry-wide hope is that AI manages the AI-written code, but it’s unclear whether that’s actually going to work out in practice. Right now, my experience is that is dicey. I’ve had AI mess up a codebase to the point where I threw it away and restarted. Maybe I was doing it wrong, though, in that I was looking at the code and was increasingly horrified by the slop. I get the feeling that in this new world, we’re supposed to ignore how the sausage is made and just focus on the final outcome.
IME AI-native engineering requires a lot of infrastructure to make it viable. Teams who are just opening up cursor and putting it on "auto" and trying to one shot features may get stuff that works but is indeed slop.
Since the beginning of the year, I've been spearheading a low-stakes AI-native project (an internal tool). No one's written a single line of code. And we've learned so much from this experience. The first rule was our product manager, who is technical but isn't typically in the weeds, needs to be able to one-shot prompts with cursor auto. And so many rules stem from there, from e2e tests to ensure he doesn't break stuff, to custom linters to ensure that code lives in the right place, to architectural spec sheets so the LLM doesn't try to do raw DB queries from the client.
We're still not there, but we're getting closer and learning and improving every day.
I think the folks who are vibe coding a lot either aren't working in a team, or they are omitting the fact that they have spent a long time building harnesses to ensure the LLM doesn't run amok.
And I think the people who hate vibe coding are likely just asking Claude Code to do X without using Skills that have opinionated ways to do X.
All that said, I don't think we should ignore how the sausage is made at all. Part of what makes me able to move quickly in this project is knowing where stuff lives. I may not understand the line-by-line code, but if I know where to look to find out why I'm missing data that's in the DB, I can move a lot faster than if I have no idea what's going on in the codebase. Then when I find the problematic file or function, I can ask the LLM why it's like X and tell it it should be like Y.
Cool. Are you restricting the AI to be very focused on a function or an architectural blocks that is envisioned, or are you giving it more freedom? I seem to have less slop when I really constrain things, but that takes a lot of work (e.g., specs) and dialogue with the AI (“focus on X, now let’s design block Y,” etc.).
I give it freedom but with the predefined restrictions. I use a plug-in called Obra Superpowers. Whenever I want to start on a block of work, whether it's a ticket or if I just want to tackle tech debt, I start with the brainstorm command. I say something vague like "implement X" or "last time i tried to vibe code Y, Z happened. I don't want that to happen again. Let's improve the harness."
It'll ask follow questions, which I answer, then generate specs that I manually review. If it looks good, it'll generate a plan. If not then I'll give it feedback.
When the scope of work is well-defined (ie my boss says users should be able to do Y) then this process is fairly seamless.
When it's not well-defined then it does take a bit longer and more dialogue as you said. But because everything is documented and written down, we have a pretty good feedback loop (boss asks why it works like X, I can look at the generated spec/plan, or ask the AI to, to understand why).
Ok, so it’s constrained by specs, but you dialog with the AI and have it create the specs. I should try that. I’ve been creating my own specs and having it work from those and then iterating, but that’s not exactly quick and I find myself thinking, “At this rate I could do it faster myself.”
Yeah definitely agreed. I'm lucky I'm that my boss is willing to invest in this little experiment so the point isn't "can we do this faster manually" it's "how can we build our AI infrastructure such that it can actually be faster."
And also, I'm taking care of my infant daughter while working so my workflow is often "launch an AI agent from my computer while she's asleep, review plan on my phone while feeding or napping the little one, approve it and execute it" so it's often running when I'm not really in a mental space to be thinking deeply.
Yep this is especially true in the pre-product-market-fit phase. Most if not all of that code should be written to be thrown away. Any time you spend writing perfect code instead of your MVP is burnt runway and a chance for competitors to catch up.
Once you show PMF though the balance changes to long-term sustainability and maintainability.
What's going to be interesting is getting to a place where it generates better code than we would from specs. You can get better and better generated code by filling in the context the model infers. Do that long enough, and well, a perfect spec is just code.
To me, it instead sounds like you care about the code you produce. You judge it more harshly than you probably do other code. It sounds like you are also meeting deadlines, so I'd call that a success and more production than what a lot of people tend to put out into the world.
I often have a lot of time between projects, and am able to really think about things, and write the code that I'm happy with. Even when I do that, I do some more research, or work on another project, and immediately I'm picking apart sections of my code that I really took the time to "get right." Sometimes it can be worse if you are given vast amounts of time to build your solution, where some form of deadline may have pushed you to make decisions you were able to put off. At least that's my perspective on it, I feel like if you love writing software, you are going to keep improving nearly constantly, and look back at what you've done and be able to pick it apart.
To keep myself from getting too distressed over looking at past code now, I tend to look at the overall architecture and success of the project (in regards to the performing what it was supposed to, not necessarily monetarily). If I see a piece of code that I feel could have been written far better, I look at how it fits into the rest. I tend to work on very small teams, so I'm often making architecture decisions that touch large areas of the code, so this may just be from my perspective of not working on a large team. I still do think if you care about your craft, you will be harsh on yourself, more than you deserve.
This is the product that's claiming "coding is a solved problem" though.
I get a junior developer or a team of developers with varying levels of experience and a lot of pressure to deliver producing crummy code, but not the very tool that's supposed to be the state-of-the-art coder.
Sure, but as I stated, even "professional" code is pretty bad a lot of the time. If it's able to generate code that's as good as professional code, then maybe it is solved.
I don't actually think it's a solved problem, I'm saying that the fact that it generates terrible code doesn't necessarily mean that it doesn't have parity with humans.
You can get AI to generate the best code you have ever seen. It just takes time and direction. I can write "poetic" code, but it takes orders of magnitude more time. I can also write beautiful code with AI, but it is also time and brain intensive.
It generates terrible code when used in a nearly open loop manner, which all coding agents are currently doing.
I mean, hasn't it learned from reading other's code? I don't think it can be any better than the common patterns and practices that it has been trained on. Some outlier of amazing code is probably not going to make much of a difference, unless I am completely misunderstanding LLMs (which I very well may be, and would gladly take any criticism on my take here).
Yes, but, that’s a low bar, no? I mean, when they first started talking about AI, were you envisioning a mediocre AI that is just average, or were you imagining an expert?
The bet is that it will be trivial for them to invest in cleaning up Claude Code whenever they face real competitive pressure to do so. My best guess is that it's a bad bet - I don't think LLM agents have solved any of the fundamental problems that make it hard to convert janky bad code to polished good code. But Claude Code is capable in my experience of producing clean code when appropriately guided, so it's not that there's no choice but jank. They're intentionally underinvesting in code quality right now for the sake of iteration speed.
Have you tried just asking CC to make a codebase more elegant? It’s surprisingly effective up to a point. No reason to think that won’t work better down the road.
Down the road AI is smarter than all of us. Today (including one time literally today), my experience is that it’s occasionally helpful at cleaning up its own mess but often tries to change behavior in a way that’s unacceptable for a production project.
> crummy code, but not the very tool that's supposed to be the state-of-the-art coder
Why not? It is subject to the same pressures, in fact it is subject to more time pressure than most corp code out there. Also, it's the model that's doing the coding, not the frontend tool.
I thought the sales pitch of all of this is that the AI was supposed to relieve people from having to do a bunch of annoying bootstrap coding and to do it in a way that we could extended easily.
I have a subscription to Claude Code and despite my skepticism, it has been pretty good at just getting a goofy PoC thing going. When I look at the code, it’s usually insane unless the prompt was so narrow and specific like about writing a function that does one thing and only one thing.
Outside of small, personal projects, I am still really uncomfortable at having agents run wild. I see the result, and then I spend a bunch of time having to gain the context of what is going on, especially if I ask it to implement features in spaces I have general knowledge, but not expertise. So, the problem remains the same. These things still need handholding by people who understand the domain, but having people become glorified PR reviewers is not an acceptable path forward.
Arguing that there is lots of bad production code kinda avoids the actual issue that is going on here. Yes, a lot of sloppy code can and has been written by people. I’ve seen it myself, but it feels like the actual thing is that, we are now enabling that at scale and calling it “abundance” when instead we are really generating an abundance of completely avoidable security holes and logic errors.
i once scolded an ai for being too late when i figured out an issue before it could come back with an answer: it made an excuse that it took too long to start up, lol
i would guess telling it to "hurry up" would produce even worse code than already does without hand-holding or maybe it would make an excuse again...
No one cares about code quality. No one has ever cared about code quality. It’s only been tolerated in businesses because no one could objectively say that ignoring code quality can result in high velocity. With coding agents, velocity is now extremely high if you get humans out of the way.
"No one cares about code quality" - disagree. As a dev, I care about code quality in that shitty code makes my life suck.
As a user of terrible products, I only care about code quality in as much as the product is crap (Spotify I'm looking at you), or it takes forever for it to evolve/improve.
Biz people don't care about quality, but they're notoriously short sighted. Whoever nerfed Google's search is angering millions of people as we speak.
"Code quality" here isn't referring to some aesthetic value. Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while. They get to the point where fixing one bug causes another, and then the codebase is in such a state that no human or agent can salvage.
People who say they don't care about the quality of code produced by agents are those who haven't been evolving non-trivial codebases with agents long enough to see just how catastrophically they implode after a while. At that point, everyone cares, and that point always comes with today's agents given enough lines and enough changes.
> Coding agents write code that doesn't converge, meaning code that they cannot evolve after a while
That's not true, and I'm not sure what that even means. It's totally up to you the human to ensure AI code mergable or evolvable, or meet your quality standard in general. I certainly have had to tell Claude to use different approaches for maintainability, and the result is not different than if I do it myself.
Nobody cares about costs until they pay them themselves.
Regarding code quality and tech debt, it's sensible not to care if it doesn't lead to anything observable. Do you really care of some "bad" code somewhere that hasn't changed for 5 years but keeps working fine, and has no new requirements?
On the other hand, if you work on an active codebase where fixing one bug inevitably leads to another, maybe it's worth asking whether the code quality is simply too low to deliver on the product expectations.
It's not even obvious to me in which direction coding agents move the needle. Do you want higher quality, at least at a higher (design) level, when you heavily use agents, so that you know know the mess will at least compartmentalized, and easier to deal with later if needed? Or do you just assume the agent will always do the work and you won't need to dig into the code yourself? So far I've mostly done the former, but I understand that for some projects, the latter can make sense.
And yet, velocity is a terrible metric to go by. It is only interesting in so far that you can spit something out before somebody else.
When agents became a thing I was hoping that we will finally be able to go through all the outstanding bugs, tighten the bolts so to speak. Instead, we produce _more_ stuff.
We have now 100 half-baked versions of everything because everybody can give their own spin on anything.
It really shows that nobody cares about uptime at github or the jankiness of claude.
I wouldnt say that customers are indifferent, but it wouldnt be the first time that investor expectations are prioritized far above customer satisfaction.
> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked.
At a place I worked at with their core product written in Python, it was exceptionally common for engineers to make shell calls for file operations that had easy Python-native functions.
For example, rather than `os.remove("some_file")`, they'd do `os.system("rm some_file")`. Sometimes, the file name being acted on included user input.
I found so many shell injections that could have easily been prevented.
This is not just true of code; it is true of everything - the whole world is held together with spit, bailing wire, a prayer, and some old dude who remembers.
Totally agree; we've created a system that goes so far beyond technical debt we're going to have to call it technical usury, and we're piling it up at rapid rates.
Given that most code gets thrown away, perhaps it won't matter much.
> I suspect if people saw the handwritten code of many, many, many products that they used every day they would be shocked.
Absolutely. The difference is that the amount of bad code that could be generated had an upper limit on it — how fast a human can type it out. With LLMs bad code can be shat out at warp speed.
Oh I don't disagree with that. I am getting pretty tired of people making multi-thousand-line pull requests with lots of clearly AI-generated code and expecting it to be merged in.
I think the better unit to commit and work with is the prompt itself, and I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
> I think that the prompt is the thing that should be PR'd at this point, because ultimately the spec is what's important.
The fundamental problem there is the code generation step is non-deterministic. You might make a two sentence change to the prompt to fix a bug and the generation introduces two more. Generate again and everything is fine. Way too much uncertainty to have confidence in that approach.
If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic.
Also, people aren't actually reading through most of the code that is generated or merged, so if there's a fear of deploying buggy code generated by AI, then I assure you that's already happening. A lot.
> If you make the prompts specific enough and provide tests that it has to run before it passes, then it should be fairly close to deterministic.
Your prompt may work on the specific state of code base and not before or after some changes. Your tests can check for the specific behavior but not for the absence of undesirable behaviors induced by absence of some specific code or by addition of other specific code.
> I assure you that's already happening. A lot.
Thank you for assurance. Can we have less of it? Thank you again.
Hell sometimes the ai may look at values in .env or other uncommited stuff. Its execution path may depend on which commands are available in the environment. The specific model and settings. On top of the inherent randomness if you havent set model heat to 0. i suspect it is very hard to get consistent reproducible ai runs
I have actually, for my personal projects. I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists. I have a Java version that works right now and I will likely be pushing it within the next week.
But more generally, I actually have been building some CI stuff to automate how I'm saying.
I don't have much of a say how this is handled at work so they're just committing the generated code, but I actually am doing what I am talking about.
> I have been writing a library called "assume" where you can specify a type signature, give it a prompt, and it generates a function on the fly in the background with Claude Code, so you still write some code, but whenever you need a function you "assume" that such a function exists.
This is very much like good old djinn [1], which would generate code from Haskell type specification.
And this is why I boldly compare current LLM craze to the much less hyped craze of strong type systems. I was a part of that strong type system discussion, advocating for them. ;)
LLMs are neat, code generation is neat, but I do wish that people had learned type theory and instead used those.
I'm not aware of djinn, but I do remember the "Type Driven Development" that Idris had that I thought was absurdly cool; when you make the type specification clear enough, there ends up being basically exactly one reasonable way of writing the code, in which case it can just be "deduced" by machinery.
I'm a huge advocate for formal methods, and it does sort of bother me that pretty much all work on that seems to have been refocused on AI.
Sounds like a fun project. And are you committing code for this library? Because it sounds like you are, and if that's the case I don't think you're actually doing what you're talking about.
Like, come on. Software has been shit for decades. AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.
> AI hasn't observably reduced the quality of software I use everyday in a way that is meaningfully separable from normal incidents in the past.
Most probably, you are not looking into that well enough.
Average duration for AWS outages [2] was 1.5 hours per outage, 38 hours total. Most recent AWS outage in 2026 [1] downed AWS for 13 hours, a third of 38 hours spanning an year before, and was caused by AWS LLM coding tool.
Not as small as The Last Ninja, but when I was a teenager first getting into emulation, I genuinely thought there was a mistake or my download got interrupted when I downloaded Super Mario Bros. 3, because it was only like 500kb [1], and I didn't think it was possible for a game that huge to be less than a megabyte.
It is still impressive to me how much game they could squeeze out of the NES ROM chips.
[1] Or something like that, I don't remember the exact number.
I don't know anything about Thom, but I've kind of grown to prefer the pissy opinionated tones of blog posts. I think impartiality is difficult or impossible for a lot of tasks, and I'd rather people lay out their opinions plainly than trying to pretend that what they're saying is "objective".
Also, I think writing only when you have things to criticize is a valid enough thing to do; what's the point of writing a glorified "I agree!" article?
I only ever blog when I have something that I think is unique to say, and as such a lot of the time my posts end up being kind of negative. I don't think I'm that negative of a person, I just don't see the point of flooding the internet with more echo-chambers.
It's one thing when it's the Associated Press, where they are trying to be a somewhat impartial source of news and reporting raw facts to the best of their ability; stuff like that probably should not have an opinionated tone at all.
But I think for things like blogs, without opinions being clear, posts can feel kind of soulless. Even before LLMs I felt that way, and now it has been amplified ten fold with people just cranking out low-effort posts with ChatGPT for reasons that I do not understand.
When I write stuff for my blog, I like to think of it as a time capsule of the entirety of the thing I'm writing about. This doesn't just include the raw subject matter, but also my mood and opinions about the subject matter. I'm egotistical enough to occasionally read through my old posts and the ones that I like the best are the ones where I feel like I was expressing myself the most, and where I make no effort whatsoever to try and be impartial.
I should check it out, it would be fun to see my house recreated as a model.
I love projects like this; no delusions of trying to change the world, just doing it because the creator thinks it would be cool to do.
reply