This isn’t to say there’s not hype. Just that if you’re not seeing big productivity gains you need to make sure you really are an outlier and not just surplus to requirements.
Rather, I hear a lot of nuanced opinions of how the tech is useful in some scenarios, but that the net benefit is not clear. I.e. the tech has many drawbacks that make it require a lot of effort to extract actual value from. This is an opinion I personally share.
In most cases, those "big productivity gains" are vastly blown out of proportion. In the context of software development specifically, sure, you can now generate thousands of lines of code in an instant, but writing code was never the bottleneck. It was always the effort to carefully design and implement correct solutions to real-world problems. These new tools can approximate this to an extent, when given relevant context and expert guidance, but the output is always unreliable, and very difficult to verify.
So anyone who claims "big productivity gains" is likely not bothering to verify the output, which in most cases will eventually come back to haunt them and/or anyone who depends on their work. And this should concern everyone.
The only downside is not learning about method Y or Z that work differently than X but would also be sufficient, and you don’t learn the nuances and details of the problem space for X, Y, and Z.
I've learned about outbox pattern, eventual consistency, CAP theorem, etc. It's been fun. But if I didn't ask the LLM to help me understand it would have just went with option A without me understanding why.
Software engineers who haven’t tried these tools don’t understand what they are, and vibe coders who never understood software are taking the mindshare in public because it sounds revolutionary to some and apocalyptic to others. You have to stop listening to the claw bros and try using these as tools yourself in small ways to see what it’s really about, IMO.
"Just verify" is glossing over a lot of difficult work, though. It doesn't just involve checking whether the program compiles and does what you wanted—that's the easy part. You should also verify that the program is secure, robust, reasonably performant, efficient, etc. Even if you think about these things, and ask the tool to do this for you, generate tests, etc., you will have the same verification problem in that case as well. The documentation could also be misleading, and so on. At each step of this process there will likely always be something you missed, which considering you're not experienced in X, Y, or Z, you have no ability to properly judge.
You can ignore all of this, of course, which majority of people do, but then don't be surprised when it fails in unexpected ways.
And verification is actually relatively simple for software. In many other fields and industries verification is very impractical and resource intensive. It doesn't take a genius to deduce the consequences of all of this. Hence, the net effect of these tools is arguably not positive.
I run static analysis on mixed human/AI codebases. The AI parts pass tests fine but they'll have stuff any SAST tool flags on first run — hardcoded creds, wildcard CORS, string-built SQL. Works in a demo, turns into a CVE in prod.
And nobody's review capacity scaled with generation speed. Most teams don't even have semgrep in CI. So you get unreviewed code just sitting in production.
The "10x" is real if you count lines shipped. Nobody counts the fix cost downstream though.
No, its verify that X approach is semantically correct, architecturally makes sense, design is valid and then add tests and documentation. Basically, 80% of the work.
I think people here are thinking I’m building Gmail from scratch when I’m talking about adding additional database APIs and models in the style of stuff I’ve already done twenty times in the same application. That’s easy for even the dumbest LLM and verification is not more than a code review, maybe an hour or two of labor. It’s never perfect, but as stated elsewhere I know how to program this stuff already so I can just fix it on the spot before I commit it.
I understand though, some of you either can’t use agents to code because of one reason or another, or refuse to; both are valid. I’m saying that for my job programming in a specific industry for a specific application in a specific language that AI agents actually help me out more than hinder me, and I still ship quality code in the style that matches the code base.
This is overly dismissive, there are many things that are possible now that weren't before because writing the code is no longer the bottleneck, like porting parts of the codebase from managed to unmanaged for teams with limited capacity. Writing code is about 1/3rd of the job. Another 1/3rd is analysis, which also benefits from AI allowing people who aren't very good at it to outperform. The final 1/3rd is-
> the effort to carefully design and implement correct solutions to real-world problems.
That's problem-solving - that part doesn't get sped up, and likely never will, reliably.