I'm not really qualified to deliver a good holy war; but it does seem like there may be something to the criticism that monolithic integration has gone a bit far if supporting one utility being written in a different language is a special feature rather than a matter of the rest of the system not knowing or caring what is on the opposite side of an interface so long as it can act as expected.

You can't really beat the fundamental economics of software development: expensive to do right but cheap to copy means that you really, really, want to share a problem with as many other people as possible(unless your whole business is being uniquely good at solving whatever the problem is; but that typically isn't the case for this sort of software). Applies to both proprietary and FOSS: relatively mass-market software is often pretty cheap for what you get; really oddball niche stuff is frequently both pricey and terrible; while your life is going to get steadily more miserable if you are personally responsible for handling backports and fixes for some internal fork of a long-EOL version of an OSS package.

The big difference, at least potentially, is that, while it tends not to be economic to DIY, licenses that give you the right to DIY also give you the right to pay someone else to do it for you; or to form a coalition of people with similar problems and have everyone pitch in to pay someone to do it for you. You still need to either eat the cost of maintaining an internal fork or putting together some sort of coalition of people with similar problems to be the openJDK 8 forever pals and share the cost of maintenance; but the vendor can't just stop selling you licenses if they want you to move to their cloud offering or whatnot.

I don't.

The creator of the pi harness did say that the claude system prompt changes often enough that he had to build his own tooling to try and improve reliability and repeatability.

I'm not convinced the differences in roles I've observed are claude personality differences as much as humans giving different prompts.

The individual users: perfectly well know they do not have permission to use the system after being suspended or fired.
Regardless auf any fault by the "login process": they are criminals. Just like any criminal who hops into your car with running engine and the key in the lock.

Perfectly right.

Talk to the AI tool like you would talk to an experienced programmer: on business level specc.

Most of the time, you do not even have to reiterate and fix errors.

Perhaps you should try it, before giving utterly uneducated shit comments.

Why aren't we genetically engineering warhorses?
Because we have tanks.

And combat robot dogs already.

Horses are cute and clever but difficult to feed in warfare. But they have a bonus: we can eat them if the food runs out.

Random intermediate CA. They got a couple of commonly used root CAs to sign for them; and everything just works from there.

That's the problem. It's relatively easy to fire a certificate issuer; but it can get surprisingly fiddly surprisingly fast to ensure that all your stuff actually distrusts one(unless you are responsible for basically nothing but a a handful of in-support major browsers and are OK with the choices their vendors make, in which case it will be handled for you relatively quickly; and was in this case). Basically any network connected widget is going to have at least one trusted root store embedded in it somewhere, possibly not updated anymore; and a number of software packages either bring their own or only partially track the OS-provided one.

You also have very little control over what other people do; both what CAs they chose to get certs from and what...questionable...partnership decisions the root CAs you do chose to trust. It's not technically secret; but unless you are practically a full-time PKI nerd you probably didn't know until after the fact that Comodo, now Sectigo, had quietly trusted eMudhra for you.

The real world is more complicated than that. For example, we still have a Windows 7 machine in my office. It has some very expensive but still very useful software locked to it that has no direct replacement available on either Linux or Windows 11. Obviously we have to be careful about security and controlling access to a legacy OS like that.

Blunt statements about "forcing an upgrade" are worthless in this kind of situation. Chances are anyone who is still using a system like that has a good reason for it, at least if it's in use professionally. We buy these assets because they solve problems. Those problems might or might not have a useful and cost-effective solution available on a different platform. If there is no modern solution available and the original still works, your statement that "the old ways are obsolete" is by definition false.

What you do need to do is rationally assess the risks and the threats you face and provide other ways of mitigating the risks and protecting against the threats if you can't rely on, for example, a legacy OS that no longer gets security updates to be secure by itself. But then ideally you shouldn't be relying on any single device or piece of software being secure as your only line of defence anyway, and assuming you already have some degree of defence in depth, accommodating unusual requirements is more a redistribution of security responsibilities than a fundamental change of approach.

Yes, it does look like we broadly agree here.

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. 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.

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. They might now have titles like "senior" or even "lead" or "staff", but they don't have the skills and experience to operate successfully at those levels. I agree the acceleration of everything due to increasing AI use tends to show these people up and I agree that a good mid-level developer using AI might well outperform them. But then I suspect in reality a good mid-level developer was probably outperforming them before AI as well, it just wasn't so obvious.

