1/4 of startups in YC current cohort have almost entirely AI-generated codebases
techcrunch.com
techcrunch.com
I cannot fathom why anyone who writes and maintain code would embrace AI tools that essentially shift their job to be more code review and less coding
Especially given the quality of AI generated code is all over the place
People say "it's like a good junior" but I disagree wholeheartedly. Good juniors eventually stop making the same mistakes
The overall technology may. A new model may be better than an old model
But a model is fixed
That's the difference
Your model isn't improving
Get ready to jump on the "pay us more for better models" treadmill or get left behind
Even if we say they haven’t, humans also get paid more as their skills/ability improve. If this hasn’t happened for you I’ve got bad news (or your boss is a dick)
It will be really interesting how "vibe coding" will cause the field to evolve. My gut says that right now it's just non-technical folks that do it and programmer that do it for fun. But IMO this will creep into the industry and will eventually result in an even bigger junior/senior gap.
If this tech saves four cents net/net it doesn’t matter how many engineers go away. It’s short sighted for sure, nobody cares if we don’t have junior devs in five years as long as we decrease headcount. Senior leadership was on the fence a bit until they came back from re:invent, AWS must have pushed hard in those closed door meetings. They came home positively GIDDY
AI is just another form of automation.
Yes.
Because user CPU cycles are cheaper than developer brain power.
Programmers who rely on them will stop learning machine code, and won't know how their program really works. That's if the compiler actually compiles your code at all, without throwing an internal error, making you change your (correct) code around arbitrarily until it actually accepts it. But at least with an internal compiler error you know the compiler has broken - rather than it silently miscompiling your code to do the wrong thing.
But even then, even if the compiler accepts your code without barfing, and generates correct machine code from it, it still won't generate as efficient machine code as you could write by hand yourself.
Nope, these compilers will never catch on, and never get reliable enough to be useful for serious software engineering.
-- Some programmer circa 1975, probably, who lives in my head mumbling this to themselves whenever I'm sure generative-AI-based "programming" is a crock of shit. Although, to be fair, the 2005-era developer who is drunkenly ranting that UML diagrams will make programming 100x more productive any day now, is a handy counterpoint.
And did that 1000x speedup make a difference to users? Are we talking about an on-click event that now took 10μs instead of 10ms? Was this a 1000x speedup in a hot critical-path bottleneck, or was it an already quick in-memory post-processing operation that fired after waiting 30 seconds on a sluggish database query?
Sorry to doubt so much, but the vast majority of times someone boasts about a speedup like this, it turns out to be done for bragging rights rather than for the benefit of the project. A 1000x speedup is only impressive if you can show that the time you improved upon was actually a problem.
Then it's not a productivity boost imo
"Produces more tech debt faster" is the worst possible outcome of a 'productivity' tool
Not everyone works in startups, specifically to avoid this disgusting mentality
If I had to deal with this "build garbage quickly to get money and run before the house of cards collapses" mentality in my day to day life I would put my face into a wood chipper
I loathe people who think this way, and it is so miserable that all tech is becoming just a vehicle for this sort of grift
Robbing banks at gunpoint is more honest
Remember that most successful exits happen more than 5 years after founding. Having an AI vomit out a prototype in a week vs doing it yourself in 4 might get you seed funding marginally faster, but if it delays product development more than 3 weeks over the next 4-5 years it's still not worth it.
Source code just isn’t an asset anymore, and it’s been slowly growing since Serverless; genai just accelerated it, and “bucket o’ lambdas” is a valid architecture now.
Naturally, that brings to mind the classic:
> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
-- Brian Kernighan, The Elements of Programming Style
And also:
> Programs must be written for people to read, and only incidentally for machines to execute.
-- Abelson & Sussman, Structure and Interpretation of Computer Programs
LLMs do not write very "clever" code by default. Without prompting them continuously to make it more "clever", they tend to write lots and lots of simple code, vs writing "clever" code that reduces redundant code, improves performance, etc.
What I am curious about is if these slop-filled codebases will be a problem or not in the future - traditionally it's been bad practice to have duplicate code everywhere, but with LLMs it feels like it matters less, as long as the code is simple and readable.
duplicate code is a bad practice "traditionally" because it means if you have a bug, you have to fix it in N spots (each of which may have drifted to be slightly different) instead of just 1.
how do LLMs improve that? if you have a bug (which everyone seems to agree happens more often with LLM-generated code) you'll still need to fix it in N spots. being able to feed those N instances into the LLM and ask it to fix the bug maybe speeds the process up a little, but it doesn't solve the underlying problem.
when I got into the industry in the 2000s, saving costs by outsourcing to India was the hype cycle of the day. would you have the same opinion that duplicate code doesn't matter, because you can just pay cheap outsourced engineers to make those N redundant bugfixes?
I would expect there to be innovation in this arena as well, beyond auto-generating code comments for future maintainers.
-- Abelson & Sussman, Structure and Interpretation of Computer Programs
I've been living by this my entire career without ever having read this book. I just snagged it. I really do believe that our primary job is to write code that people can understand and I justify it with a 2 axis analysis: code is either correct or incorrect, and comprehensible or incomprehensible. Code that is correct doesn't require any attention and isn't worth considering. All the code we care about is incorrect, then, and so it's either comprehensible (and therefore fixable) or it's not. Given those facts, and the understanding that code rot and AC changes cause all code to become incorrect over time, my primary job is to write code that other developers can understand so that when it becomes incorrect they can do something about it.
Until the requirements of the system (of any kind) change and now the code isn't 'correct' for the new requirements and needs updating.
---the OP
-- Abelson & Sussman, Structure and Interpretation of Computer Programs
I think a lot about this whenever I hear blanket statements about software performance. A program should be optimized for its performance on whichever piece of hardware it executes on with the highest cost / hour. 95+% of the time that piece of hardware is yours or your coworker's brain.
"“Let’s say a startup with 95% AI-generated code goes out [in the market], and a year or two out, they have 100 million users on that product, does it fall over or not? The first versions of reasoning models are not good at debugging. So you have to go in depth of what’s happening with the product,” he suggested."
I think our initial reactions as SWEs may be to dismiss this, but if non technical folks (who might be closer to a real customer need) can spin something up to get traction, that’s a win. What is important is delivering value to end users. I wonder how many genuinely good business ideas never happened in the past because a technical cofounder wasn’t available.
how many YC-backed startups (in general, not just the current batch) have products based in some way on LLM code-generation?
it seems like there's a significant chance for a conflict of interest here, where YC has an incentive to build up hype about LLM-generated codebases in order to benefit their overall portfolio.
will we see a follow-up story several months or a year from now, comparing how these startups have fared relative to the other 3/4ths of the batch? if one of them is a success, probably. if all of them fizzle out...maybe not.
One example of "drudge work" is that I'm currently refactoring all strings in the app. Before cursor, it would take me upwards of an hour to refactor the strings in a complex component but now I can just shove all that into cursor and have it do it for me.
For simple questions it sometimes works great and other times just falls apart. In one scenario I asked it why my sequelize query didn't return the data I expected and it immediately gave me a fix. But in another scenario I asked it how to refactor out a "forwardRef" in a component and it just kept recommending that I leave the code as is.
However, in my experience using these reasoning models to generate giant chunks of code usually has disastrous results and barely even works even when working from a clean sheet.
To which I say: a race to the bottom is still a race, yes, but not one you want to win
But they'll be fucking rich.
And hey, I get both Techcrunch and YC need clickbaity, hyperbolic PR, but guys, don't jump the shark on this.
95%? I wish! Either they have access to some seriously next NeXt NEXT gen stuff, or this is pure nonsense, exaggerated by at least half an order of magnitude.