We're running a business here. We need real software, not toys created as a fun weekend experiment with a chatbot or burning money to run an agent and get 50% (or more likely 5%) of the way there.

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.

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.

It was probably the other O'Neil, with one L. He has no sense of humour at all.

I could understand bots and mailing lists. The thing I never understood with LinkedIn was how many real people (usually recruitment agents) had apparently spent the time to read my profile and send me a personalised message, yet still thought I'd be interested in a job paying half the market rate for someone with my skills and experience.

I don't know what you mean. Look at the improvement in hiring when you can advertise an open position on LinkedIn and get maybe 100x as many applicants as before! OK, probably 99% of them will be completely unqualified for the role and barely capable of pushing the instant application button, but how is that a problem, really? Surely hiring managers can easily filter them out and no qualified applicant will ever get lost in the noise?

It's like a video I saw on YouTube the other week. Someone was talking all about "skills" for their AI agents and how they'd automated so much of their workflow using them. They started the video by kicking off four different tasks for separate agents to show how productive it was to have all this stuff happening in parallel and how it was so quick and easy to organise.

One of the tasks involved producing an infographic about a certain topic, and the AI duly produced one based on a one-liner prompt, taking only a few seconds of the presenter's time and with no further input from them about the content. The infographic had exactly the level of quality you'd expect from this: a load of boxes and arrows (with some of those arrows starting or finishing floating in space without connecting anything) and some words (a few of which might have been related to the topic mentioned in the prompt).

That infographic was the only substantial output from the whole exercise. It was the worst kind of AI slop imaginable, generated with literally no thought or oversight from the presenter beyond a couple of words about the topic as part of that one-liner prompt. This was probably about the average level of the LinkedIn posts I used to see before I left as well. As you said, I'm not sure you can be a "thought leader" without doing any thinking.

I stopped using LinkedIn when they seemingly decided my account wasn't about me (despite having obvious and publicly verifiable details right there in the description) and wanted me to verify my ID using one of the US-based services with a questionable reputation to get my access back. That's not going to happen, so I just don't use the site any longer.

As far as I can tell, that has made zero difference to my career, and it's one fewer drain on my time. The only thing I have missed is seeing the occasional good news story where a past colleague has been promoted or the like, but I'm not giving up my government-issued credentials to the US-based data harvesting industry for that.

This is fair, but that really just reinforces the point that the article makes. Solo dev is currently different, team output is limited by other factors than pure code output. I've worked on games with literally hundreds of concurrent programmers, and even when you're using something like Unreal Engine and your team is small ( 20 people), you've effectively got all the engine team at Epic generating code for you on a relatively regular basis.

It may indeed be possible for AI to actually make teams faster at some point (even in the nearish future), but right now, it's just more code, which isn't always the best solution.

One of the big problems with this is that it effectively changes the job description of programmers to managers.

You're not just responsible for your own code, you're responsible for telling someone/something else what to do, and then reviewing their work, and then integrating that work and making sure it's correct, because if it gets checked in and it's wrong, you're on the hook for it. But you didn't even write it, so it's harder to understand. Most programmers I know are better at understanding the code they wrote rather than the code they read.

Management is not a job for everyone. I've been a senior programmer and a lead programmer, and it is easier to be a senior programmer that writes complicated, essential systems than it is to be a lead programmer that REVIEWS those systems. If you don't want to do that kind of management work and you just enjoy writing code, you should stay a senior programmer, or move up to some other non-management job. But if you're forced to babysit an LLM, you get ALL THE WORST PARTS of being a lead programmer. You only get the code reviews and none of the intellectual stimulation and enjoyment of creating that thing on your own.

At least a couple comments have pointed out that solo devs use LLMs to great effect, and I'm sure this is true. But if you're not a solo dev, the task is so much different. You're trying to integrate with a bunch of other people and other systems and you're on the hook for something you didn't even write, so you'd best spend the time learning what the code says. It completely defeats the point. When I get an LLM to write my powershell scripts for me, it's because I have no interest at all in learning that scripting language. It takes 2 minutes, usually does a good job, and I can forget about it forever. The development model of asking an LLM to write code that you're responsible for that has to intermingle with the code of dozens of other people and agents sounds like a straight-up nightmare.

Solo development is a different job. The tasks you give to AI are based on what you need, and your own mental model of they code they need to spit out.

Large-scale development is different, because people are different. I've worked on 5 or 6 different game engines over the years, and Unreal is the current one that I'm on. Unreal has its quirks. The rest of our game engine has historical baggage that I need to account for. The interactions between systems are more organic, because not everything can be planned in advance. I worked on Assassin's Creed for 3 games (about 7-8 years?) and we carry over the mistakes of the previous games to the next one, because that engine shipped a game, so it's a known quantity. Sometimes if you're lucky, you get to fix some of those bugs, but then the next games get YOUR bugs, etc.

Solo devs ARE doing amazing work with AI, but solo devs *by definition* don't need to understand the code of 1 or 4 or 50 other people. You can't just check shit in on a big team.

Perfectly reasonable study, because small-scale development is not the same. I have to understand the code of 10+ programmers on a regular basis. Our game engine is involved. The only way for me to learn the code is to use it and step through it.

If you're writing apps yourself, AI is great. It's a teammate that follows your instructions and implements the things that you want. You've already got a mental model of what you need, and it gives that to you. Of course it works for you.

Big codebases are just different. Systems are interdepedent in weird ways for historical reasons, or vendor reasons or weird coworker reasons or whatever. It's not the same task.

There's quite a lot of nuance here, I guess, which isn't unexpected. It's quite a useful anecdote. At the very least, we can't just wave it away like it's not useful. It may generate sub-standard paintings or completely miss the point of art, but if it makes your proofs better, it seems insane to not have it help.

Well, wait, I don't think that actually disproves the claim. I'm not saying it's not impressive, I just don't think it's as novel as you say.

When I ask an LLM to write me code that does something 'novel', it usually does quite a good job. I'm just using the freely available models, but they quite competently write code that is not truly derivative of any other code. If I give them some code of my own that has a bug in it, they'll find the bug and patch it, and that bug is, for all intents and purposes, unique.

You're still seeing a bunch of old patterns rehashed--I presume that other proofs introduce infinity families, and they can iterate through inside a clear logical structure to test whether or not something works. Again, this is impressive work, but I'm not personally convinced that this is 'novel' in terms of the broader corpus of mathematical knowledge. It didn't invent a new field of mathematics to solve your problem.

Even if you didn't prompt it, take a look sometimes at the contemplations of the models, if that's available to you. Before the model even arrives in your hands, it's got stacks of prompts giving it meta instructions, and it then generates prompts for itself to check your work. I think it would be interesting if you ran your experiment again on a new account that's fresh and see if you can watch the chain of reasoning. You might be right, it MAY be doing something TRULY novel, but as I've said, I've got my doubts.

Obviously, you're a mathematician and I'm not; I can't tell you that you're wrong about it if you insist that it is doing something new.