> Why would any self respecting software developer use this tripe?
Because I can ship 2x to 5x more code with nearly the same quality.
My employer isn't paying me to be a craftsman. They're paying me to ship things that make them money.
How do you define code quality in this case and what is your stack?
The definition of code quality is irrelevant to my argument as both human and AI written code are held to the same standard by the same measure (however arbitrary that measure is). 100 units of something vs 99 units of something is a 1 unit difference regardless of what the unit is.
By the time the AI is actually writing code, I've already had it do a robust architecture evaluation and review which it documents in a development plan. I review that development plan just like I'd review another engineers dev plan. It's pretty hard for it to write objectively bad code after that step.
Also, my day to day work is in an existing code base. Nearly every feature I build has existing patterns or reference code. LLMs do extremely well when you tell them "Build X feature. [some class] provides a similar implementation. Review that before starting." If I think something needs to be DRY'd up or refactored, I ask it to do that.
> The definition of code quality is irrelevant to my argument
Understand. Nevertheless, human engineers may deliberately choose certain level of quality and accept certain risks (quality of output is not direct measure of professionalism, so the question wasn’t pointed at your skill) — it‘s good that AI is matching your expectations, but it’s important to understand what are they for your projects.
Code that you can understand and fix later, is acceptable quality per my definition.
Either way, LLMs are actually high up the quality spectrum as they generate a very consistent style of code for everyone. Which gives it uniformity, that is good when other developers have to read and troubleshoot code.
> Code that you can understand and fix later, is acceptable quality per my definition.
This definition limits the number of problems you can solve this way. It basically means buildup of the technical debt - good enough for throwaway code, unacceptable for long term strategy (growth killer for scale-ups).
>Either way, LLMs are actually high up the quality spectrum
This is not what I saw, it’s certainly not great. But that may depend on stack.
I'm curious were you in an existing code base or a greenfield project?
I've found LLMs tend to struggle getting a codebase from 0 to 1. They tend to swap between major approaches somewhat arbitrarily.
In an existing code base, it's very easy to ground them in examples and pattern matching.
Greenfield. It’s an interesting question though, if on today‘s project some model will perform better tomorrow because of more reference data. I would expect LLMs to lag behind on latest technology, simply because their reference data has more older examples and may not include latest versions of platforms or frameworks. I have seen LLMs breaking on basic CRUD tasks because of that.
Good employee, you get cookie and 1h extra pto
No, I get to spend 2 hours working with LLMs, and then spend the rest of the day doing whatever I please. Repeat.
You do understand that state of things is metastable, right? If the productivity gains truly are as claimed, then they will become the _expectation_, and you'll be back to working the same amount. Probably more, because management won't understand that having solid abstractions instead of LLM generated slop is worthwhile for scalability and maintainability. Or less, because you'll have been laid off and will need to do something else to make money. We all know where most of the profits will go if any of this stuff pans out.