The productivity comes from not having the startup costs. You don’t need to research the best way to do X, just verify that X works via tests and documentation. I find it still takes T hours to actually implement X with an agent, but if I didn’t know how to do X it eliminates that startup cost which might make it take 3T hours instead.
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 find it useful to use a brainstorming skill to teach me X Y Z and help me understand the tradeoffs for each, and what it'd recommend.
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.
In my instance, I’m talking more about using library X or library Y, not the difference between using an atomic versus a mutex. I want to learn the latter, but the former isn’t something I care about.
Ah, that's fair. I personally don't normally care about library usage as long as it's fairly well documented and effective (like Shadcn vs raw tailwind components vs chakra... I don't really care).
Yea I just use LLM agents as tools, I don’t kick whole features to them or have a cloud agent running all the time. I rarely use more than $100 in usage monthly, usually less than half that. I use tab completion a lot in Cursor and use agents to make mechanical changes or integrate features I don’t care about learning, like integrating several libraries together into my application. I also use it to write things I’ve already got examples for, like database APIs.
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.
Agreed; as in most things, moderation is key. It is a new tool that is here whether we like it or not. May as well learn to coexist with it, but also not defer all our thinking to the tool.
> just verify that X works via tests and documentation.
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.
Most features I do are not that complex. For the complex ones I’m already feeding designs to the agent via interfaces and specific instructions.
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.
> You don’t need to research the best way to do X, just verify that X works via tests and documentation.
"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.
Exactly. "Tests pass" and "code is secure" are just different things. AI code makes that gap worse.
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.
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.