I’m in a session now where I’ve corrected AI’s mistakes and it has corrected mine.
If AI could make me 3x as fast, I think the ideal is to let it make me only 2x as fast, and spend the gap on scrutinizing its work, tweaking it, having it scrutinize my tweaks, and coming up with higher quality output.
Saw this earlier and it made me think of this thread:
Humour, but does emphasise what might become an almost impossible (/unenviable) task, or represent the new role the majority of employed devs might shift into; reviewers of code written by LLMs rather than writing it themselves. This could shift the role of developer away from creativity (writing code) and more towards administration (reviewing code), to some degree anyway.
For those who end up having to review code it’s probably not going to be a very pleasant task/job, as indicated by the OP of this thread:
Generally there’s more job satisfaction in creative roles than ‘mundane’ administrative ones.
Does make you wonder when things might reach breaking point - for devs. (Maybe we should do an annual “How satisfied are you as a developer poll” to see whether/how things change over time…)
This is what I’m worried about as well. Creative work is turning into a wheel of fortune that I just need to spin enough times to get what I want. Or at least get something I can convince myself I wanted the whole time. And than fix all the things that are wrong with it instead of doing them well from the beginning.
And don’t think that’s specific to software development. More and more I see people having to fix slop instead of being creative.
My take is the source is not Claude’s. It’s still yours, you just didn’t type it yourself verbatim, but you did type pretty all the input that was used to create it. That code is 100% yours, so you’re not a reviewer but still the author. Difficulties bridging the gap between explicit and direct on one side and indirect, often implicit & semi-ambiguous on the other? Easy: revert back to an interim stage that suits you better - doesn’t need to be the code itself, can be just the stubs, key abstractions, behavio(u)rs, .. All those + your own implementation patterns are the inputs you must provide to Claude if you need the results resembling those when you do provide those same inputs to yourself (because otherwise you couldn’t do without).
I’m saying all this because I’ve discovered how relatively easy it is to do away with all the slop if you take on the responsibility of telling Claude to separate the concerns and sometimes even how exactly you need them separated (and keep feeding it your patterns). Claude itself already knows how to do it quite well, it’s just it’s not doing it by default. It’s default is to find the shortest way of implementing the provided requirements that works. I’d compare its code generation to water: If the shortest way down is through the floor then it will go through the floor. Not preventing it in doing so is our slop, not Claude’s. Claude can’t read our minds, let alone the thoughts that haven’t even been articulated yet. Therefore it’s slop in → slop out / quality in → quality out. No reviewers, still the authors.
My take is different. The creative work now is more about learning and taming the tool than cranking out yet one more iteration of a function that I’ve probably written a dozen times in six languages in the last three decades. It’s taken a couple of months of work to write the correct (gemini-cli) skills to get the results I want in a predictable way but the time invested has paid dividends. Orchestration tools, multiple agents, correctly deconstructing tasks, precise prompts … the work really has changed from knowing syntax to knowing how to architect, plan, and construct useful tests. I find using gemini to be more cognitively taxing than churning out code by hand, at least most of the time, but get verifiable results an order of magnitude faster.
I am an emacs user so “taming the tool” really feels like second nature. 
To come up with a balanced opinion instead of wild guesses, I spent a whole week to code review everything we deliver. The vast majority of code in these PRs has been produced by Claude. Here are my observations.
ifs, conds, Access via brackets everywhere, no with/2, no deep pattern matching, no multiple heads)That’s basically it. The code is ready for prod, it passes all the acceptance tests one might ever invent, but it makes my eyes bleeding and if I’m to be the next person to modify it, I’m to start with full rewrite of this crap to real elixir.
That being said, my personal battle now is to come up with rules for Claude to prefer elixir code over javascript written with elixir syntax. I resolved this issue for myself a century ago by teaching my agent on my own opensorce libs (I pointed her out there and told her, “this is a good code, write like that.”) Claude is so much more stupid, that a ruleset is most likely required.
Interesting.. my experience with its default syntax is quite different. It uses function clauses quite often (but forgets about adding a header-only above them), it never uses if, not even when it should, prefers matching with case against nil as the first clause instead of doing if foo = get_foo( bar) do, it uses with quite often, but yes, it likes to nest case and cond, ..
However, I’ve never used it on a greenfield yet, so it could be it tries to pick up some of the coding style it finds in the code base (it definitely didn’t find the patterns I’m complaining about here, though).
This would never pass my CR 
I even thought about providing a PR to Elixir core to improve this particular construct to not break a scope (passing the whole argument to if down to the macro hygiene.)
This code leaves foo in the outer scope, which is, ahem, unexpected.
Depends on the model, I guess.
Now, that I did not know. 100% agreed. it shouldn’t. I wonder how this passed under the radar @josevalim.
However, that’s also “not my problem” (until it becomes 
).
Anyway, I like the if construct this way a lot - less LoC than using case, unless inlining results with their -> which then becomes less readable, unless, of course, one aligns the results with tabs which then becomes un-Elixirish (and I guess the default formatter would revert it to new lines, not sure b/c I’m not using it).
if/2 should not assume anything about its arguments, that’s why I never provided a PR. Having a dedicated clause to catch the developer’s unwillingness to produce idiomatic code is far beyond the scope of the standard library, I believe.
The outer scope gets foo assigned, so why if/2 should even care about that?
I truly hate that elixir ever has if/2, let alone unless/2. I never use them in my code and I tend to get angry when I see them in the colleagues’ code. if conditional is the worst thing ever happened to programming languages. I can bear with one-handed if for side effects, that’s it. Two branches in if are simply contradictory to our life experience and erlang was all about mimicking our life experience.
We think like “if now it’s 5PM+, I’ll get my scotch,” but we rarely think “if now it’s 5PM+, I’ll get my scotch, otherwise I’ll take a shower.” ANd ifs are extremely complicated to grasp.