I've actually outsourced the first iteration of that to AI. :-)

At the end of coding sessions, I generall ask it to spin up an adversial agent whose task it is to find flaws, inconsistencies, mistakes, bugs, etc.

I'd still strongly recommend to anyone shipping AI-generated code to have a thorough human code review, but for a first pass at surface level, the AI can check itself if it has some kind of separation between the generator and the reviewer.

Personally, after some experimenting, I've concluded that:

• AI is good at implementing known algorithms.
• AI is good in creating code that flows straightforward from a design document.
• AI is good at code reviews and finding bugs.
• AI (unlike me) doesn't mind writing a few hundred tests.
• But, it tends to over-engineering simple tasks to the point of "why does Hello World need enterprise-software levels of abstraction?"
• It struggles with code that doesn't have a known solution.
• It's difficult to get it into a different lane once it started going down the wrong way.

What I use it for these days is rapid prototyping. Using AI I can make a functioning prototype of an idea I have in a few days instead of a few weeks. I can quickly test out an idea for a feature or change in my existing codebase.

What I also have been using it for a while is as a code-reviewer and for someone like me who is mostly working solo, that's an insanely valuable thing. Not just the bugs themselves, but also the ability to discuss code with someone. Basically, AI is a rubber ducky that replies.

Mickeysoft lost the plot again.

The game-changing element of LLMs and agents is that they have a non-computer-language interface - you can talk to them in plain English (or Chinese or whatever). This makes complex computer interactions available to a much wider audience than any previous computing invention. Adapting humans to the AI is getting that backwards. It's a sign you don't understand the first thing about why AI is so widely successful.

I predict this will be an abject failure and a year from now will quietly be pushed to the very back of the bottom-most drawer, never to be spoken off again (though it is getting crowded in there for M$).

Meanwhile, in the real world, everyone I've talked to about these things already has a skills file to teach the AI about their personal coding style. This is what actual humans came up with, independently several times, and it works: Adapt the AI to you. Plus we've been writing coding style guides for humans for a long time now, we've got plenty of experience doing that at least somewhat right.

SystemD isn't a monolithic application. It's a collection of utilities that all share the SystemD banner. You can pick and choose what bits of the SystemD utility set you wish to use. It is entirely possible to not use the init portion but use the system logging daemon, for example. Or other bits and pieces.

In fact, there's no distribution out there that uses everything SystemD has to offer. Most use a majority of the components, but there's often a few that are not used. systemd-networkd versus Network Manager versus interfaces, for example to manage network interfaces.

I think there was also talk of SystemD trying to replace dbus as well, but not getting any traction on that.

Heck, I think there was one now-deprecated component of KDE that was dependent on one SystemD utility that was Linux-specific. It got dropped over a more generic version that used more portable components.

When I was in university, homework was at most 10% of your grade. The midterm exam was often worth 45%, and the final the other 45%. Often with the stipulation that you must pass the final to pass the course.

I had classes where homework was assigned but not graded. It was obvious who did the homework and who didn't - you just didn't do very well on the final or midterm if you didn't do the optional homework.

Everyone's an adult. You don't do the assigned homework at your own risk, even if it isn't graded. Midterms and final exam correspond to the biggest influence on your grade.

Heck, sometimes the midterm mark can be dropped as well - I've had plenty of professors simply say because we scored badly on the midterms, they'll use the final exam mark if we do better. So if you scored a 30% on the midterm but then get an 80% on the exam, you get an 80% on the class.

Stop the coddling and just treat everyone as an adult. Assign homework, but don't mark it. You can ask if people had a problem they got stuck on so they could work it out as part of the lecture, but not part of the grade. The final grade you get depends solely on the midterm and/or the final exam.

