Live data from Hacker News

AI coding

geohot.github.io

251–260 of 299 posts

Re: AI coding

#251

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…

same. 50’s, coding since the 90’s, make more $$ than I can spend in 3 lifetimes. one constant thing in my 3 decade career has been that absolute best people I worked with all had one common thread - absolute laziness. sounds strange but every other trait of a great SWE has not been universal except laziness.

the laziness manifest itself into productivity as crazy as this sounds. how? lazy people find a way to automate repetitive tasks. what I have learned from these over the years is that anything you do twice has to find a way to be automated as third time is around the corner :)

what does this have to do with AI? the AI has taken automation to another level allowing us to automate so much of our work that was not previously possible. I found myriad of ways to use AI and several of my best (lazy) co-workers have as well. I cannot imagine doing my work anymore without it, not because of any “magic” but because my lazy ass will be able to do all the things that I have automated out

Re: AI coding

#252

> Or we could, you know, do the hard work and build better programming languages, compilers, and libraries. But that can’t be hyped up for billions. 100% this. I fear that AI will cause us to be stuck in a local optimum for the next decades where most of the code will be Python or JS because these are the languages best supported by LLMs. Don't get me wrong, Python and JS and mature and productive languages. That's f…

But we could have it so much better if there was more effort put into a next generation of tools that take all the harsh lessons learnt from the tools before and "just" do it better.

We've had 50+ years to do that. Progress has been unimpressive, to be charitable. It's time to let some different people try something else.

Re: AI coding

#253
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…

This is an interesting take on it. I've been using Cursor at work and notice that days where I have it generate all the "easy parts", I end up feeling much more mentally exhausted than if I spend the day writing everything by hand.

That tracks. Being in flow on a task you're confident about is a low arousal, satisfying state.

Monitoring AI output on any task is high arousal, low satisfaction, unless you're constantly prompting for quick wins.

Re: AI coding

#254

Earlier quoted context omitted.

My point is that micro-studies like that on a tiny random (or even counter-indicated, "healthy") selection of the general population don't tell you much for drugs that do specific things. "Antibiotics don't improve your life, but can damage your health" would likely be the outcome on 13 randomly selected healthy individuals. But do the same study on 13 people with a bacterial infection susceptible to antibiotics and…

I don't think that it matters, in this context, as a lot of folks here, have their minds made up, already, and won't let anything interfere. They'll need to learn, the same way I see lots of people learn. It's been around long enough, though, that all the Adderall-eating people should have established a Gattaca-like "elite," with all us "undermen," scrabbling around at their feet. Not sure why that never happened...

As someone with diagnosed ADHD, and prescribed something similar:

It's not that they make you superhuman - I don't think I'm any "smarter" on them. It's just that without them, my "productive" bursts would be at really random times (11PM or 2AM), and make it very hard to fit into a "normal" schedule with the rest of society (I would frequently fall asleep in classes or meetings).

So it's more that it allows you to "rearrange" the same (or slightly larger) amount of work but into a more reasonable, traditional schedule. And for certain things, helps more than that. But it's not a miracle drug by any means.

Re: AI coding

#255
post #198

What an aggressive tone. By the author's implied definition of compiler, a human is also a compiler. (Coffee in, code out, so the saying goes.) But code is distinct from design, and unlike compilers, humans are synthesizers of design. LLMs let you spend more time as system architect instead of code monkey.

I wouldn't over index on his tone here- that's the only tone I've seen him use.

Doesn’t make it any better.

Re: AI coding

#256

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…

Author here. I agree with this comment, but if I wrote more like this my blog post would get less traction.

"LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea.

"Plenty of effective engineering tools are stochastic," sure but while a SAT solver might use randomness and that might adjust your time to solve, it doesn't change the correctness of the result. And for something like a fuzzer, that's a test, which are always more of a best effort thing. I haven't seen a fuzzer deployed in prod.

"Determinism comes from external specs and tests," my dream is a language where I can specify what it does instead of how it does it. Like the concept of Halide's schedule but more generic. The computer can spend its time figuring out the how. And I think this is the kind of tools AI will deliver. Maybe it'll be with LLMs, maybe it'll be something else, but the key is that you need a fairly rigorous spec and that spec itself is the programming. The spec can even be constraint based instead of needing to specify all behavior.

I'm not at all against AI, and if you are using it at a level described in this post, like a tool, aware of its strengths and limitations, I think it can be a great addition to a workflow. I'm against the idea that it's a magical English compiler, which is what I see in public discourse.

Re: AI coding

#257

Earlier quoted context omitted.

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!

I can't tell if you are being sarcastic but this sounds absurd. Why let the AI be junior, why not an expert? This persona driven workflow is so weird to me. Feels like stuck in old ways.

Avoiding context bloat and scoping the chain of thought

Re: AI coding

#258
post #201

Earlier quoted context omitted.

Exactly. If you know how the whole thing works end to end, AI makes you incredibly dangerous. Anyone who specializes or never really learned how everything works is at a huge disadvantage. However. There's also good news. AI is also an amazing tool for learning. So what I see AI doing is simply separating people who want to put effort forth and those who don't.

I agree. Having AI write your entire application is equivalent to having it write a song for your band, or even generate audio so you don't have to do record it yourself. If you aren't talented enough to write or record your own music, you aren't really a musician. If you have a quick question about music theory and you want a quick answer, AI can be a benefit.

Yeah, I don't buy this. Creating art is in no way equivalent to making logic to perform a task.

Re: AI coding

#259

Earlier quoted context omitted.

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.

But we didn't do this with spreadsheets or word processors - and those tools really did replace small armies of clerical and secretarial workers.

The difference is AI is closing on doing the EXACT work with the EXACT info as a junior dev. Give an LLM a Jira ticket and a codebase and it can push a PR. Spreadsheets are great, but that was a tool that minimized effort but didn't remove it. LLMs can directly replace a remote junior with no visible difference already.

Re: AI coding

#260

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…

Author here. I agree with this comment, but if I wrote more like this my blog post would get less traction. "LLM coding tools are search-based program synthesizers," in my mind this is what compilers are. I think most compilers do far too little search and opt for heuristics instead, often because they don't have an integrated runtime environment, but it's the same idea. "Plenty of effective engineering tools are sto…

I think the key insight I walked away with from this whole thread, for me, was:

A compiler takes source and maps it to some output. Regardless of the compiler detail, this is an atomic operation; you end up with source (unmodified) and an artifact.

These “agent workflows” are distinctly different.

The process of mapping prompt to an output is the same; but these agent workflows are destructive; they modify the source.

Free reign over the entire code base; They modify the tests. The spec, the implementation.

It seems like this is a concept people are still struggling with; if your specification is poorly defined, and is dynamically updated during the compilation process, the results are more than just non deterministic.

Over time, the specification becomes non deterministic.

Thats why unsupervised agents go “off the rails”; not because the specification cant be executed, but because over time the spec drifts.

That doesnt happen with compilers.

Post reply on HN