That's been one of the gravest re-realizations I've noticed watching coworkers trying to pick up "agentic" coding: they often just break down into "just fix it" or "why is this broke". I've noticed that even though supposedly there's training or some sort of work done to make the agent work better with unclear or ambiguous grammar or bad structure, it feels like the quality changes palpably when you talk in clear well-structured English and provide at least a good background on the task. To me all of that feels natural, and I like writing and explaining anyways, but it's seemed like an almost insurmountable obstacle for some I've met (and I'm not even talking ESLs either). I strongly suspect those communication and writing skills will be a major factor in the bifurcation of haves and have nots as software "engineering" as we understand it continues to change.

▲

carsareok an hour ago | parent | next [-]

Yes, I have definitely witnessed this as well.

I think, I hope, this will be fixable to some degree, but at this moment I believe it's best to communicate in Queen's English and try to maintain the level of clarity of thought you expect of them in return.

My pet theory is that actual real conversations they were trained on with bad grammar and spelling are in general relatively starved of proper reasoning. By talking to them in this fashion you activate their lowbrow patterns and while it may not be catastrophic I can't imagine it helps.

▲

throw310822 42 minutes ago | parent [-]

Also, quite simply, the output is a function of the requirements and the context. If you can't communicate clearly what the situation is and what you want, what do you expect the LLM to do, read your mind?

	▲	carsareok 37 minutes ago \| parent [-]
		Oh yes, the part where actual crucial non-derivable information was left out certainly comes into play as well. I suspect many people underestimate the sheer magnitude of implicit cultural and organizational knowledge they and their colleagues carry with them. It's always part of their context in everything they do, so to speak and they expect the "bots" to carry this as well (without giving it to them).

▲

aa-jv an hour ago | parent | prev [-]

Agreed, 100%.

If you cannot formulate a specification, or describe a requirement - or indeed, if you cannot fathom the difference between a spec and a requirement, and why its needed to differentiate these from each other prior to doing a proper design and implementation - then you're going to carry your bad practice into the AI realm and that AI is going to be a force multiplier of your own bad practice. Because you will never know if the specs/reqs/design chosen by the AI are actually appropriate, unless you yourself review those specs/reqs/designs, AND the code produced by the AI to fulfill those specs/reqs/designs...

AI makes the able software developer, more able.

But it also makes the unable software developer, even more unable - with the risk of exceeding the AI-users limits on the Peter Principle scale.. in fact, AI will propel you to the middle of your own Peter Principle dilemma faster than you can type, probably.

Communication and writing skills are essential, with or without AI. But reading skills are even more relevant when dealing with AI. Alas, so few people who choose to use AI, have the temerity to actually do the work - or else they wouldn't be rushing for the AI tool in the first place.

Review, review, review. Always. Read the damn code, no matter who or what wrote it. Make sure it fulfills the specs and requirements its supposed to fulfill - and even more important make sure you, the reviewer, also understand the specs and requirements.

And if you don't, fix that - don't ship it anyway, ffs!