Hacker News Reader

Comment by Arubis | Hacker News Reader

Yes, and: the most important time to use your brain isn't in the loop.

That _is_ valuable, and will remain so, but the temptation to turn it off is there because the loop is good and getting better at what it does. Once you're in the loop, with the rare high-value exception of catching total mistakes nad redirecting, you're mostly choosing between similar-yet-reasonable options. This isn't so much right-vs-wrong as relativistic optimization. Letting the loop do the work will get you a mediocre result quickly, and that's usually fine.

The most important time to use your brain is _before the prompt_. Once you engage with your LLM and agent, you start biasing yourself, and its reasonable suggestions constrain your visibility into other options, other worlds.

First, use your brain. Then write the prompt.

View on HN

I don't agree. I'm recently a huge believer in Programming as Theory Building. The software creation itself is the part that makes you understand what you are building. It's impossible to understand things before you start building them, initial prompt can help you explore, but the idea that after that you can lean back is ridiculous. Most or maybe even all successful software projects are still heavily relying on the best software engineers. That's why anthropic and others are still hiring SDEs.

That's great, but you and your family will go hungry as a result. If not this year, next year.

Your stance isn't new, if it's any comfort. I heard (and probably said) exactly the same thing when C compilers started getting good enough to eliminate the need for most assembly coding.

I will take my chances. Software is part of my identity and I won't abandon it that quickly.

Mine, too. Now I can create a lot more software, just as I did when assemblers gave way to compilers.

The idea that this is a bad thing is just bizarre. In technology, what's anomalous isn't change, but things staying the same for 50 years, the way they have in the software business. K&R circa 1972, if transported forward in time, would instantly recognize my workflow today as being essentially the same as theirs. That's what's fucked up. It's good that something genuinely new and interesting is happening at last.

So it is your opinion that in the future llms will take extremely vague specs and turn them into fully functional software that actually works the way the prompter wanted it to?

Does the prompter sit there with the llm all day answering the 1000s of questions necessary to make what he wanted, and the prompter then spent days testing it to make sure what he initially thought he wanted is actually what he wanted?

Then for every additional feature and integration the prompter will do this again?

Are we going to make a new job title for that? Should we call that job a programmer?

Tools are tools. Better tools let us do more faster, but they are still tools.

Are we going to make a new job title for that? Should we call that job a programmer?

Works for me! The most popular programming languages in 2030 will be English and Mandarin. You don't have to like it, you just have to deal with it.

Understanding assembly coding makes you a vastly better C coder.

Nah, not really. Not anymore. Nice skill to have when debugging weird stuff, but nothing you can't get by without.

In broad strokes, I agree. You still have to make decisions and apply taste. It's _extremely_ unlikely that you'll have the full spec and shape and architecture of something large fully settled in your head before you start.

It's also unlikely that you're going to make those realizations, expressions, and decisions when your harness is asking you to choose between what _it_ identifies as being important decisions. If you're in the loop you're getting dumped on with lots of stuff that barely differentiates and you're biased away from catching things that matter.

If you're in the loop, use the loop. It's not a terrible construct. It will give you a mediocre outcome. And if mediocre is sufficient, you're done.

And here's the part that didn't make it into my prior comment -- if mediocre isn't sufficient, _stop the loop_. Play with what you've got. See how it behaves. Explore the edge cases yourself. Sketch how it works on paper, and how you want it to work, and think about how that should be constructed. Use your brain.

Then write a really long prompt (maybe referencing your files and notes and assets) to get back into the loop again.

I guess what I'm ultimately getting at is that the loop is useful _and_ a mind-killer, and using your mind is _also_ high value, so do both those things, but don't do them at the same time.

There are certain parts of my job that can be mediocre and I'm happy to offload them to models. Those are, however, not the parts that count.

Good designs tend to have simple mental models. Some of these mental models are generic and apply across many projects. Or are even written into standards. I wouldn’t be too dogmatic about impossibility of understanding before building. Sometimes knowledge beats experience, and having an intuition for when can save a lot of time.

I somewhat agree with your point, but also I find that the major agent harnesses work really hard at tricking you into leaning back and not letting a proper understanding of what you are building to develop.

This isn't a new problem. I had it when working with outsource developers, too. In both cases, it seemed that just sitting back and describing what I wanted in plain English prevented me from properly wrapping my head around the problem. Which then meant I failed to develop the insight needed to find the really good improvements. Those usually consisted of identifying and removing the bits that were making things worse.[1] It's incredibly difficult for me to think of anything other than just adding more stuff on top of what's already there if I'm not getting my own hands dirty.

So I've been moving away from plan mode and letting the spin away on building large chunks, and back toward working in small increments and typing out the important code with my own hands. That seems to be the sweet spot. I'm still getting a productivity boost because there's more than enough boilerplate and trivial function definitions to farm out. (Easy prompt, too: "Implement `someFunctionStub`.") But I'm also not letting Plan Mode drag me back into the waterfall development pit of insanity.

1: https://en.wikipedia.org/wiki/No_Silver_Bullet

That temptation is akin to giving in to maladaptive (day)dreaming. The problem is the dreaming, the noticing, the getting annoyed, and the feeling drained - all of these are happening at one place - being done by one entity - your brain. So how to train it to not to do that? Well, again, that same brain has to do it. What I am saying here is - our brains are extremely good at getting "used to". Because it "feels good" to the brain - at least in that instant. So any work that's happening on its own, feels good for most people. More the time passed in that "got/getting used to" state unchecked, more difficult it is to try and bring it back to not getting used to. Or control it, in an attempt to strike a fine balance.

Reply on news.ycombinator.com