It is actually pretty simple unless you are a bot, of course. The vikings didn't annex russia, they have merely replaced the rulers with one of theirs, keeping the rest as it was.
The mongol conquest also hasn't been an annexation. It was more like a racket, with the russian princes paying protection money while being free to launch wars of conquest on their own. Pretty common in history, really. See danegeld as an another example.

How do you decide to trust code you write?

How do you decide to trust code someone else wrote?

Tests. Design discussions. Code reviews. Code review questions. Design Questions. "What about this problem?" Real validation testing.

I was in a funny situation last week. Two different humans told their claude agents to fix the same bug. Claude came up with two _slightly_ different implementations.

I told _my_ claude agent to code review both implementations - using a new prompt I'm working on to try and automate away a lot of the code review value I was adding manually.

Same model; same bug, two implementations, and the code-reviewer agent found different bugs in both PRs.

We ended up blending the best things from both PRs into the one that shipped.

I am really confident that the code I ended up shipping here is better than what our specific humans would have done without using AI, and 10x-100x faster.

I am spending more of my time telling agents how to think like me, what to look for, what tradeoffs to make, etc. They wont do those things unless I tell them to. They don't always do those things perfectly.

(Neither do the real human software engineers who work for me.)

That is wildly optimistic IME. Frontier models do a great job of sounding authoritative on any given subject. This is not the same as actually having expert-level knowledge and understanding, and the choices the models make when you ask them to implement something can and often do reflect that. There are several domains I've worked in over the past few years where AIs lack even basic knowledge an expert practitioner would have, probably because these fields are too specialised to have a lot of books available or papers published, so presumably there hasn't been much subject-specific content to train the models on.

I don't think it's usually about what AI "did really badly on" at this point. It's more about whether the overheads of adding all the guard rails and then reviewing and correcting all the output end up costing at least a similar amount to just writing the code yourself.

For a junior developer, I'd say frontier models passed their standard some time ago. Today's LLMs routinely write code at the level of a competent junior-mid but with the advantage of an inhumanly broad knowledge base.

For a good senior, I'm much less convinced. The frontier models are hit-and-miss when it comes to writing good test suites, which matters a lot when they rely on tests so heavily to reach acceptable quality. IME, they are still mostly miss when it comes to the business insight that seniors will take into account and design/architecture decisions that keep the code manageable as it evolves. While they have become much better at recognising existing patterns in the code, and I would say they follow them reasonably well the majority of the time now, there are still bizarre anomalies that creep in, and they aren't very good at extending those patterns when necessary.

I think AI advocates also tend to underestimate just how much time it takes to properly review what they are doing. Take a half-day Claude session to implement some new feature. It might take half an hour to give it the initial brief and then review its plan. Make a few edits and it'll propose a new plan that is also long and detailed and has no edit markings to show what it changed so you have to review the whole thing, carefully and in detail, again to pick up the minor changes it also made for no obvious reason. Then you let it start doing its thing. You can't really leave it unattended for long because it'll stop to ask questions. Some of those questions might be whether it can run a screenful of ad-hoc Bash script to make some edits to your source files, because for some reason it decided not to show the actual edits as it usually would, so now you have to figure out what all the sed incantations are actually going to do while looking at those files in another editor or just trust it and then review all the changes properly later anyway. Sometimes it decides to change its plan mid-flight, but not always in a good way, and if you interrupt it to apply corrections or redirect, you break the neat plan flow it was in. Then you get to the end and you can finally see how everything it has done fits together, and you still need to review everything with the same care as you would with a junior developer's code and probably apply a few fixes where it's come up with weird names or not quite followed a pattern or imagined some instructions that were never there and made other changes in other parts of the system that should be out of scope.

If you read to the end of that last paragraph, you know how I typically feel at the end of a half day working with an agentic UI. And the thing is, I do those sessions as experiments fairly often to keep up with progress, but a lot of what I do is still written by hand, which gives me simple, objective data to compare the two ways of working and see whether the AI tools are really making me more productive once you take everything into account.

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.

Personally, I think the optimum use of LLMs right now is probably not to use them for the whole coding workflow like that or rely on agentic tools, but to use them for tasks like answering quick questions about the existing code, doing research like a fancy search engine, writing a first draft of some boilerplate, and writing quick and dirty throwaway code for experiments, one-shot tools and the like, where you don't really care about the quality as long as it gets the job done and you will see immediately if it has in fact got the job done. For these things, the LLM can read and type faster than me, and that's useful.