"You're doing AI wrong" is the new "you're doing agile wrong" which was the new "you're doing XP wrong".
The link in your bio is a long series of tools for various personas with a "schedule a consultation" link next to each one. I'm not sure what "consultation" is if not "a product". But maybe they're all free?
That said, I did not intend to call out your bias as a means of questioning your honesty and I apologize if my communication came across as doing so!
The consequence in this model of not being an early AI adopter is that unless you're a rock star performer already, you're going to fall behind the curve and get ejected from the game of software engineering early. The people who stay in the game until the end will be the ones that have vision now.
If I'm wrong, then all the people who learned AI now will have just wasted a few years on a low value skill, which is honestly the story of the entire history of tech (hello flash devs?), i.e. not an existential threat to engineers.
This is assuming that AI _currently improves productivity_. There's little empirical evidence for this (there is evidence that it causes people to believe that they themselves are more productive, but that's not very useful; _all sorts_ of snake oil cause people to believe that they themselves are more productive).
My baseline assumption right now would be that AI does not, in aggregate, improve productivity (at least in software engineering; it may in some other fields); if it ever _does_, then sure, I'll probably start using it?
AI delivers results when you understand its characteristics and build a workflow around it designed to play to its strengths. AI doesn't deliver huge results when you try to shoehorn it into AI unfriendly workflows. Even if you took the Stanford 95% study on its face (which you shouldn't, there are a lot of methodological issues), there are still 5% of projects that are returning value, and it's not random, it's process differences.
What definition of productivity are you using?
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.
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.
/* 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.*