I'm no longer considering myself a good developer either, the agent is way better at details. Not so much at following a general pattern that makes sense.
If humans are no longer reading the LLM outputs and internalizing the codebase themselves, there's no longer much point to source code. The coding assistant might as well take a natural language prompt and directly hand you an ELF binary that passes a test suite. Are companies ready for that?
Also, consider token efficiency. Imagine how many tokens would be torched just translating an import statement of a popular library to its binary equivalent, let alone a big complex program
On the other hand its VERY fast at finding and fixing some bugs, and finding problems before they hit production. Very good at checking things like what API changes an upgrade brings or finding the right answer about a badly documented library, etc.
It's not fear. It's experience. I've seen the kind of code agents write. And it's too often crap even when it "works". This isn't about beautiful code. It's about what we've built actually making sense to a, hopefully talented, software engineer.
Maybe more important than that, it's about taking the time to build the mental models that facilitate product development and the next iterations of coding. When agents write all the software, the majority of engineers I've seen, including myself, lose almost all context to what is actually going on at anything but a very high almost laughable level. And they then become almost completely dependent on the agent for the next iteration of development b/c they don't really understand what is there currently.
Does this matter? From a software perspective, it depends on what you are building and for whom.
From a human perspective, it depends on the human. I've seen good developers that I trust historically churn out crap code with agents because it was just too much to review. And there is some kind of weird addiction like thing happening in our brains when using AI that makes it incredibly difficult for us to slow down and review all the code it writes. In part b/c agents are great at crapping out 3K line PRs like it's nobody's business. But it needs to be someone's business to understand what we are shipping for anything but non-trivial projects. And truly understanding 3K line PRs hour after hour is just not sustainable for most of us. Our eyes glaze over and we just ship it because that's what we do now as an industry.
I think wary is the wrong term. I've learned agentic development's strengths and weaknesses. And the tools, as they work currently, churn out code at a rocket's pace that any good software engineer would immediately reject in years past. I don't like their code, I don't like how their code development process interacts with my brain. It's not waryness, it's dislike and mistrust.
So, yes, they can be assistants. And they can even write code. But I think in much smaller chunks than most people are using them these days.
The idea that we should build software factories and/or otherwise just turn agents loose and isolate humans to the product/QA level is insane to me. But I understand why we are here and I realize that a large portion of the business and dev community likes this new model.
I'm hoping that not doing it that way will end up be a competitive advantage in the long run. Both for the software we are producing and for the devs that are creating it.
All that AI does is giving lazy developers more output that is approved by another LGTM developer, so the appearances of progress are kept up.
There is no reason at all to justify no-AI usage. It is the same as when the cigarette industry depicted smoking as cool and non-smokers had to justify not giving in to the dirty habit for fear of not being one of the cool kids.
I've personally experienced week long incidents because someone didn't understand how a system worked and a couple of low impact shortcuts and convenient approaches and minor mistakes all came together to internally DDOS important systems. All reasonable individually, resulted in the majority of the ops team pulling a 70+ hour week and doing live prod cleanups in the middle of the night.... Agents do this faster. Also, they're labor competition, maybe.
proceeds to install 200 random npm dependencies
The biggest pocket of skilled holdouts I've noticed are in more artisan spaces where the craft of coding is part of the art. Things like old-school indie game developers where they're still sweating the assembly output and clock cycles.
> they are not hesitant to use a coding assistant, they are hesitant to go all in and let the agents do all the execution.
They are embracing the use of coding agents, but they still want to be in control. That also matches what I see from my most talented colleagues. They outsource certain tasks to the AI and verify the output.
My somewhat unpopular opinion is that only very good developers are able to use AI coding tools somewhat safely. They could have written the code themselves, but it's faster to have the agent do and then verify. The rest of us couldn't write the code, at least not when we start on a project. When we finish, we have some of the skills and could rely more on the AI tools if we were to do it again.
When even Linus is using agents it is time to accept it.
Software works because someone is accountable for it. Pair Programming, Test Driven Development, and now Agentic coding all to one degree or another damage the network of trust.
- Pair Programming (There is no one person accountable for the change.) - Test Driven Development (The test pass, so my software is good) - Agentic Coding (My prompt was good, so my software is good)
AI is great for software development... As long as you review and understand each change it makes. Because YOU are going to be held accountable for what the software does.
This is the exact mentality behind corporate software and why nobody gets fired for using IBM, Oracle, Azure...
Accountability is a poor proxy for quality because there are so many ways to frame an incident never those responsible really get accountable.
Software works because developers care about the product. If something goes wrong the entire team is accountable, so they work together on something as one.
Then there's... management forcing "agentic development" on you to basically hurry up, and actively don't want your design input or even to think about the problem. Just 'review it' and be expected to own the problems after. Outsourcing basically.
The first is fine, second is not sustainable for any happiness unless you are offering top compensation.
However, generative AI should be banned for leadership or product owners or anyone on the requirements specification end of the Jira ticket. I'm fine with them using LLMs to read documents and learn, but generative AI specifically in the hands of these folks seems to be a net productivity drag on organizations.
I am so tired of 1,500 word Jira tickets that are over-specified to death with requirements that nobody is actually interested in and I have to spend exorbitant amounts of times just trying to distill out the functionality that the requestor is actually looking for. And these logorrheic nightmare tickets end up spawning all kinds of other unnecessary downstream work.
This is not a new problem, I've had this problem every summer when a new batch of interns show up.
As they say, if an intern can bring down production, it is not the intern's fault.
The interns are generally so much better than me at writing code, but they're not the best at "software development" (I call it "software gardening").
My training regime is to push them up the next 4 leadership levels from "writing code" - delegation, negotiation, vision and inspiration.
Agents are barely at delegation, with multi-agent harnesses.
They don't negotiate with you, they say yes.
Their vision is limited to the context you gave and most of their output is uninspiring (you can smell "Claude did this" on a UX design pattern easily).
But the humans, they've been thrust into delegation on day 1 & unless you've been a tech-lead manager, you probably haven't exercised that skill yet. Even if you have done that, the way agents work is not exactly how humans work [1] in terms of incentives or even try something they think won't work.
If you've been a good IC for years, the company could always afford to hire a human who specializes in those skills and suddenly you've been promoted to a new role without a pay bump or even a choice.
Most of the "Let's add agents and go faster" is basically adding more manpower to a project behind schedule and the payback is missing because that causes communication gaps & dropped messages.
But I don't mind "agentic development" to help a person learn to code in a domain. As kind of a tutorial, both on "how things can work" and "how to spot the mistakes". "Agents" and "AI" always make a LOT of mistakes, especially in fields of domain specialization.
All you can go by is 'does it do what it says it does'
Engineers introduce these packages into their own projects that have far fewer of the above guarantees than OSS, are built under pressure from deadlines, and have a constantly churning set of maintainers.
I think from the perspective of a business its own code does call for greater scrutiny than its dependencies.
Lots of tools for analysing and debugging it
It can be cross platform - the same source code will run on x86 and ARM, and in many cases on Windows and Linux.
Changes have predictable consequences because compilers and interpreters are deterministic.
But for projects with expansive eat-the-world requirements and a need for extensive customization (enterprise and some large B2C platforms), or those with strict resource efficiency constraints, you can't just shake and bake a black box every time you have a new idea/requirement/bug. The search space to fit against is too vast, which even your model will need to pay for. You need to be working up from both a very detailed specification that can hold/verify all your constraints firm amidst changes and an architecture that sufficiently anticipated what you mean to add/fix.
Source code (as theory crafting) is really good at being the minimally-ambiguous documentation of those constraints and the analytical expression of that architecture. Where it matters, even in the context of agentic development, good source code will make your model get much more done for much less and so maintains your competitive advantage.
It's not going anywhere in the big picture, even if there will be more projects where it doesn't matter.
Until spec files can be worked with so efficiently that we can just regenerate the binaries from them for every change, what you said makes little sense.
You're going to need an intermediate portable form of storing the program. It so happens that all the tools and AI are optimized to work with source code.
Maybe you do, but most of our industry doesn't and hasn't for decades. Isn't this just the next step up the ladder of abstraction?
The Jest test runner alone has 250 dependencies in its latest version, and v25 had over 500.
Part of using software is just going off how well it works.
When one Linux flavor starts to have issues, most people don't do a dissection on why, they just switch distros. Or web browsers (I've lost count of the back-and-forth between FF and Chrome performance over the years, nevermind all their precursors). Or office suites.
Pretending that the code is what really matters, and not what the code does, is elevating the paint quality over the painting.
When dealing with LLM output, you're getting a 1 of 1. There's no way to measure the community, number of contributors, or how maintainable it is.
jqpabc123•2h ago
Perhaps because agentic development is aimed at replacing "good developers".
Agentic development tends to undermine the very process that creates "good developers".
Agentic development will do to software what off-shoring did to manufacturing.
kube-system•43m ago
> Agentic development will do to software what off-shoring did to manufacturing.
Agentic development will do to software what off-shoring did to software development.
majorchord•43m ago
alienbaby•35m ago
There will still be the need for humans in the loop to make sure the final product is suitable and what the humans genuinely wanted. We'll all become QA / Acceptance testers. For a little while , that will go away in the end too I think. software will become nothing more special than every day household objects.
datadrivenangel•20m ago
A lot of DIY AI software is going to be the equivalent of home built workshop / shed furniture: it works fine, but it is janky and built from whatever they had at the hardware store. There will be a place for professional assemblers and designers and engineers at the furniture store / factories.
majorchord•8m ago