Live data from Hacker News

AI coding

geohot.github.io

151–160 of 299 posts

Re: AI coding

#151
post #48

I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…

I love AI for speed running through all the boring stuff and getting to the good parts. In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of tim…

I think you're describing things we already knew long before this era of AI. Less code is better code, and the vast majority of bugs come from the devs who "hate the boring easy bits".

I disagree that this has anything to do with people needing a break. All code eventually has to be reviewed. Regardless of who or what wrote it, writing too much of it is the problem. It's also worth considering how much more code could be eliminated if the business more critically planned what they think they want.

These tensions have existed even before computers and in all professions.

Re: AI coding

#152

So I have all kinds of problems with this post. First, the assertion that the best model of "AI coding" is that it is a compiler. Compilers deterministically map a formal language to another under a spec. LLM coding tools are search-based program synthesizers that retrieve, generate, and iteratively edit code under constraints (tests/types/linters/CI). That’s why they can fix issues end-to-end on real repos (e.g., SW…

It's not surprising that you're finding problems with the article. It's written by George Hotz aka Geohot.

Re: AI coding

#153

I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me. Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work. It only takes basic english to produce these results, plus complaining to the AI agent that "The GUI is ugly and overcrowded. Make it look better, and dark mode." Want specs? "include a specs.md" This isn't a 20%…

I think it's like CMS and page builders enabling people to build their own websites without html and server knowledge. They're not making web developers disappear, instead there are more web developers now because those some of those people would eventually outgrow their page builders and need to hire web developers.

Re: AI coding

#154

I do agree with many points in the article, but not about the last part, namely that coding with AI assist makes you slower. Personal experience (data points count = 1), as a somewhat seasoned dev (>30yrs of coding), it makes me WAY faster. I confess to not read the code produced at each iteration other than skimming through it for obvious architectural code smell, but I do read the final version line by line and mak…

> Personal experience (data points count = 1), as a somewhat seasoned dev (>30yrs of coding), it makes me WAY faster. > Long story short: things that would take me a week to put together now take a couple of hours. The vast bulk of the time saved is not having to identify the libraries I need, and not to have to rummage through API documentation. One of these is not true. With libraries, it's either you HAVE to use i…

> you are evaluating multiple ones (and that task is much quicker).

Of course the latter. And of course I ask the AI to help me select a libray/module/project/whatever that provides what I need. And I ask the AI to classify them by popularity/robustness. And then I apply whatever little/much I know about the space to refine the choice.

may go as far as looking at examples that use the API. And maybe rummage through the code being the API to see if I like what I see.

The whole thing is altogether still way faster than having to pick what I need by hand with my rather limited data ingestion capabilities.

And then, once I've picked one, connecting to the API's is a no-brainer with an LLM, goes super fast.

Altogether major time saved.

Re: AI coding

#155

I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…

> I can pretty much see projects in my head, and know exactly what to build.

This is where AI actually helps - you have a very precise vision of what you want, but perhaps you've forgotten about the specific names of certain API methods, etc. Maybe you don't want to implement all the cases by hand. Often validating the output can take just seconds when you know what it is you're looking for.

The other part of making the output do what you want is the ability to write a prompt that captures the most essential constraints of your vision. I've noticed the ability to write and articulate ideas well in natural language terms is the actual bottleneck for most developers. It takes just as much practice communicating your ideas as it does anything else to get good at it.

Re: AI coding

#156

I'm almost 50, and have been writing code professionally since the late 90s. I can pretty much see projects in my head, and know exactly what to build. I also get paid pretty well for what I do. You'd think I'd be the prototype for anti-AI. I'm not. I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the goo…

> I can build anything, but often struggle with getting bogged down with all the basic work. I love AI for speed running through all the boring stuff and getting to the good parts.

I'm in the same boat (granted, 10 years less) but can't really relate with this. By the time any part becomes boring, I start to automate/generalize it, which is very challenging to do well. That leaves me so little boring work that I speed run through it faster by typing it myself than I could prompt it.

The parts in the middle – non-trivial but not big picture – in my experience are the parts where writing the code myself constantly uncovers better ways to improve both the big picture and the automation/generalization. Because of that, there are almost no lines of code that I write that I feel I want to offload. Almost every line of code either improves the future of the software or my skills as a developer.

But perhaps I've been lucky enough to work in the same place for long. If I couldn't bring my code with me and had to constantly start from scratch, I might have a different opinion.

Re: AI coding

#157
That METR study gets a lot of traction for its headline; and I doubt many people read the whole thing—it was long—but the data showed a 50% speed up for the one dev with the most experience with Cursor/AI, suggesting a learning curve and also wild statistical variation on a small sample set. An errata later suggested another dev who did not have a speedup had not represented their experience correctly, but still strongly draws into question the significance of the findings.

The specific time sucks measured in the study are addressable with improved technology like faster LLMs and improved methodology like running parallel agents—the study was done in March running Claude 3.7 and before Claude Code.

We also should value the perception of having worked 20% less even if you actually spent more time. Time flies when you’re having fun!

Re: AI coding

#158
post #48

Earlier quoted context omitted.

I love AI for speed running through all the boring stuff and getting to the good parts. In some cases, especially with the more senior devs in my org, fear of the good parts is why they're against AI. Devs often want the inherent safety of the boring, easy stuff for a while. AI changes the job to be a constant struggle with hard problems. That isn't necessarily a good thing. If you're actually senior by virtue of tim…

> Devs often want the inherent safety of the boring, easy stuff for a while That's matches my experience. In my first job, every time a new webapp project has been starting it was fun. Not because of challenges or design, but simply because of the trivial stuff done for n-th time - user accounts, login, password reset, admin panel. Probably should have been automated at this point, but we got away with reinventing th…

[deleted]

Re: AI coding

#159
post #97

I'm a 100% vibe-coder. AI/CS is not my field. I've made plenty of neat apps that are useful to me. Don't ask me how they work; they just do. Sure the engineering may be abysmal, but it's good enough to work. It only takes basic english to produce these results, plus complaining to the AI agent that "The GUI is ugly and overcrowded. Make it look better, and dark mode." Want specs? "include a specs.md" This isn't a 20%…

The crucial part is security. If the apps runs locally it doesn’t matter, if it‘s connected to the net it could be the seed for the next Mirai bot network.

It’s a pretty good solution for creating live mockups. A designer on my team came back eight hours after a meeting with a fully vibe coded, multi-page interface. I was honestly blown away. I had no idea this was the state of what’s possible with these tools.

Was it a real website? No, but it’s a live mockup way better than any Figma mock or rigid demo-ware.

Re: AI coding

#160

Earlier quoted context omitted.

Which was my original point. Not that the outcome is shit. So much of what we write is absolutely low-skill and low-impact, but necessary and labor-intensive. Most of it is so basic and boilerplate you really can't look at it and know if it was machine- or human-generated. Why shouldn't that work get cranked out in seconds instead of hours? Then we can do the actual work we're paid to do. To pair this with the commen…

> So much of what we write is absolutely low-skill and low-impact, but necessary and labor-intensive. Most of it is so basic and boilerplate you really can't look at it and know if it was machine- or human-generated. Is it really? Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction. I've seen people describing…

If you're not able to review what it generates, you shouldn't be using it (and arguably are the wrong person to be doing the boilerplate work to begin with)

Put differently, I go back to my original comment, where AI is essentially a junior/mid dev that you can express what needs to be done with enough detail. In either case, AI or dev, you'd review and/or verify it.

> Or is it a refusal to do actual software engineering, letting the machine taking care of it (deterministically) and moving up the ladder in terms of abstraction.

One could say the same of installing packages in most modern programming languages instead of writing the code from first principles.

Post reply on HN