Live data from Hacker News

AI coding

geohot.github.io

141–150 of 299 posts

Re: AI coding

#141
post #122

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%…

You made a forest hut and you are calling out people who build skyscrapers - gatekeepers.

No. I'm just saying: "yes, AI can code."

Re: AI coding

#142

Earlier quoted context omitted.

> Add logging throughout some code That's one of the thing that I wouldn't delegate to LLM. Logging is like a report of things that happens. And just like a report, I need relevant information and the most useful information. ... A lot of these use cases actually describes the what. But the most important questions is always the why. Why is it important to you? Or to the user? That's when things have a purpose and no…

Code with logging is "self reporting". Adding logging statements is not reporting itself. Adding `logger.error(f"{job} failed")` is not reporting itself, and LLMs are perfectly capable of adding such statements in applicable places. As to why, it's because I'm building an app with a growing userbase and need to accommodate to their requirements and build new features to stay ahead of the competition. Why you decided…

As someone else said: Launch is only the first step. That's when practicality start to matter.

The reason senior engineers are being paid that well is not because they need to type a lot of code to get new features in. It's because they need to figure how to have less code while having more features.

Re: AI coding

#143
post #131
post #79

Earlier quoted context omitted.

Interesting point. There's also the fact that, while you're coding the easy stuff, your mind is thinking about the hard stuff, looking things up, seeing how they articulate. If you're spending 100% of your time on hard stuff, you might be hurting these preliminaries.

This makes no sense. Yes, having time to think about the hard part is good, but just because you’re not doing the boilerplate anymore doesn’t mean you can’t do the thinking part anymore! See how absurd it sounds when you actually describe it this way?

Let me rephrase.

I know brilliant people who took up knitting to keep their hands busy while they think over their difficult problems. But that only works if you can knit in your work hours. Sadly, despite clearly improving the productivity of these people, this is a fireable offense in many jobs.

I'm not saying that the only way to think through a hard problem is to work on boilerplate. If you are in a workplace where you can knit, or play table soccer, by all means, and if these help you, by all means, go for it.

What I'm thinking out loud is that if we're dedicating 100% of our time to the hard problems, we'll hit a snag, and that boilerplate may (accidentally) serve as the padding that makes sure we're not at these 100%.

That being said, I'm not going to claim this as a certainty, just an idea.

Re: AI coding

#144

AI coding is the one thing that got my back to programming. I got to the point in life, when my ability to focus is reducing, and I prefer to send the remaining energy elsewhere. I kind of gave up on programming, just doing architecture and occasionally doing very small programming tasks. It all changed when I discovered Claude Code and saw that the way it works, is kind of how I work. I also use a lot of grep to fin…

I feel the same way. After 30+ years coding, I know what I want to build, but finding the time to work on it and the focus is harder than it used to be.

Re: AI coding

#145

Great short read. But this “ It’s why the world wasted $10B+ on self driving car companies that obviously made no sense.” Not everything should make sense. Playing , trying and failing is crucial to make our world nicer. Not overthinking is key, see later what works and why.

"that obviously made no sense" is bizarre.

Waymo's driving people around with an injuries-per-mile rate that's lower than having humans do it. I don't see how that reconciles with "obviously made no sense".

Re: AI coding

#146
post #70

This is a more extreme example of the general hacker news group think about AI. Geohot is easily a 99.999 percentile developer, and yet he can’t seem to reconcile that the other 99.999 percent are doing something much more basic than he can ever comprehend. It’s some kind of expert paradox, if everyone was as smart and capable as the experts, then they wouldn’t be experts. I have come across many developers that beha…

This.

I think his excellency in his own trade limited his vision for the 99% who just want to get by in the job. How many dev even deal with compiler directly these days? They write some code, fix some red underlines, then push, pray and wait for pipeline pass. LLMs will be gods in this process, and you can even beg another one if your current one does not work best.

Re: AI coding

#147

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…

That‘s exactly why i like AI too. I even let them play roles like „junior dev“, „product owner“ or „devops engineer“ and orchestrate them, to play together as a team - with guidance from me (usually the „solution architect“ or „investor“)! This „team“ achieves in weeks what we usually needed months for - for 2.40€/h*role!

Re: AI coding

#148
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., SWE-bench Verified), something a compiler doesn’t do. Benchmarks now show top agents/models resolving large fractions of real GitHub issues, which is evidence of synthesis + tool use, not compilation.

Second, that the "programming language is English". Serious workflows aren’t "just English." They use repo context, unit tests, typed APIs, JSON/function-calling schemas, diffs, and editor tools. The "prompt" is often code + tests + spec, with English as glue. The author attacks the weakest interface, not how people actually ship with these tools.

Third, non-determinism isn't disqualifying. Plenty of effective engineering tools are stochastic (fuzzers, search/optimization, SAT/SMT with heuristics). Determinism comes from external specs: unit/integration tests, type systems, property-based tests, CI gates.

False dichotomy: "LLMs are popular only because languages/libraries are bad." Languages are improving (e.g. Rust, Typescript), yet LLMs still help because the real bottlenecks are API lookup, cross-repo reading, boilerplate, migrations, test writing, and refactors, the areas where retrieval and synthesis shine. These are complementary forces, not substitutes.

Finally, no constructive alternatives are offered. "Build better compilers/languages" is fine but modern teams already get value by pairing those with AI: spec-first prompts, test-gated edits, typed SDK scaffolds, auto-generated tests, CI-verified refactors, and repo-aware agents.

A much better way to think about AI coding and LLMs is that they aren’t compilers. They’re probabilistic code synthesizers guided by your constraints (types, tests, CI). Treat them like a junior pair-programmer wired into your repo, search, and toolchain. But not like a magical English compiler.

Re: AI coding

#149

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…

> developer somewhere between junior and mid-level Why the insistence on anthropomorphizing what is just a tool? It has no agency, does not 'think' in any meaningful manner, it is just pattern matching on a vast corpus of training data. That's not to say it can't be very useful - as you seem to have found - but it is still just a tool.

It's not anthropomorphising though, is it? It's just a comparison of the tool's ability. Like talking about the horsepower of an engine.

Re: AI coding

#150

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…

Excellent response, completely agree.
Post reply on HN