Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The current state of LLM-driven development

blog.tolki.dev

Post reply on HN
Print view View original

151–160 of 244 posts

Re: The current state of LLM-driven development

#151

Post by sudhirb »

troupo wrote: post #104
sudhirb wrote: post #90

Earlier quoted context omitted.

By no means are better background agents "mythical" as you claim. I didn't bother to mention them as it is easy enough to search for asynchronous/background agents yourself. Devin is perhaps the one that is most fully featured and I believe has been around the longest. Other examples that seem to be getting some attention recently are Warp, Cursor's own background agent implementation, Charlie Labs, Codegen, Tembo, a…

> as it is easy enough to search for asynchronous/background agents yourself. Ah yes. An unverifiable claim followed by "just google them yourself". > Devin is perhaps the one that is most fully featured and I believe has been around the longest. And it had been hilariously bad the longest. Is it better now? Maybe? I don't really know anyone even mentioning Devin anymore > examples that seem to be getting some attent…

>Ah yes. An unverifiable claim followed by "just google them yourself".

Some agent scaffolding performs better on benchmarks than others given the same underlying base model - see SWE Bench and Terminal Bench for examples.

Some may find certain background agents better than others simply because of UX. Some background agents have features that others don't - like memory systems, MCP, 3rd party integrations, etc.

I maintain it is easy to search for examples of background coding agents that are not Jules or Copilot. For me, searching "background coding agents" on google or duckduckgo returns some of the other examples that I mentioned.

Re: The current state of LLM-driven development

#152

Post by candiddevmike »

d_silin wrote: post #150

Relying on LLM for any skill, especially programming, is like cutting your own healthy legs and buying crutches to walk. Plus you now have to pay $49/month for basic walking ability and $99/month for "Walk+" plan, where you can also (clumsily) jog.

Why would I pay you to walk with crutches when I can just get crutches and walk myself?

Re: The current state of LLM-driven development

#153

Post by aeonik »

d_silin wrote: post #150

Relying on LLM for any skill, especially programming, is like cutting your own healthy legs and buying crutches to walk. Plus you now have to pay $49/month for basic walking ability and $99/month for "Walk+" plan, where you can also (clumsily) jog.

It's more like strapping on a exoskeleton suit with a jetpack.

It makes your existing strength and mobility greater, but don't be surprised if you fly into space that you will suffocate,

or if you fly over an ocean and run out gas, that you'll sink to the bottom,

or if you fly the suit in your fine glassware shop with patrons in the store, that your going to break and burn everything/everyone in there.

Re: The current state of LLM-driven development

#154

Post by diatone »

simonw wrote: post #141
donperignon wrote: post #132

Earlier quoted context omitted.

Yeah if I want I to develop I need tooling around me. Still trivial to learn. Not a difficult skill. Not an specific skill to llm.

Why would you need to take all of these additional sandboxing measures if you weren't using an LLM?

For one - I’d say scoped API tokens that prevent messing with resources across logical domains (eg prod vs nonprod, distinct github repos, etc) is best practice in general. Blowing up a resource with a broadly scoped token isn’t a failure mode unique to LLMs.

edit: I don’t have personal experience around spending limits but I vaguely recall them being useful for folks who want to set up AWS resources and swing for the fences, in startups without thinking too deeply about the infra. Again this isn’t a failure mode unique to LLMs although I can appreciate it not mapping perfectly to your scenario above

edit #2: fwict the LLM specific context of your scenario above is: providing examples, setting up API access somehow (eg maybe invoking a CLI?). The rest to me seems like good old software engineering

Re: The current state of LLM-driven development

#155

Post by derektank »

d_silin wrote: post #150

Relying on LLM for any skill, especially programming, is like cutting your own healthy legs and buying crutches to walk. Plus you now have to pay $49/month for basic walking ability and $99/month for "Walk+" plan, where you can also (clumsily) jog.

There are a lot of skills which I haven't developed because I rely on external machines to handle it for me; memorization, fire-starting, navigation. On net, my life is better for it. LLMs may or may not be as effective at replacing code development as books have been at replacing memorization and GPS has been at replacing navigation, but eventually some tool will be and I don't think I'll be worse off for developing other skills.

