My favorite is when someone is demoing something that AI can do and they have to feed it some gigantic prompt. At that point, I often ask whether the AI has really made things faster/better or if we've just replaced the old way with an opaque black box.
Until now, it was a code smell if you need those often. There are exceptions to that, but those are a small minority.
Also, design and rationale what humans need is different than what LLMs need. Even what is needed according to humans writing code/documentation and what’s needed for reading is different, that’s why we have that many bad documentation. There are ton of Apache projects whose documentation is rather a burden than helpful. They are long and absolutely useless.
/* This changes the sorting of the original list based on the result, when you use a pipeline <- you have an architectural problem - this happens for example in Splunk */
map()
/* You need to call these in this exact order, one after another <- your architecture is terrible */
processFirst()
processSecond()
processThird()
/* We did this unusual thing because we hate encapsulation <- obvious paraphrase, and lie, you were just lazy, or you didn't have time */
class A {
public static String x
}
In unrelated code: A.x = "something";
/* We merged these two classes because they looked similar, in the code we have a lot of switches and ifs to differentiate between them, we explained them one-by-one <- do I need to explain this? */
Developers who don't document typically do system design beforehand, but that design process often just isn't documented/recorded properly, that's my point. A development environment that records prompt history and lets you use an LLM to query it is a goldmine for auditing and avoiding the pitfalls of Chesterson's fence.
My favorite is when someone is demoing something that AI can do and they have to feed it some gigantic prompt. At that point, I often ask whether the AI has really made things faster/better or if we've just replaced the old way with an opaque black box.
The gigantic prompt has a side benefit though: it's documentation on design and rationale that otherwise would typically not get written.
Until now, it was a code smell if you need those often. There are exceptions to that, but those are a small minority.
Also, design and rationale what humans need is different than what LLMs need. Even what is needed according to humans writing code/documentation and what’s needed for reading is different, that’s why we have that many bad documentation. There are ton of Apache projects whose documentation is rather a burden than helpful. They are long and absolutely useless.
> Until now, it was a code smell if you need those often. There are exceptions to that, but those are a small minority.
Documentation for a system, particularly a rationale, is never a code smell.
> There are ton of Apache projects whose documentation is rather a burden than helpful. They are long and absolutely useless.
LLM prompts are short and to the point by comparison, that's part of my point.
> is never a code smell
/* This changes the sorting of the original list based on the result, when you use a pipeline <- you have an architectural problem - this happens for example in Splunk */
map()
/* You need to call these in this exact order, one after another <- your architecture is terrible */
processFirst()
processSecond()
processThird()
/* We did this unusual thing because we hate encapsulation <- obvious paraphrase, and lie, you were just lazy, or you didn't have time */
class A {
public static String x
}
In unrelated code: A.x = "something";
/* We merged these two classes because they looked similar, in the code we have a lot of switches and ifs to differentiate between them, we explained them one-by-one <- do I need to explain this? */
class TwoCompletelyUnrelatedThingsInOne
> that's part of my point
> The gigantic prompt
It was clearly not.*
Null argument. I'd rather have developers who do system design before the system implementation.
Developers who don't document typically do system design beforehand, but that design process often just isn't documented/recorded properly, that's my point. A development environment that records prompt history and lets you use an LLM to query it is a goldmine for auditing and avoiding the pitfalls of Chesterson's fence.