Well, not necessarily that far. If you might possibly ever have any sort of personal data even with no intent to actually do anything sketchy with the data, GPDR compliance is a pain.

But still for good reason, you are making yourself a steward of the data which, by any sane measure, should be a responsibility taken very seriously. If you don't like it, good, you have a strong motivator to actually implement the feature at the edge and do everything to avoid ever collecting the information and avoid retaining it even in the edge device.

Problem being that IBM HR and Legal direction is actively bad for business. So it's a little less mundane than usual. Especially IBM legal has a habit of painfully intervening in open source engagement by IBM personnel.

On HR, IBM has been known in the industry for eroding their formerly respectable benefits to substandard. So they expect to apply IBM HR principles to RedHat, and that's going to be terrible for attrition. Don't know anyone that would actively *want* to work for IBM anymore after the changes they've put into place.

And Legal, oh boy. IBM's legal team last I dealt with them were horrific for a company trying to do open source. If any of that remains, expect RedHat to really screw up their bread and butter as they become crippled trying to do anything that involves open source participation one way or another.

If you went the other way, ditching IBM's HR and Legal and letting RedHat call the shots, that would make sense, but I fully trust IBM to do the stupidest way possible.

And that assessment of Red Hat's dead culture and what replaced it... Yeah, that totally brings back memories of my time at IBM.

Indeed, but the ratio of 'boring code' can be pretty low, leading some micromanaging leaders to see lower proportion of LLM generated output from their senior devs and think of them as luddites, no longer able to adapt to 'obviously' better new tech rather than the tech having limited capability in nuanced ways beyond their ability to understand. Some people in my company have taken to generating side slop to pad the metrics so that execs stop asking why the senior devs aren't using enough AI. In the name of it not being totally wasteful, they take on grunt work that they might have formerly offloaded to interns so that LLM can actually generate some viable code that can be shown in the actual team output.

I think the training could be difficult to the extent LLM burns away typical straightforward well trodden new guy fodder, and we do have this to an extent in other fields like math. You could teach a kid right out the gate here's a calculator, don't worry about the details, that's offloaded. Instead we go through this phase that seems like nonsense to the kids, do it by hand without a calculator. Then after enough has happened to prove their worth, they are allowed ancient levels of calculator while they manually do the things more modern calculators can do. Until at some point, the education no longer cares what tool you use for the things the tool can do. So some sort of nonsensical "ignore the helpful tech" seems to be the ticket. Challenge being that traditionally the workplace is where a huge amount of software development is learned, and companies aren't too big on educational style "limit your resources to do the task".

But broadly speaking it's felt like throughout my entire career Gartner has said various things with all the accuracy of coin flipping. I'm shocked that business people have kept citing them time and time again like some grand Oracle as they keep flubbing the details with little or no particular insight than anyone else.

Yes, but it's got a more decent chance at a viable result for entry level than advanced. At all levels you have to audit, just the relative likelihood that it will screw up and the amount of correction needed varies. If you ask it to make a function to initialize a set of variables from argv, it'll do that fine and quick, but sometimes screw up a variable or omit something and just need a little amendment.

So when Altman sees two sorts of outcomes, young entry level people that can see significant gains by having an LLM crank out something and auditing, and an advanced career person that is barely helped if at all by LLM, he concludes that the person is screwing up not that the LLM is limited.

Of course, that can be hard with an irrational market inflating everything into fly-by-night territory

Suppose the question remains, what is *different* compared to the previous experiments of similar design, or is it just a matter of "yeah, it's the same experiments, just trying to get a larger sample size"?

The person recognized this is a test of the crew, not the tech, but just wondering why since we've experimented with crew before.

In a lot of places, the only career ladder is to leave tech behind by 45 to 50 and become management.

Those who cling to tech get stuck with stagnant compensation because they are organizationally considered a dead end.

So at least some of the older half of that age range are out of 'tech roles' but because they are getting more money for doing stupider stuff.

Of course the ageism is a problem, hiring managers wondering what a loser a 55 year old must be if they haven't started reaping some cushy management position. We actually did hire someone for some tech work who was 50, and it was actually more understandable because they worked landscaping until then and hiring managers were happy to have a rational explanation for why an old guy would be settling for a tech role.

Well, for Gen Z, it's a little more competitive with LLM because they don't have the work experience to be trusted with anything difficult yet, so they get assigned tasks that are more likely LLM fodder.

It's not an advantage really because the more established participants do this as well, use LLM where LLM makes sense. It's just a lower proportion of their assigned responsibilities can be done in an LLM way.

The LLMs are not difficult to use to the extent they work. Altman is trying to market it as the next PC or smartphone revolution, where the young led the way and old fogies that were reluctant to train up were left behind.

LLMs however are more useful for the sorts of thing an inexperienced person can do. Those folks aren't trusted/expected to do the complicated stuff anyway. So while the more advanced people might keep seeing LLM fail most of the time, an entry level person might see it able to do like 75% of the tasks they would be trusted to do.

Another that bit us, foreign tech workers on visas deciding it's better to leave the US in the current climate. We had a couple of new hires that were graduating and still on student visas that let them work decide this wasn't the place for them.

Unfortunately, I've seen the exact opposite. I asked it to do something that *should* have indicated a very well maintained external function call, but it instead emitted an unholy mess of a function. I thought it would have saved me a bit of search to find it, but had to search myself. I have no idea if the function would have worked in this case, as I took one glance and said that not only is it failing to use a third party library for a complex interoperability that needs active maintenance, it looked horribly unreadable as well (which I confess usually the AI suggestions are pretty readable, though usually incorrect, it's at least easy to follow how they are incorrect).

I suspect this is a message intended to those starting out to do something weird rather than accumulated complexity over time.

I have seen some pretty stupid stuff. For example, a development team came to me for help because some operation was slow. Turned out they had written their own file copy routine instead of using the standard library, and they manually copied stuff in and out of a 512 byte buffer. There was no good reason for this, no possible good reason, but for whatever reason they wrote a bespoke function to copy a file from one place to another despite the standard library having that built in. Replacing calls to that with the standard library sped up the operation over a hundred fold.

Now that said, sometimes 'complexity' is invoking "frameworks" too liberally, and trying to use them for things they were never really geared to do. So you have a framework that strives to be a streamlined facility for a GUI wrapped around a SQL database, and that framework is popular so someone declares 'lo, we shall use framework X', except there's no SQL database in the particular scenario and thus it really doesn't make sense and you end up doing all kinds of weird things to circumvent the natural design point of SQL at the core of the given framework. The framework was designed to make exactly one thing easy, and you aren't doing that, yet you still try to use the framework anyway.

Like all sorts of this guidance, everyone can find a way to agree or disagree depending on how they interpret it.

Well, yes, that was the 'doing what it's told', just by the system prompt hopefully more than the enduser prompt (though we have plenty of examples of prompts that supersede the system prompt).

His assessment is right and largely we try to affect that through prompt stuffing, but none of that is "agency", and it's wobbly enough that it's very hard to provide absolute guarantees of anything in any of the prompts being effective under all scenarios.