Hacker News Reader

Comment by tptacek | Hacker News Reader

This logic doesn't even cohere. Thinking is a significant part of software delivery. So is getting actual code to work.

ideally there is an order of magnitude difference between, and the latter is trivially delegable (where the former is not)

No there isn't.

This harkens back to the waterfall vs agile debates. Ideally there would be a plan of all of the architecture with all the pitfalls found out before any code is laid out.

In practice this can’t happen because 30 minutes into coding you will find something that nobody thought about.

In the micro, sure. In the macro, if you are finding architecture problems after 30 minutes, then I’m afraid you aren’t really doing architecture planning up front.

Depends on what you're building. If it's another crud app sure, but if its something remotely novel you just can't understand the landscape without walking through it at least once.

> if its something remotely novel you just can't understand the landscape without walking through it at least once

Sure you can. Mapping out the unknowns (and then having a plan to make each one knowable) is the single most important function of whoever you have designing your architecture.

Up-front architecture isn't about some all-knowing deity proclaiming the perfect architecture from on high. It's an exercise in risk management, just like any other engineering task.

>Mapping out the unknowns

and

> isn't about some all-knowing deity

Seems like a big conflict of your own thoughts.

Or as they say....

> there are known knowns; there are things we know we know. We also know there are known unknowns; that is to say we know there are some things we do not know. But there are also unknown unknowns—the ones we don't know we don't know.

> But there are also unknown unknowns—the ones we don't know we don't know.

And pretty much your job as an engineer is to mitigate the risk that poses.

We don't build new architectures in a vacuum. We build on what has worked before in similar situations, and we adapt it to the problem at hand.

That adaptation is an ongoing process - but it's not the same as saying "fuck it, let's vibe-code our architecture"

Oftentimes, micro pitfalls are ill omens that some bigger issue is afoot.

if you're spending anywhere near as many engineering hours "getting code to work" as you're spending "thinking" then something is wrong in your process

Take that up with the author of this article!

Maybe you're right both of you, but you're thinking about two pretty different software projects and domains :-)

Which part of the third chart do you disagree with?

Here we're really arguing about his first chart, which I agree with, and you do not.

I’m not following. It seems straightforward enough, and consistent with both charts, that a dramatic speedup in coding yields a more modest improvement in overall productivity because typing code is a minority of the work. Is your contention here that the LLM not only documents, but accelerates the thinking part too?

It does, for sure, and I said that in my comment, but no, the point I'm making is that this article isn't premised on thinking being an order of magnitude more work than coding. See: first chart in article.

Reply on news.ycombinator.com