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

91–100 of 244 posts

Re: The current state of LLM-driven development

#91

Post by mikeshi42 »

donperignon wrote: post #68

LLM’s are basically glorified slot machines. Some people try very hard to come up with techniques or theories about when the slot machine is hot, it’s only an illusion, let me tell you, it’s random and arbitrary, maybe today is your lucky day maybe not. Same with AI, learning the “skill” is as difficult as learning how to google or how to check stackoverflow, trivial. All the rest is luck and how many coins do you ha…

There's plenty of evidence that good prompts (prompt engineering, tuning) can result in better outputs.

Improving LLM output through better inputs is neither an illusion, nor as easy as learning how to google (entire companies are being built around improving llm outputs and measuring that improvement)

Re: The current state of LLM-driven development

#92

Post by softwaredoug »

I find all AI coding goes something like this algorithm

* I let the AI do something

* I find bad bug or horrifying code

* I realize I have it too much slack

* hand code for a while

* go back to narrow prompts

* get lazy, review code a bit less add more complexity

* GOTO 1, hopefully with a better instinct for where/how to trust this model

Then over time you hone your instinct on what to delegate and what to handle yourself. And how deeply to pay attention.

Re: The current state of LLM-driven development

#93

Post by hitarpetar »

simonw wrote: post #48
troupo wrote: post #23

Earlier quoted context omitted.

> 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. Because for all our posturing about being skeptical and data driven we all believe in magic. Those "counterintuitive non-trivial workflows"? They work about as well as just prompting "implement X" with no rules, agents.md, careful lists etc. Becau…

The problem with your argument here is that you're effectively saying that developers (like myself) who put effort into figuring out good workflows for coding with LLMs are deceiving themselves, and are effectively wasting their time. Either I've wasted significant chunks of the past ~3 years of my life or you're missing something here. Up to you to decide which you believe. I agree that it's hard to take solid measu…

That's not a problem, that is the argument. People are bad at measuring their own productivity. Just because you feel more productive with an LLM does not mean you are. We need more studies and less anecdata

Re: The current state of LLM-driven development

#94

Post by simonw »

skydhash wrote: post #56
simonw wrote: post #14

Learning how to use LLMs in a coding workflow is trivial. There is no learning curve. [...] LLMs will always suck at writing code that has not be written millions of times before. As soon as you venture slightly offroad, they falter. That right there is your learning curve! Getting LLMs to write code that's not heavily represented in their training data takes experience and skill and isn't obvious to learn.

If you have a big rock (a software project), there's quite a difference between pushing it uphill (LLM usage) and hauling it up with a winch (traditional tooling and methods). People are claiming that it takes time to build the muscles and train the correct footing to push, while I'm here learning mechanical theory and drawing up levers. If one managed to push the rock for one meter, he comes clamoring, ignoring the…

I'd describe LLM usage as the winch and LLM avoidance as insisting on pushing it up hill without one.

Re: The current state of LLM-driven development

#95

Post by rkomorn »

hitarpetar wrote: post #93
simonw wrote: post #48

Earlier quoted context omitted.

The problem with your argument here is that you're effectively saying that developers (like myself) who put effort into figuring out good workflows for coding with LLMs are deceiving themselves, and are effectively wasting their time. Either I've wasted significant chunks of the past ~3 years of my life or you're missing something here. Up to you to decide which you believe. I agree that it's hard to take solid measu…

That's not a problem, that is the argument. People are bad at measuring their own productivity. Just because you feel more productive with an LLM does not mean you are. We need more studies and less anecdata

The whole debate about LLMs and productivity consistently brings the "don't confuse movement with progress" warning to my mind.

But it was already a warning before LLMs because, as you wrote, people are bad at measuring productivity (among many things).

Re: The current state of LLM-driven development

#96

Post by misja111 »

hiAndrewQuinn wrote: post #77
uvdn7 wrote: post #55

Earlier quoted context omitted.

Is the non-trivial amount of time significantly less than you trying to ramp up yourself? I am still hesitant using AI for solving problems for me. Either it hallucinates and misleads me. Or it does a great job and I worry that my ability of reasoning through complex problems with rigor will degenerate. When my ability of solving complex problems degenerated, patience diminished, attention span destroyed, I will beco…

>Genuine question - are people comfortable with this? It's a question of degree, but in general, yeah. I'm totally comfortable being reliant on other entities to solve complex problems for me. That's how economies work [1]. I neither have nor want to acquire the lifetime of experience I would need to learn how to produce the tea leaves in my tea, or the clean potable water in it, or the mug they are contained within,…

