[samstokes]

Most of the comments so far are responding to the first few paragraphs of this article. On reading further, I thought this was actually an unusually balanced take on how to use LLMs in a software org.

I can't help but cringe at the "cost of code is now zero" meme that this article repeats because in my experience the biggest cost of code was always the activities around the code - planning, communicating, reviewing, validating. This author, despite repeating the meme, seems to agree. Their emphasis on writing PR descriptions and specs for humans rhymes with my experience and it sounds like a nicer way to work than chasing some dark factory fever dream.

I also thought the "Two Modes of Working" section was useful. People get wildly different results from coding agents depending on how they use them, but I've not seen a lot of actual guidance on when to do X vs Y.

Personally, I've been using what the author calls "sidekick mode" since last October - before the supposed "AI got good now" threshold - and agree it's a more useful default for an engineer than "delegate mode".

[tayo42]

Writings code has been viewed as an expensive part of development for a while. That's why the coding interview script the industry has adopted requires you to to not write any code until you suffenciently planned the whole problem.

[habinero]

No? You do that to make sure everyone understands and agrees on what to build.

Writing code is the easy part. Figuring out what your new feature or product should do is the hard part.

[tayo42]

Because the assumption is code is expensive to generate. Otherwise why would you put all the upfront effort into all of the planning?Just write some code and iterate on where it goes.

[habinero]

Because you're not just dicking around for funsies? It's fine if nobody uses your shit, but it's not fine if you have actual customers who depend on you.

Maybe this is a paid feature that we're going to charge money for. Or we're going after a new market segment, or trying to take business from a rival. A new feature might have regulatory or legal requirements, somebody needs to understand all that.

At the very least, someone wants this new thing for a reason. You can't just guess, you actually have to talk to people and understand the problem domain lol.

[tayo42]

Your not going to know your classes, parameters, how data should actually be laid out in storage or represented in the application until you start writing anyway. It's always an iterative process.

[habinero]

Kind of, but not really. Those things are hard when you're learning, but they're pretty trivial after some experience.

I almost always have a pretty good idea of what I'm making and how I'm going to make it before I start.

[samstokes]

Code being expensive would be one reason to plan, but hardly the only one. Some other reasons: cost of failure (don't leak customer PII), maintenance, unclear requirements, unclear success criteria.

[pixel_popping]

Developers that can't see from A to Z (all steps ahead) are generally not the ones hired for serious roles (or high paying jobs), that's the difference with iterating on the fly.