I am shocked by the number of people who are dismissive of AI, or have stuck to the whole copy and paste into a chatbot approach to development.
I'm finding this stuff, when given proper guidance, can reproduce experiments I've run incredibly fast. Weeks of typing done in minutes of talking to Claude Code.
In the working world, a lot of the time what matters is getting results, not writing 'perfect' code the way software engineers would like to.
concerns:
- security bugs
- business logic errors that seem correct but are wrong
as long as you have domain experts, I suspect these will gradually go away. hopefully LLMs can be trained not to do insecure things in code.
> In the working world, a lot of the time what matters is getting results, not writing 'perfect' code the way software engineers would like to.
But you do recognize that one's ability to speedily implement features is dependent on the present quality of a codebase, right? Being a serious practitioner here means balancing active feature development with active tending to the codebase to keep it in a reasonable state, since its quality will tend ever downward otherwise.
In your experiments, do you find agents readily find this balance? I ask genuinely, I have only minimal experience with Cursor.
To be blunt and a bit nihilistic: I get paid to ship features.
Client wants a feature EoW, they get it EoW, they're not paying for a week of extra work for the "quality codebase" feature.
But the good thing is that we've had objective and automated tooling for quality checks for code. We used to use them for humans, but now we apply the same tools for AI.
Good unit testing practices, exhaustive linters, .editorconfig etc. force humans AND LLMs to produce code within specific parameters.
If your project doesn't have automated tests and linters, now is the time to add them. Maybe use an LLM to help you with it :)
Maintaining a quality code base is more than just having tests and linters. It's about organization, right-sized abstractions, architecture and choosing the right patterns. There is no real way to automate the verification of these things. If an agent farts out a 2,000 LOC feature in a day but bifurcates the code base, duplicates functions or makes awful abstractions, it WILL eventually turn into a big ball of mud.
All that being said, if wielded correctly an LLM can contribute to a healthy repository, but it requires much of the same thought and planning that development pre-LLMs did. I promise you, if you stick with the same code base long enough using your approach and little consideration to its health, it will become a hellish place to build in.
I suspect you haven't worked with agents enough. Start trying! You'll see...
In the age of agents.md files, you direct the agents style, organization and architectural choices. If you thought you were a coder, and a good one, your skill is useless. You now need to be an architect and a manager.
> it requires much of the same thought and planning that development pre-LLMs did
Exactly, there's nothing new to coding with LLMs than there is coding with actual humans.
A human programmer can also fart out a 2000 LOC feature that bifurcates, duplicates and has shit abstractions - they just waste a full two week sprint on it.
With a LLM you get the piece of poop in a day and you still have 7-8 days to tell it to fix its shit. With a human you're two weeks in the hole already and the feature is should be QA'd (2 weeks) and needs to be released in a month so ... fuck =)
The feedback loop with LLM generated code is so much faster than with actual humans and it makes up for (some) of the issues with it.
Can it replace all human coders? Of course not. But all of the bulk shit of adding CRUD operations to a handler or adding a new parameter to a HTTP API and flowing it through the 12 layers of enterprise shit to the database layer can be easily done with an LLM and the humans can focus on the actual creative and difficult bits.
I'm not dismissive of AI but I still do the whole "copy and paste" into chatbot approach simply because I use it as a boilerplate or research tool where the intent or workflows are already established and is targeted so it doesn't really matter how it writes since I can "parse" it's output quickly kind like an advance version of vscode saved snippet templates. I never use it do software design for me since this actually requires you understanding the problem but I can still use it to research existing stuff which is pretty cool.
I'm finding this stuff, when given proper guidance, can reproduce experiments I've run incredibly fast. Weeks of typing done in minutes of talking to Claude Code.
In the working world, a lot of the time what matters is getting results, not writing 'perfect' code the way software engineers would like to.
concerns: - security bugs - business logic errors that seem correct but are wrong
as long as you have domain experts, I suspect these will gradually go away. hopefully LLMs can be trained not to do insecure things in code.