191–200 of 522 posts
Earlier quoted context omitted.
I would normally agree, but I think the "code is a liability" quote assumes that humans are reading and modifying the code. If AI tools are also reading and modifying their own code, is that still true?
What happens when there’s a service outage and you cannot debug code without an agent?
And LLMs aren’t half as good as maintaining code as they are to generate it in the first place. At least yet.
Earlier quoted context omitted.
> If this were to work, could theoretically make nice revenue and it shouldn't show up in any metric anywhere. Except production GDP, the standard measure of economic activity.
Correct me, but if two people create a SAAS that can replace a 50 people SAAS, compete on price and the competitor is forced out of the market, wouldn’t this show up as an reduction in GDP? Efficiency (GDP/time_worked) should be up though, and AFAIK it isn’t.
What are the 48 other people doing now? Presumably some other economic activity.
Earlier quoted context omitted.
Because coding bootcamps and CS programs were churning out squillions of people who could type the code but had poor design and analytical skills, because there was a time where being able to implement Dijkstra on a whiteboard would get you 400k at a FAANG.
And you think these people will now produce better results with the assistance of an LLM that was trained on their work?
Bootcamp grads are basically obsolete now. The real skill has always been the ability to make good design decisions and that's still the case in the LLM era.
> Code has always been expensive. Producing a few hundred lines of clean, tested code takes most software developers a full day or more. Many of our engineering habits, at both the macro and micro level, are built around this core constraint. > ... > Writing good code remains significantly more expensive I think this is a bad argument. Code was expensive because you were trying to write the expensive good code in the…
Last month I did the majority of my work through an agent, and while I did review its work, I’m now finding edge cases and bugs of the kind that I’d never have expected a human to introduce. Obviously it’s on me to better review its output, but the perceived gains of just throwing a quick bug ticket at the ai quickly disappear when you want to have a scalable project.
I basically fully agree with this. I am not sure how to handle the ramifications of this in my day to day work yet. But at least one habit I have been forming is sometimes I find that even though the cost of writing code is immensely cheap, reviewing and validating that it works in certain code bases (like the millions of line mono repo I work in at my job) is extremely high. I try to think through, and improve, our…
That is my observation as well. Churning code is easy, but making sure the code is not total crap is a completely new challenge and concern.
It's not like prior to LLMs code reviews didn't required work. Far from it. It's just that how the code is generated in a completely different way, and in some cases with barely any oversight from vibecoders who are trying to punch way above their weight. So they generate these massive volumes of changes that fail in obvious and subtle ways, and the flow is relentless.
Earlier quoted context omitted.
Or another way of looking at it: just because digging a ditch became cheap and fast with the backhoe doesn't mean you can just dig a bunch of ditches and become rich.
Yeah but there were a lot less ditch diggers in the world after the invention of the backhoe
As a specialization? Sure. But the ditch diggers moved since to machine operators, handymen and the like.
In the past there were sysadmins. Do we have less software engineers since sysadmins ceased to be a thing?
If coding is so cheap, I hope people start vibing Rust. If the machine can do the work, please have it output in a performant language. I do not need more JS/Python utilities that require embarrassing amounts of RAM.
Turned it into a Stripe revenue dashboard and notifier.
Even bought a couple more, flashed them, and gave to my cofounders, complete with AI written (personally tested, though) setup instructions!
Earlier quoted context omitted.
It's funny that so many people are using AI and still hasn't really shown up in productivity numbers or product quality yet. I'm going to be really confused if this is still the case at the end of the year. A whole year of access to these latest agentic models has to produce visible economic changes or something is wrong.
This is actually an old syndrome with technology. It takes a longt ime for the effect to be reliably measured. Famously, it took many years for the internet itself to show up in significant productivity gains (if the internet is actually useful why don't the numbers show that? - a common comment in the 1990s and 2000s). So it seems to me we're just the usual dynamic here. Productivity in trillion-dollar economies do…
Yeah but the actual productivity gains that the internet and software tools introduced has had diminishing returns after a while.
Like, are people more productive today when they use Outlook and Slack than they were 20 years ago when using IBM Lotus Notes and IBM Sametime? I'm not. Are people more productive with the Excel of today than with Excel 2003/2007? I'm not. Is Windows 11 and MacOS Tahoe making people more productive than Windows 7 and Snow Leopard? Not me. Are IDEs of today offering so much more productivity boost than what Visual Studio, CodeWarrior and Borland Delphi did back in the day? Don't think so.
To me it seems that at least on the productivity side, we've mostly been reinventing the wheel "but in Rust/Electron" for the last 15 or so years, and the biggest productivity gains came IMHO from increased compute power due to semiconductor advancement, so that the same tasks finished faster today than 20 years ago, but not that the SW or the internet got so much more capable since then.
> Here's what I mean by "good code": > [...] > - It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future. But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk.
> But do the humans need to actually understand the code? A "yes" means the bottleneck is understanding (code review, code inspection). A "no" means you can go faster, but at some risk. I always thought of things like code reviews as semi pseudo-science in most cases. I've sat through meetings where developers obviously understand the code that they are reviewing, but where they didn't understand anything about the s…
How?