(I got a D on a class where I didn't do the homework. The second semester the followup course I did the homework and got an A-)

That would have been really useful for some mag tape systems I used to use. They had too many errors for their error correction system.

You should do it for backup systems. It's why PAR2 exists. You run it over your data and it creates the Reed-Solomon parity files. Each file contains a checksum of every file in the set, and you need only enough parity file to fix the corruption. E.g., if you have a 1MB block that's corrupted, you just need a 1MB parity file. The files often come in varying sizes so you just use as much as you need.

There's lots of programs able to handle the PAR2 format and it's been around for decades.

RS codes are awesome in that you only need parity enough to cover the damage - you can generate parity files all the way up to 100% - which in theory if they only thing that survives are parity files, you can reconstitute the original files still.

If half the data is corrupted, and half of the 100% parity is corrupted, the remaining 50% of each is enough to rebuild

But even Trillion dollar companies like Meta essentially freeload off the likes of Php where a contribution in the low millions or tens of millions works help bend development to their liking,

Even less: clearly most of these companies don't particularly want to influence the directions (they could hire the devs if they really wanted to). They're jut content to use them. If they chucked, say, 10 grand a year at a handful of projects, the problem would be solved.

But I guess companies are now meeting their doing good quota

It's not even doing good, it ought to be pure, bloody minded self interest. The cost of things like the PHP exploit, heartbleed and so on are absolutely immense. Investing a small amount in the future i jut good business. Trouble it it needs everyone to do it to make it so cheap they don't notice.

I suppose the main thing I'd have said very differently is the terminology, in that I wouldn't regard the kind of incompetent senior as a senior in the first place

The best phrase I heard (I think here) was "10 years experience or 1 year experience repeated 10 times".

But then I'm pretty old school about this: to me, a junior developer needs quite close supervision to produce useful results, a regular/mid developer can perform routine tasks with minimal supervision but might need more help with larger or more complex tasks, while a senior is someone you can give more or less any task on your project to and they'll figure it out, and senior is also the level of someone who would be capable of supervising and training a junior.

Ostensibly yes. The juniors I'm thinking of certainly do need close supervision, though I don't think Claude replaces them because the good one use claude.

What I've noticed is there are a lot of jut plain crap mid level and senior people (for some value of senior). They can do more or less what you say, except they're still crap. The results will be overengineered piles of crap where they've decided to use the latest "technologies" which are really due to curiosity not some actual need. And the whole thing comes with an attitude problem too.

We've had a wave of people, particularly since the tech boom during COVID, who have obviously been over-promoted due to the employee's market and title inflation.

This is true, but my big corporate job spanned COVID, and I can assure you that the problem existed before COVID. Some of the refugees (haha they were in for a shock) from other big corporate shitshows had much the same to say.

Even that somewhat inflated sum is pocket change for just one of the many major corporations which rely on PHP.

I challenge you (well obviously this is impossible but you get the rhetorical point) to find one corporation in the entire world valued at over a billion that doesn't, say, use openssh. The OpenBSD foundation struggles to raise CAD 400,000 a year.

Sure they are legally allowed to be freeloaders. The point of the license is anyone can use it. It's really stupid however to contribute absolutely nothing when it's critical infrastructure you rely on day to day and you could easily afford a sponsorship. But it's the tragedy of the commons.

For a junior developer, I'd say frontier models passed their standard some time ago.

No, I disagree, and now that I'm thinking about it more, quite strongly. I think frontier models passed the mediocre programmers of all seniority levels some time ago. I've worked with so many arrogant pillocks who are convinced they are the shit and will not listen to someone with domain expertise and then get pissy when they turn out to be wrong. Or worse, get political and push through an objectively broken thing.

Good juniors can drive AI really well and do good stuff. I had a summer intern the summer just gone. 2 month placement in the middle of an engineering degree. Basically gave him a problem I didn't have time to work on: you know "here's the current solution, here's what I know, this is the problem, go nuts" kind of deal. Obviously there were regular feedback sessions, but he did all the work, and used AI heavily but not religiously. And that's now part of the product. He was obviously very very junior, but I've had seniors who were less capable and flexible.

The frontier models are hit-and-miss when it comes to writing good test suites,

I've also found the mediocre are very much monkey-see-monkey do kind of programmers who write tests because those are Bet Practices and they are the Best. But they also as I say convinced they are the shit and don't appear to actually believe their code need testing really. CI is there to put the halt on all the fools they are surrounded with, not them of course, but they know they need to model Best Practices for the unwashed.

End result, a lot of programmers are shockingly bad at writing tests and basically test useless things that are easy to test and unlikely to break but don't do what's actually hard but important. This appears to be what Claude has been trained on: basically the average, on average and it tends to write long batteries of more or less meaningless tests.

Naturally good juniors aren't very good at tests initially. They're juniors, but I find it's the attitude that matter. It's not hard to convince them they might be wrong and that there's a need for testing. Or "prove to me Claude hasn't messed it up", kind of thing. I'd much rather work with an enthusiastic junior who wants to prove me, Claude or themselves wrong than a senior programmer who I have to beg to consider the notion that their code might not be perfect.

TL;DR I broadly agree, but I think Claude makes the competent/incompetent split starker, not the junior/senior split.

Currently, based on objective data comparing similar fully completed development tasks like for like, I still outperform agentic workflows using frontier models by about 25-50% on average, and I don't have to pay anyone extra fees to do that, and subjectively I also find it more engaging to work that way. So I don't really buy the hype about AIs making us all orders of magnitude more productive unless you're happy to YOLO everything forever and take the much-discussed risks that comes with.

Yes, though as you say quite a lot of stuff can be YOLO'd.

It's amazingly good at some stuff and not at others.

It can bash out a CRUD app with a web based UI in basically no time, and really well. Think some boring internal tool like inventory management or something. Would cost a fortune to buy and also suck massively. It would from a project perspective count as long and complex, but from a pure software point of view, it's not complicated stuff. It's well documented. It's also a horrible tech stack.

It's also very good at indexing an unseen codebase and figuring out entry points for things. I've known people, or rather a person, that good, but I ain't.

But I've also seen it make a complete shitshow of threading in a small, contained task. It's also so-so if that at optimization. I set it on making thing go faster. I had the dataset, and specified tests. It found the hotspot and made it faster, which is frankly more than a lot of programmers can do. Most of them will smugly tell you everyone knows e.g. std::unordered_map is slow (and you're implicitly a moron for using it), change everything to their own implementation on a Friday night then bugger off. So yeah better than that, but I let it churn for ages with its agents and it didn't get much further. So I put some easy wins in by hand.

It is quite often wrong and i definitely worse in areas requiring domain expertise. But then again that's the case with your average programmer. It's also a bit weirdly pissy at time, but much less so that many programmers, so that's a net win. It won't flounce off if you tell it to delete a bunch of code it just wrote.

So...

Yeah I use it and quite a lot.

This isn't wrong. One of my devs is on a bit of a side quest to see how far he an get with Qwen locally (5070Ti) compared to Claude. He was basically trying to answer the GP's question. Resort so far: it's not as good as the latest frontier model feels like 4.6 instead which is pretty solid. Main thing is it's got a pretty small context, but that's due to the 16GB size of the GPU not the model per-se.

There are 640 acres in a square mile

[Sighs in metric]

Microsoft has probably the most illustrious history of bugs where just visiting a website or opening an email can get your system hacked, but you're right, this is not a problem unique to them.

These days, Lookout asks you before it loads any images from outside your organization...

The proper response to being in an area where datacentres are crowding in is "lobby your elected officials to increase property taxes and not give out tax increment financing deals". Tax everything, and tax it well. They'll stop building new datacentres in your area, and the ones that are there will (unless they were given a long-term sweetheart deal beyond your already-low tax rates) start being cash cows for your area.