Throughout all these conversations I’ve been wondering how long it will take for Steve Yegge to be proven correct:
“If you’re looking at your code, then you’re in a Formula One race and you’ve parked your car and opened the hood and you’re looking at the engine. You’ve slowed time to the point where everyone is racing past you and you’re a frozen statue. Code is a liquid. You spray it through hoses.”
We aren’t there yet obviously, but also Anthropic announced the preview of their upcoming Mythos model today and it seems to be a massive improvement to what is currently available. For all we know, we might be moving towards a future where hand-writing code (as well as reviewing that code) are things of the past, similar to what happened with, say, writing assembly code or having to reserve time to use computers.
This a particular pain point of mine, once I experienced Claude automatically respond to my review comments. IMO reviews are for mutual design discussion and learning, not for rubber-stamping code to get it merged. If we remove ourselves from the feedback loop, we need to reasses why we are doing (human) reviews in the first place.
I think this is a process/results-driven difference in world view. Do we value a well-oiled machine that is a work of art, runs like clockwork, and all the sweat and blood that goes into producing that? Or do we only care about the result, regardless of if the path to it is a monstrosity that is built upon the tears of dying unicorns?
Regardless of what happens there will still be those of us interested in doing that. The only thing I see changing that is when models can reliably write more efficient code 100% of the time. Otherwise, we’ll see how it plays out with companies who vibe their products vs those who don’t (it feels like we’re already witnessing that a little, though there is no hard data that I know of)
Thanks for the paper. I can say at least that it is certainly in line with how I feel when I use it sometimes and what a lot of say . I’m starting to hit my stride, though (I’m not working right now but doing a lot of programming, heh). What stopped my initial “I’m just going to totally prompt and not write anything” experiment was that I was looking directly at the code for a menu that included a chat icon. I typed “Please put the chat icon at the end.” That felt really bad, lol.
Along those lines since DHH was quoted above, what he said directly afterwards in the same tweet thread was:
I still write plenty of code by hand. Both out of necessity (the models aren’t hitting what I want) and out of joy (writing code is fun!), but I’ve embraced the idea that getting a good draft really does speed things up quite often
I think using PR review as the venue for design discussion, mentorship and shared understanding is already a smell, and AI simply exposes it. By the time code is written, the expensive decisions are locked in: arguing about an abstraction in a review comment means somebody’s either redoing the work, or, more likely, shipping it anyway because the reviewer doesn’t want to be the jerk. That conversation needed to happen before a single character was typed (or generated), i.e. at the design doc, the whiteboard, the “hey can I think out loud for ten minutes” Slack huddle. Reviews are a terrible forum for it because the sunk cost is already on the table.
So when I say AI eats code review, I mostly mean it eats the gate function, which is the line-level nits, the style enforcement (like preference for pattern-matching instead of conditionals inside the function), the “did you handle the nil case” stuff. That was always the less valuable half, and offloading it is a feature, not a bug. The design conversation doesn’t disappear with AI, it just moves to where it should have been all along: upstream of the diff.
I don’t think we’re at the level where AI is fully autonomous and humans are completely hands off. But I think we’re closer than most people think to a world where reviewing the code after it gets written becomes mostly unnecessary except maybe in the most critical areas like security, money or features that are literally at life-or-death levels of importance.
Sometimes I wish I didn’t care and I could let go, but I do care and I can’t. It’s a major source of stress to me that the code is being sloppified and I seem to be the only one who really cares.
In the meantime, lots of credo, lots of tests, lots of CI checks is what I have to reign things in how I can. But that doesn’t do anything around taste, duplicating functions, overall architecture of the context modules and functions.
I feel in a very bad rut but only because I really do care about the product I’m building. I have to figure this out.
Bro, have an internet hug from me because I am right there with you. 90% of my work stress is related to so often being the sole voice constantly squawking about tech debt and telling clients no to feature requests. Devs just want to merge their PR and go home and I need to avoid micromanaging. Client support just wants contracts and I need to think about the business. PM wants the meeting to wrap up and I need to think about the next sprint. AI has made this situation objectively worse and I have always been on the edge of just giving up anyway. Once more unto the breach, I guess…
It’s very obvious to me at this point that the only way to win this battle is to go on the offensive. And that’s what I’ll be doing: very soon Zoi will be all over the codebase and the Saga pattern absolutely will be enforced with electric shock collars and laser-guided auto-aiming turrets… as a start.
I think we all should start collaborating – maybe via a community wiki right here on ElixirForum? – on all sorts of lints / checks for Elixir projects. I keep not finding the time but again, it is becoming obvious that I am losing the battle that way and must start aggressively allocate some time for automated quality checks.
