zlacker

Your article comes across like you think every developer is the exact same as you, very egocentric piece

Not everyone is just cranking out hacked together MVPs for startups

Do you not realize there are many many other fields and domains of programming?

Not everyone has the same use case as you

>>superc+(OP)
Which part of his article is specific to his use case? It all looks fairly general to me.

>>superc+(OP)
And not everyone working in things that aren’t “hacked together MVPs” has your experience. You can read any number of reports about code generated at FAANG, incident response tooling that gets to RCA faster, etc.

There are obviously still things it can’t do. But the gap between “I haven’t been able to get a tool to work” and “you’re wrong about the tool being useful” is large.

>>superc+(OP)
> Not everyone is just cranking out hacked together MVPs for startups

Now here’s the fun part: In a really restrictive enterprise environment where you’ve got unit tests with 85% code coverage requirements, linters and static typing, these AI programming assistants actually perform even better than they do when given a more “greenfield” MVP-ish assignment with lots of room for misinterpretation. The constant “slamming into guardrails” keeps them from hallucinating and causes them to correct themselves when they do.

The more annoying boxes your job makes you tick, the more parts of the process that make you go “ugh, right, that”, the more AI programming assistants can help you.

>>Uehrek+N1
I’m not entirely sure this is the silver lining you seem to think it is

>>Uehrek+N1
Unfortunately high code coverage is misaligned with high quality code.

If one copy-pastes a routine to make a modified version (that’s used), code coverage goes UP. Sounds like a win win for many…

Later, someone consolidates the two near identical routines during a proper refactoring. They can even add unit tests. Guess what? Code coverage goes DOWN!

Sure, having untested un-executed code is a truly horrible thing. But focusing on coverage can be worse…

>>BobbyT+g4
Trash Driven Development :D

>>BobbyT+g4
Didn't we quickly turn against TDD after it became unavoidably obvious that it doesn't work?

What is which this new paradigm where we act like everything is easily measurable and every measure is perfectly aligned with what we want to measure. We know these things aren't possible. It doesn't take much thought to verify this. Do you believe you are smart enough to test all possible issues? No one is. There'd be no CVEs if you could and we'd have solved all of physics centuries ago

>>Uehrek+N1
A human might see a gap in guardrails and avoid it, or upon seeing unexpected behavior they might be able to tell that a guardrail was breached and have some intuition of where. An LLM will happy burst through a gap in the guardrails, claim it has solved the problem, and require just as much human effort to fix and even more long-term maintenance because of less code familiarity.

>>hatthe+mn
An LLM, which has deep advantages over humans in rote pattern recognition, will see gaps in guardrails that humans miss. In the end, it's a wash. What's not a wash is all the rest of the instrumentation and formal methods stuff an LLM agent enables, all of which is available to every dev team today but doesn't get used because type safety, semgrep rules, advanced linters, and TLA+ specs are too time-consuming for humans to deploy. Not a problem for an LLM agent.

>>nostre+H1
> ...code generated ar FAANG...

Oh, like these set of PRs on the dotnet repo? >>44050152