Engineering leads, what are you doing to stop the slop?

,

Right now I like to think they are more faulty than us, and making mistakes at a much much faster rate! Amazing!

The productivity though is really something. The sharp edges not so much. I am even working on three projects while typing this. I will be needing more computers if this continues.

2 Likes

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.

3 Likes

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…)

3 Likes

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.

4 Likes

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.

1 Like

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. :slightly_smiling_face:

2 Likes