> For the person who rejects PR suggestions, it makes me less inclined to participate in those PRs. Why spend the time doing a thorough review if it's going to get rejected anyways.
This is why you leave blocking suggestions and force the conversation if you think it is important enough.
Yep, without a decent team culture this is what LLMs force, the slop deluge is just overwhelming without leadership asserting "no, stop"
Ultimately you just let bugs through because the alternative is spend an inordinate amount of time communicating with someones claude through PR comments about what the shape should be.
Career was fun while it lasted. I suppose its a blessing a to get to do a job that you enjoyed for as many years as I did.
Disapprove and ask for a call where the author must verbally explain the changes to receive approval? This seems like a solvable problem, and one that already existed in repos with many contributors of varying skill (open source, bigco with lots of interns). Letting bugs through is an even bigger time sink.
It comes down to culture on the team, if you think your leadership will allow that/you won't get a bad perf review for doing it go for it. That is sadly not a lot of peoples reality.
If you work at a small shop that may work. Everyone is 100xer now thanks to AI. No one has time to actually go through all this nonsense, not even the people who "wrote" it. Approve and pray you're not the one on call is the only viable strategy for some.
You get better at proactively setting up feedback loops and the ability to respond quicker.
Saying "im sorry this is broken it will take us a few weeks to fix it" feels infinitely worse than "im sorry this is broken give us a few hours and we'll get it fixed"
I started using zig more heavily for some edge device ML inference projects lately after watching Andrews jetbrains interview and it really really resonating with me on a personal level.
Am also really overall enjoying the language, it def has some rough spots regarding documentation and the stdlib but overall has been very nice to work with in neovim.
I can't throw 400k but I'll go ahead and pledge some dollars towards it as well.
I despise this retort that i see constantly, in no way shape or form is it remotely an accurate analogy. They are two completely different things and its dishonest to attribute the two together.
"A compiler is free to optimize...", on sufficiently basic prompting "make me a user address collection form that writes to a database table called 'registered_users'..."
...I agree it's not deterministic (neither are all your variations of C compilers, neither is Firefox v Safari v Chrome), but it probably Does Something(tm), and I might not want to peel back the covers and see how it used React, or Vue, VanillaJS, QT, or GTK.
It's upsetting that we are _committing the generated code_ rather than being able to use better and better optimizing compilers against the original prompt of: "make me a user registration form with database connection"
...I'm very with you on "it's not an accurate analogy", but I'm pointing out that there have been sea-changes already w.r.t. strict adherence to the generated code, or inclusion of left-pad v react libraries.
...and there have been corresponding productivity gains (debatable? ;-) when we've worked at these higher levels of abstraction.
I'm personally still in the "blacksmith" stage of working with AI output (put it back in the fire and beat on it a bunch more times), and shudder in horror at the thought of maintaining (or paying to maintain) megabytes of hours of token generation that looks like source code.
I'm hopeful that we'll eventually strip out some of the mud between the CPU and putting pixels on the screen (with the help of LLM's?), and that we'll still be able to understand and reason about the real "DAG" of what our programs are trying to do (eg: declarative guis, kindof like we have declarative sql), but there will always be a muddy middle part where the computer/complier/LLM is doing something in between that _is_ sufficiently reliable for us to ignore those bits most of the time.
Just to be clear, i also find the "determinism" points to be a bit misleading if the intent is accurate, obviously there has been some level of non determinism in compilers and computing forever. I think the better word is "predictability."
When you write code and it compiles the outcome that you get is entirely predictable. An LLM prompt is not at all predictable.
Overall though agree entirely with your sentiments. And my llm usage is also blacksmith esque, in that its like hammering steel into shape. "Sharing my prompts" would be hundreds of "move this method" "rename this to that" "extract line 12-24 to a new method" etc etc
...I think we've been exponential (or s-curve) w.r.t. repeatable predictability that _smaller_ prompts are yielding. eg: `regform.php: register( first, last, address, email )` would have had a 30% "one-shot" outcome 1-2 years ago, but closer to 90% "one-shot" outcome this year.
As we're "committing" code (blacksmith-type), presumably it's b/c we've reached a plateau of "probably works right" and includes some level of testability and fitness-for-purpose, ie: we've rolled the dice enough times and are committing the current "yahtzee" board to the repo.
16 years ago I've been advocating effectively that "acceptance tests are more valuable than the code under test" (b/c given sufficient acceptance tests, it's "trivial" to reproduce the code correctly... but given the code and no tests it's at least an order of magnitude harder to prove correctness)
It's again the dual hourglass shape of consensus between creation and acceptance, and LLM's (when used well) are helping to compress the two sides together around an "exact" agreeable crystallization.
"I want you to calculate pi" (wide hourglass) <=> ...etc... <=> [(precise code/assembly) <=> (precise validation)] <=> ...etc... <=> "pi should start with 3.14", "pirr should equal area", ...etc...
...but throughout time, we as developers have been the human interpreters / vessels via "english-to-buggy-code", and now we have this whole new set of (semi-unpredictable) tools. Think of woodworking (hackers), with hand-tools and eventually moving to power tools w/ jigs. Some things are lost, but others are gained! Maybe we're needing to come up with "jigs" (or "harnesses?" ;-) to strap around our new LLM power-tools?
Closing thought... I've done some sketchup modeling, eg: mocking my kitchen to consider a remodel. "Models must represent to a precision useful for their purpose". Counters, sink, fridge... cool! But then, should I include the toe-kick cutout, or cabinets == flat boxes? Should I include the counter overhang? What about representing the cabinet doors? Should I include the cabinet knobs? Should I actually measure the true openings down to the 16th inch? Validate that they're 90deg rather than 88deg square? On the counter overhang, should I include the rounding? What if it was routed, is the shape of the overhang important?
Basically, reality has infinite detail and our "captured models" of the problem domain are always working at a level of detail that is "fit for purpose". Design a nuclear power plant? LLM == "probably not". Design a local CD ripper GUI for yourself? "the level of detail and correctness is probably fit for purpose"
In terms of knowledge sharing and gathering hard-won human context I agree, sort of. An LM review can at least prompt some reasonable changes, catch performance issues, etc.
This is why you leave blocking suggestions and force the conversation if you think it is important enough.
reply