Slop is not necessarily the future

But I am not the fan of code it writes most of the times. I want my code to read and behave certain way. I can not submit that code, even if it works, if I can't explain or just don't like it. I then iterate over that code myself or ask AI until it has the shape I agree with.

For my personal side projects I don't care as much what code looks like as long as it works correctly and easily modifiable. But for work, it still remains my responsibility no matter which tool was used.

I don't believe there is a dichotomy, or even a spectrum of developers, but a complex landscape. Of course, that is also an bald assertion, but on a weaker claim, and no less valid than the original assertion.

That said, independent of assertions about developer classification, in my experience there is a clear connection between the quality of the software and the quality of the product, and I've often see evidence of poor quality software compromising the product and user experience. Poor quality leaks out. Remember BSOD? Maybe not.

I've become hesitant to unleash coding agents simply because the code base ends up looking like the victim of drive-by coding, littered with curious lambda functions, poor encapsulation, etc. The only thing I use coding agents for is exploratory and throwaway code, like one off scripts. I love coding agents for all the ancillary work, I protect the critical path like mamma bear her cubs.

Coding agents make all the second order work easier so I have more bandwidth to focus on the critical parts. Again, software is a landscape, but at least for my work I can't abdicate parts to a coding agent and "works" is an inadequate standard. I need bullet-proof and unfailingly correct.

Token generation definitely produces a certain stream-of-consciousness, Kerouac-as-programmer style. As long as I don't ever have to maintain or modify the code myself, am not concerned about cost control (especially in cloud environments where I am billed by compute cycles), I am fine with quick and dirty and done. I sigh when I see what should be a six line change in my head balloon to 300 lines of generated code, revert, and write the six lines myself. Would take longer to write the prompt to get the coding agent to fix it than fix it myself. It would grind away for several minutes and burn up an astonishing number of tokens for simple fixes.

Anything linguistic the coding agents do well. Want to rename a variable in 300 different source files? I mean, it is overkill to be running a 200B parameter model to avoid writing the sed script I might write otherwise, but who am I to turn my nose up at my work being subsidized by investors? I don't think that economic model will go on forever.

Any higher abstraction is being cargo-culted from language. This is where LLMs are weakest, because they don't understand abstraction or encapsulation, only the artifacts as expressed in language.

Outside of exploratory and throwaway code, I use inline prompting to precisely target and scope changes, and then identify the cleanup and refactoring required to bring the code to acceptable quality. Although I do a lot of cleanup by hand as well. Rather than tell the coding agent that a lambda function wrapping a one liner that is used in one place in the code is dumb, I'll just remove the lambda myself. The coding agent can't adopt and generalize lessons from code review comments the way a human software engineer can -- I am forced to burn tokens every single time to get it to dial back its insane love affair with lambda functions. Again, not a big deal while costs remain subsidized.

Operations and maintenance overhead in the type of software I've written through my career dominates over programming cost. Telecom, aerospace, e-commerce, etc. Systems are long lived. Outages are expensive. Regulatory compliance is a large factor. I've worked in shops with 70% cost overhead in operations. A $50K a month cloud compute bill can be reduced to $15K. There's usually some low hanging fruit and poor quality software doesn't account for all of this, but it is a significant fraction. Like a poorly written termination condition in a container that essentially was a busy wait burning thousands of dollars a month doing nothing (true story).

I am currently writing a trading system, and can't afford to hallucinate a bunch of bad trades. Like the developer landscape, the software landscape is complex and not uniform. So I will concede there are probably many types of software outside of my own experience that can be implemented largely by coding agents. Low consequence. Marginal operational overhead.

I might assert that coding agents forte is autogenerating technical debt, but then I am just being a wag. Less waggishly I would say use of coding agents is subject to engineering judgement, like any tool. Who is going to read that headline or give it a billion dollar valuation?

when you're making (crafting) software if the lines are going up for an equivalent functionality it means you're cooking up bullshit.

the whole premise of software arts (engineering) - is you do MORE with LESS.

engineering is not science, and neither is art. creativity is needed, rules of thumb are to be followed.