> My dad doesn't need to know how to do algebra to get his taxes done, he just has an accountant.

This is not quite the same thing. The AI is not perfect, it frequently makes mistakes or suboptimal code. As a software engineer, you are responsible for finding and fixing those. This means you have to review and fully understand everything that the AI has written.

Quite a different situation than your dad and his accountant.

Re: The current state of LLM-driven development

#97

Post by simonw »

antonvs wrote: post #63
SadErn wrote: post #29

Earlier quoted context omitted.

This is all just ignorance. We've all worked with LLMs and know that creating an effective workflow is not trivial and it varies based on the tool.

Define "not trivial". Obviously, experience helps, as with any tool. But it's hardly rocket science. It seems to me the biggest barrier is that the person driving the tool needs to be experienced enough to recognize and assist when it runs into issues. But that's little different from any sophisticated tool. It seems to me a lot of the criticism comes from placing completely unrealistic expectations on an LLM. "It's…

As of about three months ago, one of the most important skills in effective LLM coding is coding agent environment design.

If you want to use a tool like Claude Code (or Gemini CLI or Cursor agent mode or Code CLI or Qwen Code) to solve complex problems you need to give them an environment they can operate in where they can solve that problem without causing too much damage if something goes wrong.

You need to think about sandboxing, and what tools to expose to them, and what secrets (if any) they should have access to, and how to control the risk of prompt injection if they might be exposed to potentially malicious sources of tokens.

The other week I wanted to experiment with some optimizations of configurations on my Fly.io hosted containers. I used Claude Code for this by:

- Creating a new Fly organization which I called Scratchpad

- Assigning that a spending limit (in case my coding agent went rogue or made dumb expensive mistakes)

- Creating a Fly API token that could only manipulate that organization - so I could be sure my coding agent couldn't touch any of my production deployments

- Putting together some examples of how to use the Fly CLI tool to deploy an app with a configuration change - just enough information that Claude Code could start running its own deploys

- Running Claude Code such that it had access to the relevant Fly command authenticated with my new Scratchpad API token

With all of the above in place I could run Claude in --dangerously-skip-permissions mode and know that the absolute worse that could happen is it might burn through the spending limit I had set.

This took a while to figure out! But now... any time I want to experiment with new Fly configuration patterns I can outsource much of that work safely to Claude.

Re: The current state of LLM-driven development

#98

Post by johnisgood »

misja111 wrote: post #96
hiAndrewQuinn wrote: post #77

Earlier quoted context omitted.

>Genuine question - are people comfortable with this? It's a question of degree, but in general, yeah. I'm totally comfortable being reliant on other entities to solve complex problems for me. That's how economies work [1]. I neither have nor want to acquire the lifetime of experience I would need to learn how to produce the tea leaves in my tea, or the clean potable water in it, or the mug they are contained within,…

> My dad doesn't need to know how to do algebra to get his taxes done, he just has an accountant. This is not quite the same thing. The AI is not perfect, it frequently makes mistakes or suboptimal code. As a software engineer, you are responsible for finding and fixing those. This means you have to review and fully understand everything that the AI has written. Quite a different situation than your dad and his accou…

> This means you have to review and fully understand everything that the AI has written.

Yes, and people who care and is knowledgeable do this already. I do this, for one.

Re: The current state of LLM-driven development

#99

Post by simonw »

donperignon wrote: post #68

LLM’s are basically glorified slot machines. Some people try very hard to come up with techniques or theories about when the slot machine is hot, it’s only an illusion, let me tell you, it’s random and arbitrary, maybe today is your lucky day maybe not. Same with AI, learning the “skill” is as difficult as learning how to google or how to check stackoverflow, trivial. All the rest is luck and how many coins do you ha…

Learning how to Google is not trivial.

Re: The current state of LLM-driven development

#100

Post by simonw »

Palmik wrote: post #81

People that comment on and get defensive about this bit: > 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. How much of your workflow or intuition from 6 months ago is still relevant today? How long would it take to learn the relevant bits today? Keep in mind that Claude Code was released less than 6 months…

Pretty much all of the intuition I've picked up about getting good results from LLMs has stayed relevant.

If I was starting from fresh today I expect it would take me months of experimentation to get back to where I am now.

Working thoughtfully with LLMs has also helped me avoid a lot of the junk tips ("Always start with 'you are the greatest world expert in X', offer to tip it, ...") that are floating around out there.

Post reply on HN