Re: The current state of LLM-driven development

#156

Post by azan_ »

troupo wrote: post #66
tptacek wrote: post #54

Earlier quoted context omitted.

Even this opens up a whole field of weird subtle workflow tricks people have, because people run parallel asynchronous agents that step on each other in git. Solo developers run teams now! Really wild to hear someone say out loud "there's no learning curve to using this stuff".

The "learning curve" is reading "experts opinion" on the ever-changing set of magical rituals that may or may not work but trust us it works.

No, you do not need to trust anyone, you can just verify what works and what doesn't, it's very easy.

Re: The current state of LLM-driven development

#157

Post by phillipcarter »

leptons wrote: post #33
trenchpilgrim wrote: post #21

Earlier quoted context omitted.

The amount of misconceptions in this comment are quite profound. Copilot isn't an LLM, for a start. You _combine_ it wil a selection of LLMs. And it absolutely has severe limitations compared to something like Claude Code in how it can interact with the programming environment. "Hallucinations" are far less of a problem with software that grounds the AI to the truth in your compiler, diagnostics, static analysis, a r…

>Copilot isn't an LLM, for a start You're being overly pedantic here and moving goalposts. Copilot (for coding) without an LLM is pretty useless. I stand by my assertion that these tools are all basically the same fundamental tech - LLMs.

This is like saying every web app is basically the same fundamental tech - databases.

Re: The current state of LLM-driven development

#158

Post by d_silin »

derektank wrote: post #155
d_silin wrote: post #150

Relying on LLM for any skill, especially programming, is like cutting your own healthy legs and buying crutches to walk. Plus you now have to pay $49/month for basic walking ability and $99/month for "Walk+" plan, where you can also (clumsily) jog.

There are a lot of skills which I haven't developed because I rely on external machines to handle it for me; memorization, fire-starting, navigation. On net, my life is better for it. LLMs may or may not be as effective at replacing code development as books have been at replacing memorization and GPS has been at replacing navigation, but eventually some tool will be and I don't think I'll be worse off for developing…

GPS is particularly good analog... Lose it for any reason and suddenly you are helpless without backup navigation aids. But compass, paper map, watch and sextant will still work!

Re: The current state of LLM-driven development

#159

Post by thefourthchime »

throwawaybob420 wrote: post #140

Judging from all the comments here, it’s going to be amazing seeing the fallout of all the LLM generated code in a year or so. The amount of people who seemingly relish the ability to stop thinking and let the model generate giant chunks of their code base, is uh, something else lol.

It entirely depends on the exposure and reliability the code needs. Some code is just a one-off to show a customer what something might look like. I don't care at all how well the code works or what it looks like for something like that. Rapid prototyping is a valid use case for that.

I have also written a C++ code that has to have a runtime of years, meaning there can be absolutely no memory leaks or bugs whatsoever, or TV stops working. I wouldn't have a language model write any of that, at least not without testing the hell out of it and making sure it makes sense to myself.

It's not all or nothing here. These things are tools and should be used as such.

Re: The current state of LLM-driven development

#160

Post by thefourthchime »

credit_guy wrote: post #101
tptacek wrote: post #8

Learning how to use LLMs in a coding workflow is trivial. There is no learning curve. You can safely ignore them if they don’t fit your workflows at the moment. I have never heard anybody successfully using LLMs say this before. Most of what I've learned from talking to people about their workflows is counterintuitive and subtle. It's a really weird way to open up an article concluding that LLMs make one a worse prog…

Fully agree. It takes months to learn how to use LLMs properly. There is an initial honeymoon where the LLMs blow your mind out. Then you get some disappointments. But then you start realizing that there are some things that LLMs are good at and some that they are bad at. You start creating a feel for what you can expect them to do. And more importantly, you get into the habit of splitting problems into smaller probl…

I'm glad you feel like you've nailed it. I've been using models to help me code for over two years, and I still feel like I have no idea what I'm doing.

I feel like every time I have a prompt or use a new tool, I'm experimenting with how to make fire for the first time. It's not to say that I'm bad at it. I'm probably better than most people. But knowing how to use this tool is by far the largest challenge, in my opinion.

Post reply on HN