Leave Me Behind

> Indeed, however I would also point out that senior engineers have already been expected to be good at reading code: they were expected to evaluate the code quality of other contributors, so they had to be able to do that.

Yeah, but the frequency, volume, and complexity of that activity, and its ratio versus all the other work that a developer was previously expected to do, has shifted dramatically, not least because now we're having to review the output of our own coding agents as well as that of other developers on our teams.

As a consequence, folks who were marginal but capable at that skill now likely find themselves working beyond their ability.

> So, really, I think that for juniors it's actually much harder because if they want to do due dilligence they have to do the same evaluation but without the years of experience working with that code base. I can understand, even if I don't like it, that they just submit the output of the LLM for the senior to review.

Yup, couldn't agree more.

A really sincere piece of advice that I really hope you take to heart: everyone who disagrees with you is not simply beneath your genius. I am not a PM (yet that is also quite insulting to some very competent and technical PM's I have worked with), I have an actual math degree, alongside a physics degree and a PhD in astrophysics from a strong department; I have worked in companies both at the MAANG scale and companies as small as 20 people for the last decade. It feels gross to have to type this but evidently you seem blocked from considering other viewpoints because you think I am a "vibe coding PM". It's ok if you want to cling to this as a comfort but just know it's a troubling way of going through life and also happens to be leading you astray in this particular case.

I don't see really any hard source at all here from you except anecdotes that you seem to hold in very high regard. I do see an incredible amount of condescension and chest pounding about what is ultimately a very technical and...ahem...mathematical topic. I don't know about you but I don't really see many conference paper reviews that start with "I am not here to enlighten every vibe coding PM that shows up". I am sure you would agree with me.

> But for the sake of bringing you closer, the "agentic" code is often very inferior, implementing happy paths or just bluntly exposing secrets in clear texts, etc. Probably a consequence of it being trained on, as you put it "p50 engineering code".

I do appreciate this tiny delicious gift of "bringing me closer" because it (1) answers my question about "inherent" properties of agentic systems by giving anecdotal examples of existing systems, (2) completely misunderstands how agentic coding models are trained. Human code traces are a bootstrap to an RL with verifiable rewards stage. Not having the same "you are too beneath me to explain my wrong opinions" attitude, I will genuinely explain a bit because this isn't as trivial and obvious as you make it sound, nor is it a giant pissing contest. Likely the most important property of coding agents that has resulted in their existing and future success is that they are not limited by the quality of human training data. Seems to be a very common misconception, but this is, like you say, just math:

- Agentic coding models like Claude go through several complex training stages

- Pretraining which is kind of a compression step and gives them semantic understanding and a bit more

- Supervised fine tuning which gives them some task specific performance (this is where human traces and verified synthetic traces are used)

- Alignment to make them not give you meth recipes and to behave in the way you want agents to behave

- Reinforcement learning with verifiable rewards (RLVR): then they go forth and solve open ended questions. RLVR is not new mathematics, we know what happens when you take RL with good rewards and throw a bunch of compute at it, we've known that for decades now. This is where the "superhuman" performance comes in, it's not some "vibe coding PM" that's giving you an empty promise, it is the math that you and I so highly revere that promises you this.

> Running my own company and been paying the LLM-Shit-Generators for my whole team for a long time, in the hope they would bring the advertised benefits. Guess what - for serious use-cases, they bring shit and more shit.

This sounds like the experience I would mostly expect from a small company adopting Claude, it is not magic nor is it at the point where you can blindly trust it to not mess something up. It will waste your time. I find it kind of doubtful it has not given you any benefits, but I'm not sitting where you're sitting so I can't refute your experience. People talk resentfully about "advertised benefits" but then never cite what advertised benefits they interpreted these systems as having. Do you have like a quote or something that you can point at?

> Oh yeah obviously not, I mean, its not like understanding software development would help you understand how LLMs are not similar to a "p50 engineer" at all:). I'd take the latter over the former every time.

Maybe I misinterpreted you: I found you telling me to "read a book" to be more of a dismissive condescending comment but maybe you mean it sincerely in which case, sure I will continue to read programming books and following the published work in the field as I have done for years now.

> Well for one, LLMs are not humans, but it should be obvious to even to most cretinous of the e/acc crowd. It's not like they can think in abstract terms or come up with completely new concepts. But then again, don't mind me - if you can live with below average AI slop - go for it.

I do agree with you that LLMs are not humans but when you say this is obvious and then don't back it up, that is really not convincing. I think you overestimate the capability of human beings and underestimate the asymptotic capabilities of these systems. Their performance improvements are predictable and these predictions continue to hold. It seems the burden of proof is on you to explain why we should expect some sort of fundamental limit to these capabilities and where those fundamental limits would arise. I'm not aware of very many.

> exaggeration and spin made by corporate marketing.

corporate marketing spins and hypes, but this is an ultimately pretty academic and mathematical field. The loud LinkedIn promoters are not building these systems.

"if one looks into the details and think critically about what is being claimed, one can see that consumers are jumping to false conclusions."

well then help us out here: can you be specific? To me it sounds a lot like goalpost moving. You're telling me that in 2020 if I showed you a system that can solve an Erdos problem or disprove a conjecture (just recently showed up) you wouldn't be blown away?

> That said, it is very cool how an LLM helped human mathematicians in the recent specific Erdos problem solution announced by OpenAI. Just don't jump to the conclusion that anybody can input any Erdos problem into an LLM and a solution will come out the other end.

Woah woah, that's not the conclusion I'm jumping to. That's not at all how these headlines happen. Solving problems like this is almost prohibitively expensive today, and they more often than not lead nowhere. The point I'm making is, today, 4 years since ChatGPT, we have systems that can and have solved them. First we had things like AIME and IMO benchmarks, then people said "well those are just cheats in the training data, wait for it to solve a real math problem" -- ok but now we're solving real math problems.

I agree that it's out of the developer's control in some organizations. I'm also skeptical the degree to which this is happening across the industry. If I were running a software team, I would give team members autonomy over how much they use AI. Some people will be more productive with it, and some will be more productive without it. What matters is delivering quality software.

Long before vibe coding, it was well understood that output in terms of lines of code wasn't a good metric for quality or productivity. I'm predicting that the industry will come to the same understanding in terms of PRs and token usage. Eventually, those lagging indicators will catch up and teams will have to relearn the "No Silver Bullet" lesson.

I have everything this guy is talking about just from running Filerun (with the Nextcloud client for mirrors) and backing up to Backblaze R2. At some point developers seem to forget that other developers exist.