It would have been great if they had disclosed which products.
I've been building tons of projects with AI lately, and while this is a massive productivity boost, the code itself doesn't scale.
The acceleration when you start with zero is massive, but with a growing code base, AI hits a wall at some point.
You better understand what you've built going from there.
I watched this happen decades ago. Smart coders knew about memory allocations. Okay coders just assumed that the garbage collector would handle it. One friend of mine wrote code that was 1000 times faster than the people in the next cubicle over. Why? Because he was careful with memory usage and didn't trigger the virtual memory thrashing.
Must be it be swallowed up? Is it not possible that an improvement in productivity increases but still be net positive? I believe that's what happens in the real world.
Yeah, these new-fangled "compilers" will never catch on.
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.
I mean, the difference between a computer and an LLM is correctness. The compiler MUST conform exactly to a spec. An LLM is useful precisely because it does not.
> One friend of mine wrote code that was 1000 times faster than the people in the next cubicle over
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.
I think you misunderstand the purpose. Who cares if it adds technical debt later if your goal is just to have something to show off to get investments? The goal of every startup is to get funding and an exit. The concern is not long term maintainability.
> Who cares if it adds technical debt later if your goal is just to have something to show off to get investments? The goal of every startup is to get funding and an exit. The concern is not long term maintainability
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
Even for the small subset of companies for which this is true, you need to have a successful exit at all. Technical debt is fine from that perspective, but only if the whole thing comes crashing down AFTER you sell. If it comes crashing down too soon, you have done nothing but waste a few years of your life.
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.
Nobody cares about tech debt when large orgs are happy to rewrite every workload each decade. Every reorg finds the debt, blames it on “the last guy” (now in management), and they replace some components with new tech. Rinse and repeat.
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.
I'm not surprised. There is a complete meltdown in the Cursor subreddit because some update made code generation worse in "agent" mode. It seems that there are many people completely relying on prompting without reviewing any code at all.
Haven’t most models dropped in price per token in the past few years? Despite being far better?
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)
Aside from this pedantry being useless, GPT-4o as 1 of many examples, has had several updates including both its knowledge cutoff but also meaningful improvements (usually) in other benchmarks, without any official renaming etc.
It's honestly kind of entertaining to read the posts on there where folks are talking about Cursor messing up their codebase and every comment is telling them to learn coding basics and start using git.
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.
“Will creep” is the wrong tense: we’re doing it now. At $bigco we’ve rolled out GH Copilot and an AWS sandbox with Sonnet3.7 et al to the whole engineering org (which is big). We already have a 2025 KPI around copilot use by devs, human review required for generated code commits (by policy) for now. Just this week we started rolling out automated copilot PR reviews for human code, it’s already packaged in github action runners. PMs are already using genai for fleshing out epics and features and the architecture org has a demo next week of a genai diagramming tool.
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
> During the discussion, Hu said that even if product builders rely heavily on AI, one skill they would have to be good at is reading the code and finding bugs.
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
>So if you're as clever as you can be when you wrote it, how will you ever debug it?
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.
> 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 wasn’t suggesting anyone should duplicate code or that duplication doesn’t have downsides. My point was more about how LLMs, by default, tend to produce less “clever” (and often more repetitive) code. We know that duplicated code can be painful when bugs need fixing across multiple places, but I’m curious how programming practices will evolve moving forwards as I don't see this going away in the short-term.
I'd imagine AI refactoring meta layers will continue to develop and grow in importance with time. Right now the focus is on generating reams of new code. As time passes this will inevitably shift to more of a focus on maintaining the code.
I would expect there to be innovation in this arena as well, beyond auto-generating code comments for future maintainers.
> Programs must be written for people to read, and only incidentally for machines to execute.
-- 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.
> Programs must be written for people to read, and only incidentally for machines to execute.
-- 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.
Sounds like you're just trying to justify poor software development practices. You can have code that is both performant and readable. Programmers once had to write software for machines 100 times weaker than current machines, yet they had no issue creating software more complex than anything we'll ever build.
This stood out to me as well, along with this quote:
"“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."
Well AI is best at greenfield projects, so it makes sense. What would be interesting to track is the amount of code still written by AI after 1 year or more if the company still exists.
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.
> In a video titled “Vibe Coding Is the Future,” Friedman, along with YC CEO Garry Tan, managing partner Harj Taggar, and general partner Diana Hu, discussed the trend of using natural language and instincts to create code.
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.
I recently started using cursor for my side business and it's been amazing so far. I found that it works best for simple questions where I would normally go to stack overflow and for "drudge work".
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.
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.
I feel like this is not a very insightful take - you can have an AI generated codebase where every function is generated by prompting from humans - such a codebase could be pretty good indeed.
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.
Prediction: soon we will see the first vibes based billionaire. They'll have no idea what they did, what their product does, how it works, or any possible ethical implications of having developed it.
55 comments
[ 2.9 ms ] story [ 109 ms ] threadAI is just another form of automation.
Yes.
Because user CPU cycles are cheaper than developer brain power.
[0] https://en.wikipedia.org/wiki/Jevons_paradox
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.
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
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."
To which I say: a race to the bottom is still a race, yes, but not one you want to win
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.
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.
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.
But they'll be fucking rich.