"Product" studies this data and tells engineers what features they want. I am rarely instructed to A/B anything...excepting when it's defensive, to ensure the first rule of "don't interrupt the flow of money" is upheld, if at all. Most of the features are obvious improvements anyway (determined from plain conceptual planning, manual testing, and personal usage).

ofc I don't understand the customer or market or anything else. I'm paid with the expectation that I'm not going to share an opinion about it, especially since am never exposed to the raw data and inner circle decisioning except during a quarterly meeting...maybe. This is part of why AI is so successful. Humans in large organizations are specialized with little creative input and lots of mechanical process. Coding is largely a mechanical black box (turing machine) from the outside looking in. It works seamlessly because I don't need to know about the things product wants, so the AI doesn't know and everyone carries on faster than we were before.

The hyperbole feels like it's been contrived to fit into the classic AI counterpoint: But humans do this too!

The parent comment is interesting, but ultimately I think in this case, the AI is actually revealing something about the true nature about their place of employment, a nature that has always been there versus some mutation caused by the prevalence of the AI itself.

A lot of money can be made purely algorithmically. Think market markers or other algorithmic trading. The ought vs is divide is quite narrow here. It's not a moral question, the "value" is in the money to be made. It's actually not a great example to invoke Hume's problem. Many companies essentially are chasing a similar spread, its just less obvious. Few people ever ask what "ought" to exist. If the power of AI makes more businesses operate more reactively and algorithmically, because of more data or processing power or w/e that really is probably in keeping with their alignment and goals. Because the ultimate ought for a company is we ought to be making more money. So, in many ways the ought is really not that interesting, the is is satisfactory provided the return on whatever their version of a spread is keeps improving.

The number of companies that actually "invent" useful things and thus ask even vaguely meaningful "ought" questions are extremely slim. The vast majority of employees are, at best, accessories to these questions, even in software where even before AI many of us were not doing very interesting work. There is a lot of essentially rebuilding your competitors same layers on top of common libraries and standards where the actual interesting work is done. Really not unlike asking AI to cook you up a boilerplate by leveraging the vast work of a fraction of SWEs who maintain OSS tools. It's the same pattern and the same sort of behavior, just now your "layering" is becoming automated to the point of irrelevance.

What the parent misses - the real promise of AI is paradoxically, that it will allow more people to ask actually interesting ought questions as AI owns more of the spreads. In the same way a human does not compete with an algorithmic trader, and at some level, really doesn't care. The more algorithmic your business becomes, the less any individual human "value judgement" matters. And really this is desirable, because again, most companies are not asking interesting value questions anyway. The end state of this you are missing is these companies are going to cease to exist. In the optimistic case this will free you up to ask more interesting value questions - like how do I value all my UBI enabled free time. In the less optimistic case your value judgments will be more dire - like who do I sacrifice given the Terminators are at the door and we only have x quantity of supplies left.

This is the other paradox. When questions of what ought to happen are of paramount importance, you are probably finding yourself in a very undesirable situation. It's easy to valorize the ought problem from a distance, it is much much harder to actually engage with it when it actually matters. In many ways, the relative luxuries of society and civilization are derived from taking such questions out of most of our hands. This is (perhaps surprisingly) true even as you climb the ladder of power:

I used to think that if there was reincarnation, I wanted to come back as the President or the Pope or as a .400 baseball hitter. But now I would like to come back as the bond market.

And the complement is credit/provenance laundering. These are things being misappropriated.

The grift often does both of these with the same sleight of hand, and this is what gets accelerated with the new tools and cavalier culture around everything.

Folks break everything all the time and looking at their PRs and messages are clearly just having the AI respond to everything for them and actually have no idea what they're doing.

And then other people doing the same thing approve their work (presumably not reading or understanding any of it) because then the other person will do the same for theirs.

Hopefully my experience is an anomaly though :)

Everyone can write code these days. Trouble is, all code has to be SIL-4 code now, because, human, you will never know if your compiler trusts your AI until you trust your compiler. This rule will be true for decades into the future, I'm willing to wager...

But, ultimately, software has to follow certain rules, or it just doesn't work. Proper workflows - involving review - are needed. Because security is pretty much over, otherwise.

Folks are finding it easier to make their own software now, too - rather than use others. I predict an end to the app stores - or at least, the primary interface is going to end up being "describe the app you want to use today" instead of picking words from a list ..

Just to make this clear: if you can define a really good PRD and sophisticated technical specs, and a strong set of tests cases to pass, at the right level of architectural granularity, plus adversarial code review processes that triangulate and weed out most mistakes, SOTA agents can write the code autonomously, at or above the quality level of most human coding teams. I call that "solved" but only if you meet those context requirements. Which is still hard, not solved, at that layer.

Solving writing is not a good analogy IMO. Writing is for human consumption, and cannot be wrapped in objective requirements and verification processes. Certain forms of writing perhaps could be (can't think of one at the moment but I don't doubt some exist), and those forms might be good analogies for being "solvable" or "solved."

Saying that LLMs have "reduced the cost of coding" would be boring. And using your analogy, pencils, typewriters and computers have all reduced the cost of writing, but writers are still around.

At least that's how I experience it. In the before times each non-trivial code change had a real opportunity cost as it would easily consume two days until I could even estimate whether this is worth looking deeper into.

I think "solved coding" is taking it too far, but for many projects, the mechanical aspect of it has been removed or reduced greatly.

LLMs will have a much harder time "solving writing", because they cannot develop their own style and so are severely limited, creatively. This is less important for coding.

Today, human-language outlines / briefs / prompts are “compiled” to code which is itself then adapted to hardware. We are stretching less and less across the divide, doing less and less work on the terms of the machine. Now the farthest we’ll stretch is often formatted markdown - the most basic application of machine-parseable structure to very organic human thinking. Because we’re given the chance to be less precise, coherence suffers.

This time I add another definition "when you can own it".

To your point, it's not the wrong abstraction for solving code level bugs. Just like python is not the right abstraction for solving memory corruption or pointer mis-alignments.