[valicord]

I agree with your first paragraph but not the second one. In many cases it's easier for me to directly write the code that satisfies the unwritten acceptance criteria I have in my head than to write those criteria down in English, have an LLM turn them into code, and then have to carefully review that code to see if I forgot some detail that changes everything.

[Terretta]

> easier for me to directly write the code that satisfies the unwritten acceptance criteria I have in my head than to write those criteria down in English

Yes, and for team or company code, "there's the problem".

Those acceptance criteria are guardrails for the change that comes after, and getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.

Virtually all teams — because virtually all PgMs, PjMs, TLs, and Devs — miscalculate this.

Easier for you, not better for team or firm.

• • •

FWIW, perpetuation of this problem isn't really a fault of culture or skill or education. It's largely thanks to "leadership" having no idea how to correctly incentivize what the outcome should holistically be, as they don't know enough to know what long-haul good looks like.

FWIW, you can make that easier for them by having the LLM derive your acceptance criteria into English (based not only on code but on your entire conversation+iteration history) and write that up, which you can read and correct, after the countless little iterations you made since your head-spec wasn't as concrete as you imagined before you started iterating.

Even if you refuse to do spec driven development, LLMs can do development-driven spec. You can review that, you must correct it, and then ... Change can come after more easily — thanks to that context.

[valicord]

> Those acceptance criteria are guardrails for the change that comes after, and getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.

I have a lot of context about the system/codebase inside my head. 99.9% of it is not relevant to the specific task I need to do this week. The 0.1% that is relevant to this task is not relevant to other tasks that I or my teammates will need to do next week.

You're suggesting that I write down this particular 0.1% in some markdown file so that LLM can write the code for me, instead of writing the code myself (which would have been faster). Chances are, nobody is going to touch that particular piece of code again for a long time. By the time they do, whatever I have written down is likely out of date, so the long term benefit of writing everything down disappears.

> after the countless little iterations you made since your head-spec wasn't as concrete as you imagined before you started iterating.

That's exactly the point. If I need to iterate on the spec anyway, why would I use an intermediary (LLM) instead of just writing the code myself?

[theshrike79]

You also write it down so that the bus factor goes down.

And if nobody touches the code for a long time, how can the documentation be out of date?

[godelski]

  > getting those out of your head into English is more important over the long haul than your undocumented short-term solution to the criteria.

I think there may be miscommunication going on, or I may be misreading the conversation. What I do not know is what valicord means by "satisfies the unwritten acceptance criteria".

In one interpretation, I think they make a ton of sense. We invented formal languages to solve precisely this problem. The precision and pedantic nature of formal languages (like math and code[0]) is to solve ambiguity. If this is the meaning, then yes, code is far more concise and clear[1] than a natural language. That's why we invented formal languages after all. So they may be having trouble converting it to English because they are unsatisfied with the (lack of) precision and verbosity. That when they are more concise that people are interpreting it incorrectly, which is only natural. Natural languages' advantage is their flexibility, but that's their greatest disadvantage too. Everything is overloaded.

But on the other hand, if they are saying that they are unable to communicate the basics (it seems you have read in this way) then I agree with you. Being able to communicate your work is extremely important. I am unsure if it is more important than ever, but it is certainly a critical skill. But then we still have the ambiguous question of "to who?" The type of writing one does significantly differs depending on the audience.

Only valicord can tell us[edit], but I think we're just experiencing the ambiguity that makes natural languages so great and so terrible. I think maybe more important than getting the words out of ones head is to recognize the ambiguity in our language. As programmers this should be apparent, as we often communicate in extremely precise languages. But why I'd say it is more important than ever is because the audience is more diverse than ever. I'd wager a large number of arguments on the internet occur simply due to how we interpret one another's words. The obvious interpretation for one is different for another.

[0] Obviously there's a spectrum with code. C is certainly more formal than Python and thus less ambiguous.

[1] Clear != easy to understand. Or at least not easy to understand by everyone. This is a skill that needs training.

[edit] Reading their response, I think it is the first interpretation.

[jghn]

This is the point I'm raising. I agree with you, but what I'm saying is I think the skillset you describe is the next on the chopping block.

The acquaintances of mine who are absolutely *killing* it with these tools are very experienced, technically minded, product managers. They have an intimate knowledge of how to develop business requirements and how to convert them into high level technical specifications. They have enough technical knowledge to understand when someone is bullshitting them, and what the search space for the problem should be. Historically these people would lead teams of engineers to develop for them, and now they're sitting down and having LLMs crank out what they want in an afternoon. They no longer need engineers at all.

My contention is that people with that sort of skillset will have an advantage due to their experience with skills like finding product fit, identifying user needs, and defining business requirements.

Of course, the people I'm talking about were already killing it in the old paradigm too. I'll admit it's a bit of a unicorn skillset I'm describing.