Over the last year I had your Elixir blog post announcements on my phone’s browser tabs for months and ultimately closed them all just because I never could squeeze 20 minutes to give you a carefully written feedback on your posts. And I mean 20 minutes per post.
But I’ve read at least 11 of them.
One thing that’s worth much longer blog post(s) and posts here on ElixirForum is that this thing in particular is never seen during interviews. You are deemed acceptable / good / fantastic and from then on it’s all internal team mechanics and executives don’t want to hear about it – they will see you as “the troublemaker” because that’s how far their brains can work I guess. No root cause analysis, it’s all “OMG it all worked fine and now this new guy is stirring things, let’s go scold him!” or w/e. That remains an unsolved problem to this day though there are IMO ways to screen for that.
Yep. In my current job I had to explain and over-explain probably no less than 7 times so far that the team’s previous crunch and leg-breaking sprinting to features left their code in absolute shambles.
Did not land. What I had to do was roll up my sleeves and learn to steer Claude in real time together with delivering real features and fixing bugs. Only just recently I finally gained some goodwill that netted me a permission to “start fixing the slop”.
I am not, like, mad or angry about it, but it’s saddening. People want to hire talent that’s better than what they currently have… and then they judge it by their current (suboptimal) standards. It can get frustrating – and it did.
But on a more positive note, I guess that’s how you bond with a team – you go bleed with them on the frontlines and only then do they accept you as one of their own.
Same. After the initial drunken brainrot period has inevitably passed for me, I settled on “productivity gains are from 30% to 100%, usually hovering at 60-70% for most tasks”. You do have to review, enforce general architecture, not allow 1000 private function helpers that really should be reused project-wide, not allow loose financial assertions (so no “> 0” anywhere, always assert on the exact amount and if you can’t then you don’t understand the feature and must hit the brakes), never have nested with or case (not more than 2 levels for the latter anyway) and many, many others.
I had good success of doing chunks of work with Claude and then tell it: “Reconcile all current unstaged code with all our team code policies” – and it finds its own mistakes and fixes them.
But you have to be present and participating.
One of my colleagues coined a good joke: “Claude, implement X and make no mistakes”. I like it.
But yeah, that’s my general take on this entire topic here: you must be present, and you must steer.
We have a saying when our team starts to pass too much things to backlog and too much shitty code to prod, “Oops, it happened again. We need another pain-in-the-ass-picky-nerd in the team.”
I mean, we literally have this informal position, “boring asshole.”
I can only speak for myself but I don’t think anyone is generally assuming they won’t get better, they are just concerning themselves with the present, which I think is the right thing to do. I also don’t think it’s prudent to assume they will get a whole lot better. I do think there is a very good chance they will because humans never stop pushing towards progress (whatever that progress is). But even then there are other factors that could throw a wrench into things, like the price suddenly quadrupling or something. I already think it’s insane how much money people spend on this stuff. I only spend $20/month and still think that is too much
I think you may have missed some crucial details in the post you are replying to. But probably those that can’t hang with the new AI reality will get the boot, have to agree there.
Humans also make the most trivial of errors constantly. Even if you have decades of experience you probably make them.
The same rule that applies to self-driving cars also applies to AI more generally: it doesn’t have to be perfect to be immensely useful. It just needs to be noticeably better than humans at the given task.
Regarding the “six months ago”, you don’t have to take it from me. Listen to what some of the movers and shakers of our industry are saying:
“It genuinely feels to me like GPT 5.2 and Opus 4.5 in November [2025] represent an inflection point - one of those moments where the models get incrementally better in a way that tips across an invisible capability line, where suddenly a whole bunch of much harder coding problems open up." -Simon Willison, co-creator of Django
“This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.” -Ryan Dahl, creator of Node.js
“It turns out half [my] resistance [to AI] was simply that the models were not good enough yet. I spent more time rewriting what it wrote than if I’d done it from scratch. That has now flipped.” -DHH, creator of Ruby on Rails
“Before you drag the ‘software engineering is over by next year’ quote, consider that [Anthropic CEO] Dario’s ‘90% of code will be made by AI in 3-6 months’ has rung true (for my own dev).” -Chris McCord, creator of Phoenix
So let me ask: are these people (and many other prominent SWEs) saying these things because of peer pressure, or do they know something you don’t? Note that the quotes are all from after Opus 4.5 came out.
That’s a common point in discussions about coding agents: treat code generated by agent the same way as you treat one written by a developer. In the end, no matter what editor, coding agent or linter the developer uses, their job is to write the good code and they are responsible for it
And I agree with it in general, but this argument misses the main point in the topic of generated code, which is “how to stop the slop from appearing in reviews in the first place”. And again, it all boils down to the nature of mistakes. People don’t push slop because they think “I see a problem in this code, but I won’t fix it, cause I dont work for @mudasobwa who will fire me”, they push slop because they think “I don’t see any problems with this code”.
And funnily enough, a person can make a mistake during a review. And as a matter of fact, reviews are the last and least efficient step in implementation. Person who wrote the code, usually knows more about the problem and the solution than the person (with the similar experience) who reviews the code. It is just a result of that the person who was writing the code, had to spend like several hours thinking about the problem and every smaller problem they saw during solution implementation. Compare it to the person who spends less than an hour on just reading the code.
Then, meaningful reviews can be done only by engineers who have experience in the problem. More experience and knowledge they have, the better their reviews are. I can review code of opensource Elixir databases, because I’ve read code of databases, read articles about them and implemented some myself. I can review code of compilers because I’ve implemented some small ones myself, read books about them. But I don’t think that a person who just generated a 30k lines project of a database or a compiler without prior experience can perform a decent review of their own generated code (and my reviews on this forum are a proof this). And this is also true for a regular +500/-300 commit, generated by the AI in the ticket the developer knows not much about.
In the end
I think that the real solution is about professional improvement, about learning, about writing good code in the first place, not relying on reviews or some sophisticated reviews structure. And the reality with code generation is: developers don’t learn anything about the problem when they generate code, they gain very little experience and confidence, they can’t perform decent review of generated code, that’s why they can’t stop the slop, that’s why leads have to perform a detailed review of every PR/MR. Because regular devs can’t review their own PRs themselves, because they don’t learn.
I’m actually gonna bite the bullet and attempt to answer this. I think there are quite a lot of reasons why those people might have a very positive experience with LLMs that is not entirely representative of such of an average developer. Some of them from the top of my head:
They might not code all that much anymore
They might primarily work within an established pre-LLM codebases which are very resilient to slopification
They might work on projects alongside other maintainers who shield them from the worst slop
They might primarily work alone on greenfield/research projects.
They might be of such extraordinarily ability that they do not experience deskilling or it will take them a very long time to notice.
There is always a possibility that they were, in fact, “one-shotted by AI”.
In any ways, you can always find other prominent SWEs that acknowledge challenges that LLMs present, so random quotes don’t really give us much.
