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.
> Software works because someone is accountable for it.
When software works, it's because there were layers of measures to ensure quality. In order to set up and maintain those measures, you need to establish accountability for quality, not for individual changes.
In fact, given that making mistakes is perfectly human, I would argue that insisting on accountability for individual changes is counterproductive. Since I'm a grumpy old fart, I'll illustrate what I mean with a story ;)
At one of the places I've worked, there was this workplace survey they would do twice a year, one of those anonymous surveys where they give you a bunch of statements and have you select options ranging from "strongly disagree" to "strongly agree". One of the questions that has stuck with me was "on my team, it feels safe to make mistakes".
For the first couple of years or so, I didn't really grok the deeper meaning of that question. I simply interpreted it as "my team is forgiving of minor fuck-ups" and didn't think more about it. I'm not sure what made it click, but one day I realized that it's not just about not working under a martinet. It's about minimizing the chances of a mistake causing problems and maximizing the ease of recovery from such problems if they do occur.
Being able to point a finger at me or one of my teammates and say "this is the person that screwed up" is not what makes software work.
How does opensource software work when nobody is accountable when I run software from GitHub?
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.
Yes, you look at stars, issues and activity to infer trust, but there is no accountability, the licenses are clear about that that software is distributed as is
This comment makes me despair. Pair Programming and TDD, as well as other aspects of Extreme Programming, were explicitly introduced as practices that put the human, with needs and feelings, at the center of the software development process. Your analogy is wildly off base, so much so that I suspect a trolling attempt (if that's the case, well played)
They have a HN history going back nearly a decade (pre-LLM) with comments mostly not looking like trolling to me. My first guess would be that they've just been exposed to a bad implementation of Pair Programming and TDD (or even a "good" implementation in an environment where it's not a good fit), and that's where they developed those opinions.
TDD especially has a lot of critics. Some of that's justified. Some of it is just a difference in thought methodologies (e.g., a fraction of developers "think" through a problem by writing code, and the "tests" mandated by TDD physically can't meaningfully appear till after some implementation has happened). If a rando developer thinks negatively of it, that's not news to me. If they haven't tried it much and misattribute the exact cause of those negative opinions to be able to form a nice story-centric through-line, that's also not surprising. I'd be much more inclined to believe they're a developer who you disagree with than a deliberate troll. Who knows.
100%. It's the accountability that I find most compelling.
My AI assisted software has far FEWER bugs than when I hand-coded everything.
Why? I use it to improve and augment my judgement, rather than replace it. Critical analysis, rapid PoC spikes, more tests, more documentation. Half the tests may be superfluous, and the documentation might be overly verbose...but there are more good tests, and the documentation is at least PRESENT and consistent.
I don't get this comment, you say it breaks trust because it's unknown who is accountable, and then you say you (the author) is accountable. So where is the trust broken?
Also your examples are wrong, regardless of pair programming or TDD, there is always a single committer, who is to be held accountable. How you achieve that commit in the past, copy-pasting from stackoverflow, or some auto-expand snippet automation from the IDE - so any tooling - does not matter. Agentic development is also such a tool, thus does not change trust.
The agent runner, or committer, a single human, is to be held accountable. That responsibility is - and always was - the most important role of a programmer.
I am wondering if a combination of broader/deeper observability attach and synthetic user monitoring can help offset some of this. This may just displace and not mitigate the trust issue, but it seems like a valid product direction for the harness layer given falling token costs.
I started thinking about agentic programming from a totally different perspective.
Personal accountability in software development is actually hard, and less useful than it seems. What good is it if you discover a 12 y.o. vulnerability and can blame a specific person? (Like the recent one in PHP?) You may learn the name of that programmer who made the mistake, but it does not really tell you anything about that person, unless their overall record is terrible, and you are not entitled to any damages anyway.
In closed source, this is even worse. So a certain Windows function sucks. Now what. You never learn any other provenience than "Microsoft did it". Tough luck even getting support, and you certainly don't get your license fee back. This sort of accountability is worse than useless.
The only exception I see is knowledge within a specific development team. We usually know what sort of errors our colleagues are prone to, and we may be able to work around their personal weak spots.
Agentic coding done well has a dimension of trust that human coding cannot achieve. I can tell my agents to aim for 100 per cent test coverage without overburdening them or running out of budget and time. I can ask other agents and other models to review code written by the first agents, and then again. Every layer of such review adds some credibility to the result, and its mechanistic character ensures certain level of repeatability. Sure, it can happen that all involved mechanisms share the same weakness and let a particular bug through. But it is similar to several sieves over one another lining up perfectly to let something through, and that is quite rare.
If I had to choose, I would trust code designed, implemented and reviewed by three different SOTA models over code designed, implemented and reviewed by three median programmers today. Three elite programmers would have been a different story, but that would also be expensive like hell, and much like you don't eat most of your dinners in a Michelin restaurant, you have to economize with your code development in a similar way.
For me programming is about reducing complexity, in one way or another. By reducing needless CPU cycles or RAM, or by reducing the complexity of the code when I read it, making it "more logical", which is of course in tension with what would be the absolute most optimal (e.g. perfectly optimized assembly for everything). You make low-level things to turn into higher-level functions to do even higher level things with, and how joyful that is to navigate and use has a lot, if not everything, to do with how things are named.
LLM are great at creating code, obviously, but what is your (or anyone's) experience with them making code "better" in that way? Finding patterns in messy things and making it more "tidy", renaming things to be less verbose yet still descriptive, or even more descriptive, that sort of thing? Where you can "apply" agents to a codebase and have it come out more accessible to LLM and humans, because it's better code and less of it, if you will. I know rewriting things is more enticing and often more practically useful, but are there efforts/experiment in that direction? With actual code I can look at, comparing before and after?
I agree it would be nice to see some more formal experiments in this space but you can very easily experiment with this yourself. I had Claude rewrite a C++ simulation code to better adhere to the C++ core guidelines and it did a good enough job. Hard to quantify how good it did...
It's not about blaming a person, it's having a person or organization that has reputation to lose or gain and resources to fix it. Responsible AI coding usage increases both velocity and quality, but it's very easy to have issues become the responsibility of nobody.
I think it definitely breaks the "locus" of knowedlge acquisition. You know this dev worked on this component and can tell you about it.
That's not true anymore. All handoffs are "hard won" and everyone gets silo'd.
This stuff is supercharging my development because I'm unaccountable and I choose the level of technical intricacy based on what I expect to do with any piece. All the user facing stuff is not going to matter. Whoever comes after me will have docs, tests and code, but will need to remake the world in which the assumptions are made.
> Software works because someone is accountable for it.
Good joke.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> They are hesitant to take their hand off the wheel because they don’t have full confidence the agents have the right guardrails in place to run off on their own.
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.
I think this blog post is underbaked. I think it misplaces where the tension is, and also the skiing metaphor is attempting to simplify an explanation that's already simple.
The post describes the tension as being between leaders and developers. I don't really think that's where the tension is. I'm on a small team of all senior devs, and I've seen both sides -- skepticism and full embrace, and leadership was not pushing AI on us at all. On our team, no matter where we're each individually at on adoption, we're all pretty clear-eyed about the upsides and downsides. The upside is absurdly fast code production. The downside is losing touch with every line of code in the codebase.
There's no need to introduce the skiing metaphor, because the problem is simple: it's the devs' necks on the line when the system goes down or a customer record goes missing. When you get a call at 4 in the morning from the CEO, "Let me ask someone (AI)" isn't an acceptable answer. It's your job to know the failure modes like the back of your hand and be able to diagnose and rightsize in minutes. We've spent our whole careers guarding against those failures by agonizing over every line of code that goes into the product. With that understanding, it's pretty obvious why senior devs are hesitant to adopt something new without a clear picture of how they can be sure that the program isn't going to go down under load, isn't going to drop or mangle customer records, and when one of those things inevitably does happen, how to recover quickly. In a nutshell, job #1 for a senior dev is to account for every failure, and this becomes much harder when an automated system is pushing through 10x as much code.
I'm one of the devs who has chosen to adopt AI. As I reflect on that, I think the reason I'm willing to do so is because I have a level of certainty that I can work the pipeline to safely introduce more changes, faster. So far, I am getting mixed results, but that's not deterring me from continuing to try to reach an optimal point on the tradeoff curve.
A business ending software failure or security breach can occur from a single feature flag variable or 'minor' parsing bug. Usually its a long sequence of these, but it only takes one.
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.
Because LLM's can do amazing things, but they can also make huge blunders. Claude constantly makes incorrect assumptions, or implements the wrong thing, or claims there is a bug when there is not.....
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.
That's a strawman (or at least a weakman): only a very small number of people (perhaps overrepresented online) thinks current agents are superhuman at programming in practice.
Which is of course not the same group as those who expect new models to become superhuman in months/years.
I'm responding to the push to rebrand it as Super Intelligence coming from people in power (not just the current occupant of the White House). Whether or not they believe it to be super human, they seem to want us to see it that way.
And of course the whole point of tools is being superhuman, compared to humans without those tools. E.g. compilers are better than humans at converting C into assembly. "Just a tool" doesn't mean much.
This is why, to me, it's more interesting to ask the question "how are good devs attaining outsized successes with AI" than "why are good developers wary of AI?"
Yes, there are real reasons to be careful, but that's already obvious to everyone in the field. The real gold is in discovering how successful devs are managing these risks while also retaining the benefits.
> 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.
I have a suspicion that eventually you won't have to be a developer to successfully create good software. I do think that familiarity with algorithm design will still help a lot. But ultimately, if your verification, testing, and observability regimes are good enough, the exact implementation shouldn't matter.
What you're not considering is that software implementation is a 2-way street. The process of reading what you wrote both elucidates something more about the problem, and elicits from you some aspects about the program's behavior that you do care about but didn't consider before.
LLMs for many months have been at a level where if you know exactly what you want, you can simply let the LLM bang out an implementation and never have to read it. But outside of simple problems, you probably don't know what you exactly want.
That being said, I've had considerable success ending every prompt with "ask me for any further details that I haven't considered" or some variation thereof.
really depends on what you work on and risk profile of such projects and your level. I'm sure if i worked at a startup just responsible for shipping features as fast as possible, i'd be going all in. At my work, finding good ideas is hard and LLM's help in that regard but you can't move as fast as if you knew what to do. In a small company, there is just an endless amount to do.
I've seen devs who I once considered good veer heavily into architecture astronaut and/or "productivity hacking" territory with heavy agentic use, then invariably start posting like a hyperactive Linkedin marketing feed. I'm not sure what they're doing. I think they're building AI tools for other AI people to do AI things. It's certainly not reflected in consumer products in any way.
lol, the list of issues that guy found (ironically using AI) is so minuscule, this honestly sounds like a ringing endorsement for Tan’s approach. Claude Code found all those issues, and fifteen minutes of Opus 5.5 would have fixed them all. Put an automated review step on your PRs and you’re good.
To be honest, if this is what you consider to be a form of “brain damage”, I suspect you might be using reasoning here motivated more by your skepticism (fear? hatred?) of AI than by your colleagues truly going off the deep end.
Yeah, I almost passed out when reading that there was an empty CSS file and that some images lacked descriptions. How will the world survive such horrors? /s
This is also my experience in my own bubble. Even my friends who were skeptical for the longest started finding ways to perform cool cross-org work with them and accelerate their coding.
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.
The problems is the best devs aren’t the ones doing all the work. You have shitty devs too who are barely thinking or checking anything mixing slop code in with what whatever the best devs are doing, so it all eventually turns to shit.
The job of the best devs is to build the system ("the harness") that let's anyone build near their level of competency by unloading their heuristics into the harness. That is what the most senior, most talented devs on the team need to be doing so that the baseline gets lifted across the board.
that's a pointless endeavor. The seniors should just be building everything, not wasting time working on a harness that won't guarantee results anyway.
The seniors shouldn't be building the product; the product team can build the product directly. There is no reason for a product manager to ask a senior engineer to fix the spacing or update the tab sequence for some workflow. The harness should be sufficient for them to do at least that. Get it right and a product manager should be able to build whole features if enough of the heuristics and system level constraints are in place.
and if this trend will continue the good ones increasingly aren't going to be working either. hopefully they realize they are getting themselves there by cooperating
> How much can we trust a system when nobody has experience of building it this way?
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?
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.
Probably at a point where my worries will be when my team of construction robots finishes my villa, rather than whether companies are prepared to ditch source code.
I think some definitely are. Especially if there is a system that sits on top of that and pokes and prods the binary to see if it behaves like it's supposed to.
Exactly! I wouldn’t be surprised if some day in the distant future, that’s where this all goes. Coding languages may in fact be on their way to being dead. You can imagine a world where, regardless the platform, the lowest level instruction format is output.
I can see a future generation of models. For now, LLM's train on human artifacts and they handle Python/TS well because of the overwhelming amount of code they've seen, combined with the semantic labels high level languages use that they rely on for reasoning.
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
How would we train those LLMs? Feed them binary executables along with their business requirement docs? Is the corpus of training data large enough to be effective? What happens when a new CPU architecture is developed? Where would the training data come from for the new machine code?
Exactly! That's why the "pelican riding a bicycle SVG" test is unfair. It's a token predictor, not an intelligence. What corpus of SVG data has the LLM been trained on? Only in the last 10 years has "drawing using data" been in existence. Midjourney can generate you a pelican riding a bicycle artwork easily. But instead, if the test is intentionally based on a task with no corpus, then you get garbage.
When people install npm packages, they typically only install ones the community trusts. These packages have clear APIs, open source, good docs, test coverage, security checks, and, importantly, usually no undocumented side effects.
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.
Gary Tan has said markdown is code. Personally I see my job as establishing the architecture, creating tests, lint rules, etc. for my agents. Monitor the code, but if there's an issue create a new agent that monitors performance, etc.
Feels like the obvious reason is that you don't have the mental map usually created by figuring out and writing the code yourself. So, not only is it annoying to debug AI generated code, but you're left trusting that the system didn't sneak something in that you don't know about.
You can definitely help limit this issue by having clear instructions for how the AI should work, but there's just a feeling you're telling someone else what to write, while being left on the hook for it if anything goes wrong.
That and a lot of developers like programming, and vastly prefer to it to the alternative process of "acting like a virtual manager".
"agents" are useful for people operating in domains they don't know or understand, and not for people who do. Or at least I've never seen a task in a field I'm comfortable in, improved by either "AI" or "an AI agent". Made worse, yes, but not improved.
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.
If you've been a tech lead of a group larger than, say, 10 people, you'll know the feeling of not having enough time to review all the code changes. But still, you're expected to and usually can contribute to important directional decisions. You have some confidence in being able to smell issues from patterns of software behavior. I think it might be people with that experience who tend to be more comfortable in delegating more to agents. That seems like the more likely predictive factor to me than "good" vs "bad" developers.
Good developers know that AI isn't necessary at all and no software got better since AI generated code. In fact it got worse.
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.
This joke is made a lot but I think most good developers take care in considering the npm dependencies they install. You can get a ton of dependencies pretty easily by just installing very popular ones like react, tailwind, nextjs, etc. If there's ever a dependency that I'm not familiar with then I make sure to take at least a cursory look over the repo to make sure it has a decent number of stars/community, is well maintained, has multiple contributors, etc.
That is great, but the reality is that your OS, the productivity software you use daily, and the dependencies downstream of the ones you review, are not actually being checked by you for code quality.
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.
I didn't mention the code once in my reply. Code is only one aspect of reviewing a dependency. Much more important is the community and support around the tool/dependency.
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.
Beyond ongoing support, community/number of contributors doesn't indicate anything, though?
And maintainability is a function of code, as it relates to humans, so it is a measure of the code itself.
One of the things I've actually seen companies considering (due to supply chain compromise attacks), is not just having an in-house package repo that trails public versions, but instead fully in-housing critical dependencies and essentially making them private forks that they (probably use LLMs to) maintain.
Basically cutting out the Chainguard-like companies that made private deps their business model.
You can argue that correlation doesn't imply causation, but typically more contributors means more people who have played a part in the code and so more eyes on the project to catch issues as well as a higher bus factor and less key person risk.
And larger community means there's more rewards for a successful attack and therefore fewer latent security issues (ie, obvious ones are more likely to be caught).
I think companies considering building in-house packages are just trading one risk for another. Especially with LLMs, it's going to be a lot easier to find vulnerabilities in your internal dependency than it would be in a battle hardened dependency used by 100s of others.
Honestly, I see good points in both of your comment sets.
But there really is a floor on how deeply a person can understand their own software. There has to be a "good enough" somewhere. As a C# dev, I can understand my entire codebase pretty deeply. And I've read enough of the .NET Core framework to understand some of the nuances of how a lot of the methods we rely on every day are implemented. But I've never once looked at the CIL that Roslyn has produced, and certainly not inspected the machine code that the runtime has compiled. I can't read or write Assembly. I don't really know anything about the x86 or ARM instruction sets. My understanding of the CPU is barely better than "it's transistors," and even lower than that, I have a vague awareness that neutrinos from space can flip bits and there are error correcting mechanisms for that, but I have no idea how they work. And yet, I'm able to write fast and reliable software.
There are super knowledgeable devs out there who pretty much DO understand the whole thing, but it's impossible to memorize every line of every version of framework that you're using or the unique alterations and upgrades to every piece of silicon that your program will run on, and as you guys pointed out, proprietary operating systems are basically completely opaque to our understanding.
So the question is really "where is the practical floor that you stand on?" And for me, personally, there is room for at least some areas of code at the application level that I'm OK with never having read myself.
I think the person above is stating that this is distinguishing characteristic of "good" developers. By extension, the ones you are referring to are not good.
We need to build systems where trust in the code is not needed.
I don't trust the JavaScript code I run in my browser, I don't need to.
A language with a strong enough type system and effects system could say, "this function updates the users preferences, and may not access the network, and may not access data from other users", and the compiler can ensure these constraints AT COMPILE TIME! Provably correct code.
That's a strawman argument. I'm just saying that we need to find ways to wrangle the mountains of code coming out of LLMs into something we can trust, as best we can.
Where do you find these guys? I haven't worked on a project with more than 20 dependencies, and usually those dependencies have 0 subdependencies so they're quite easy to audit.
Not sure how you operate, but I've never worked on any project in my 10+ years as a professionally employed JS dev where we've shipped Jest in our release.
I don't audit all the code I run (I don't think anyone does), but I do audit all the code I _release_. What's actually important to you?
That's a fair point, and with newer package managers, at least the dependencies no longer automatically execute build scripts on install.
There were a few common sources of large runtime dependencies in the past. Like the browserify Node polyfills, babel-polyfill and runtime with core-js, React -> fbjs, Material UI -> JSS and plugins, styled-components.
It's also not trivial to tell whether a dependency you listed under devDependencies is actually imported and consequently bundled into your production build.
Since today we no longer need polyfills and the modern stack with Vite etc. doesn't have a sprawling dependency tree, I think things are now looking much better.
You don't have to ship a dependency for it to be a vulnerability; the shai hulud worm was attacking dev machines and cicd environments to steal credentials. The deps you run are absolutely just as critical.
They're not. But some of them are! And it comes down to knowing how to work with agents in the best way. A good developer -- all in on Agentic development or not -- still knows precisely where to review, pause, rewrite, spike, and so on and so forth. I just don't see the problem here.
It seems to me as a management problem, not a tech problem.
You can delegate responsibility, not accountability.
This is a key principle in management, and usually what makes people progress in their career: if you take accountability for the failures, you also own the successes.
As I see it, if someone is pushing accountability down the chain, they are not the leaders you want.
Also asking why and poking holes in their responses. You get to keep learning and it helps keep them grounded since they otherwise enter a self-reinforcing loop.
My experience as a senior software engineer is that generative AI is an incredible productivity boost for engineers that know what they need to implement. If I need to write a new service, I'm going to be able to do that extremely quickly with Claude Code or some other agentic tooling as long as I know what I want.
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.
Not wary really, but I do tend to micro manage the agent.
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.
There's agentic development where you've designed, even at a high level what the goals and constraints are. Within reason, as doing 10 things at once is not compatible with actually thinking about a problem, no matter what your Adderall says.
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.
> Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production...I always felt there was something else, another fear hiding behind those obvious ones.
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.
> 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.
For me this is the big one. When you code by hand something (especially at the start of a project / feature), it gives you times and opportunity to evaluate different approach, like data-structure or overall architecture. When you're given agentic-generated code to review, those choices are already been made implicitly by Claude, and while it give you the impression that you understand the codebase, you actually haven't been able to process the tradeoff.
Of course, not 'hand-generated' code has the same ROI, and when you're about to do something derivative of something you already understand, agentic development is truly a huge productivity gain.
For me this is the difference between 'vibe coding' and 'coding with AI': Am I able to predict in advance the code that Claude is going to generate, and more importantly, am I able to be surprised when Claude doesn't generate the code I thought it would have (sometime for good technical reasons), or am I just looking at plausible-looking code diffs, and accepting thing without being able to understand the impact on the rest of the codebase. This for me is way more important than what percentage of code lines have been generated by AI.
I've had the opportunity to try both approach: one where I was given a vibecoded project and told to maintain it with Claude: I knew the details of some features, but haven't worked with the codebase enough to really understand the architecture, or be able to mentally reason about the codebase when I'm asked a question during a meeting.
On the another re-implementation of the same product, I've been given more leeway to develop how I wanted, so I've handcrafted the first few features in a transversal way (handling the file architecture, the routing, the way data and components are splitted, and how the API calls are handled), and then I've used Claude to generate the other feature (most of them I knew to be derivative of the first one). In the end something like 90% of the code is generated by Claude, but the end result is both much simpler because I knew where things should be simple and where edge case where, and most importantly I trust what I've put in production.
Do you review and understand every byte of machine code being generated by your compiler? Do you understand all the implications of how it could interact with the underlying hardware, pipelining and prediction, etc?
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?
Not OP, but the issue for me is that for the longest time doing software development meant translating potentially nebulous requirement into strict computer logic.
The process of creation is often a back-and forth between that fuzzy concept in your head (or an natural-language spec that is often ambiguous), and the (usually reduced) physical object / drawing / computer program you've created to materialize this idea. That imperfect projection of your initial idea then helps you refine what this idea implies, and what are the different tradeoff you could take [0].
That back-and-forth has to be made when writing the computer code, even if it's going to be compiled after, because code needs to be detailed enough to force you into expressing the desired behavior with clarity. Prompting Claude on the other hand usually means that you let the LLM resolve this ambiguity for you.
In some case the details don't matter, and it's a productivity gain, and in other case the devils are in the details, and you've let Claude make important technical decision for you, even though Claude doesn't know how much those decision match the needs of the project.
Personally I think of my role as a software developer as someone who know technical possibility (and technical limitations), and weight the different tradeoff it implies to propose code that solves a business problem. And that's the crux of the issue with only creating code by prompting Claude Code: it gradually robs me of my ability to understand the technical possibility and limitation of the system.
[0] This idea has largely been taken from the very good book "Sketching User Experiences: Getting the design right and the right design", about the processus of ideation / sketching.
And, for what I do, Python web apps, it's almost never a problem. It doesn't affect runtime performance, accuracy, maintainability, or bug frequency except in the rarest of cases. Finding non-determinism is even rarer. And, in almost all adverse cases, it would be considered a bug.
I therefore find your suggestion to compare machine code and LLM output questionable. I find them qualitatively different paradigms, not simply another step up in abstraction.
You can’t abstract away the need to capture requirements in a symbolic language. It doesn’t matter which programming or formal language you choose to specify your requirements in, but it cannot be natural language.
Nah, good developers are wary of agentic development because they have a high degree of understanding and intentionality for their designs. And they see how it easily becomes a crutch for a lack of understanding or intentionality.
> 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.
Indeed, I think skills are like muscles... you need to keep using them well to stay strong. If you farm out all your thinking to an AI, your own skills and knowledge will diminish and your ability to design/debug/reason about your own (or any) code can fade.
as has happened time and again through history. software development skills will fade as models become genuinely better at creating, designing, architecting, engineering, testing, validating code at the level of fully complete products.
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.
Making a custom household object requires time, effort, and expense. Especially if you want it to be nice.
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.
Is there a reason you seem to believe this "jank" in the AI software world will stay the same forever? The policies, testing and general knowledge of the professionals are part of what's training the AI models... accurately passing all necessary software standards/certifications/policies are just a few (near future) prompts away.
> Once this done, where will the general knowledge to train AI come from?
I think this assumes that all professionals will eventually disappear and be replaced entirely with AI, and I don't agree with that.
The existence of AI does not dictate that developers can or will no longer exist (and not everyone will even use AI). I think we will still have enough data to train from... and if not, then the AI simply won't be used for that and people will learn again the old fashioned way.
I'd push back on the use of the term "good developers" here. Since the beginning of software development, software developers have had to adapt to ever changing technologies. The good ones adapt, and the bad ones fall off. A person could say that they were great at writing assembly back in the 70s or 80s, but almost nobody writes straight assembly nowadays, and if they do it's usually written as inline assembly. The environment has once again changed, and agentic coding is the change. The actual good developers will use coding agents to complement their skills and write better code faster, while the ones who can't use or refuse to use coding agents will fall off.
Also the article mentions "senior engineers", the term "senior" is thrown around so much these days — along with the term "engineer" — that it's beginning to lose all meaning. Everyone is a senior after 2 years of software development it seems. Honestly if a group of "senior" "engineers" and infrastructure consultants couldn't get an application working in a week with agents behind their back, I would doubt their expertise. Maybe that airline application is super complicated, but it looks like they let the agents run hog wild without any oversight, which no shit they didn't get a working application in a week. Anyone who has used agents for coding knows you can't do that and expect good results for anything more than a toy application. Also I didn't see a mention of which agents they used, they are far from equal. They could be using Claude Haiku on low effort for all I know.
I think this experiment would have been more interesting with 3 teams: One team with no agents allowed, one team who do full on vibecoding like it seems in this article, and the last which uses agents to complement developers.
For me it breaks the rule of "Network of trust".
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.
> Software works because someone is accountable for it.
When software works, it's because there were layers of measures to ensure quality. In order to set up and maintain those measures, you need to establish accountability for quality, not for individual changes.
In fact, given that making mistakes is perfectly human, I would argue that insisting on accountability for individual changes is counterproductive. Since I'm a grumpy old fart, I'll illustrate what I mean with a story ;)
At one of the places I've worked, there was this workplace survey they would do twice a year, one of those anonymous surveys where they give you a bunch of statements and have you select options ranging from "strongly disagree" to "strongly agree". One of the questions that has stuck with me was "on my team, it feels safe to make mistakes".
For the first couple of years or so, I didn't really grok the deeper meaning of that question. I simply interpreted it as "my team is forgiving of minor fuck-ups" and didn't think more about it. I'm not sure what made it click, but one day I realized that it's not just about not working under a martinet. It's about minimizing the chances of a mistake causing problems and maximizing the ease of recovery from such problems if they do occur.
Being able to point a finger at me or one of my teammates and say "this is the person that screwed up" is not what makes software work.
I don't think pairing, nor TDD come anywhere close to the abdication of responsibility that agentic programming does.
How does opensource software work when nobody is accountable when I run software from GitHub?
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.
Open source projects themselves have reputation, regardless of how they are governed specifically.
Yes, you look at stars, issues and activity to infer trust, but there is no accountability, the licenses are clear about that that software is distributed as is
This comment makes me despair. Pair Programming and TDD, as well as other aspects of Extreme Programming, were explicitly introduced as practices that put the human, with needs and feelings, at the center of the software development process. Your analogy is wildly off base, so much so that I suspect a trolling attempt (if that's the case, well played)
They have a HN history going back nearly a decade (pre-LLM) with comments mostly not looking like trolling to me. My first guess would be that they've just been exposed to a bad implementation of Pair Programming and TDD (or even a "good" implementation in an environment where it's not a good fit), and that's where they developed those opinions.
TDD especially has a lot of critics. Some of that's justified. Some of it is just a difference in thought methodologies (e.g., a fraction of developers "think" through a problem by writing code, and the "tests" mandated by TDD physically can't meaningfully appear till after some implementation has happened). If a rando developer thinks negatively of it, that's not news to me. If they haven't tried it much and misattribute the exact cause of those negative opinions to be able to form a nice story-centric through-line, that's also not surprising. I'd be much more inclined to believe they're a developer who you disagree with than a deliberate troll. Who knows.
100%. It's the accountability that I find most compelling.
My AI assisted software has far FEWER bugs than when I hand-coded everything.
Why? I use it to improve and augment my judgement, rather than replace it. Critical analysis, rapid PoC spikes, more tests, more documentation. Half the tests may be superfluous, and the documentation might be overly verbose...but there are more good tests, and the documentation is at least PRESENT and consistent.
I don't get this comment, you say it breaks trust because it's unknown who is accountable, and then you say you (the author) is accountable. So where is the trust broken?
Also your examples are wrong, regardless of pair programming or TDD, there is always a single committer, who is to be held accountable. How you achieve that commit in the past, copy-pasting from stackoverflow, or some auto-expand snippet automation from the IDE - so any tooling - does not matter. Agentic development is also such a tool, thus does not change trust.
The agent runner, or committer, a single human, is to be held accountable. That responsibility is - and always was - the most important role of a programmer.
Putting pair programming and TDD in the same box as agentic development (with, as you assume, zero review of the code) seems...
I am wondering if a combination of broader/deeper observability attach and synthetic user monitoring can help offset some of this. This may just displace and not mitigate the trust issue, but it seems like a valid product direction for the harness layer given falling token costs.
I started thinking about agentic programming from a totally different perspective.
Personal accountability in software development is actually hard, and less useful than it seems. What good is it if you discover a 12 y.o. vulnerability and can blame a specific person? (Like the recent one in PHP?) You may learn the name of that programmer who made the mistake, but it does not really tell you anything about that person, unless their overall record is terrible, and you are not entitled to any damages anyway.
In closed source, this is even worse. So a certain Windows function sucks. Now what. You never learn any other provenience than "Microsoft did it". Tough luck even getting support, and you certainly don't get your license fee back. This sort of accountability is worse than useless.
The only exception I see is knowledge within a specific development team. We usually know what sort of errors our colleagues are prone to, and we may be able to work around their personal weak spots.
Agentic coding done well has a dimension of trust that human coding cannot achieve. I can tell my agents to aim for 100 per cent test coverage without overburdening them or running out of budget and time. I can ask other agents and other models to review code written by the first agents, and then again. Every layer of such review adds some credibility to the result, and its mechanistic character ensures certain level of repeatability. Sure, it can happen that all involved mechanisms share the same weakness and let a particular bug through. But it is similar to several sieves over one another lining up perfectly to let something through, and that is quite rare.
If I had to choose, I would trust code designed, implemented and reviewed by three different SOTA models over code designed, implemented and reviewed by three median programmers today. Three elite programmers would have been a different story, but that would also be expensive like hell, and much like you don't eat most of your dinners in a Michelin restaurant, you have to economize with your code development in a similar way.
For me programming is about reducing complexity, in one way or another. By reducing needless CPU cycles or RAM, or by reducing the complexity of the code when I read it, making it "more logical", which is of course in tension with what would be the absolute most optimal (e.g. perfectly optimized assembly for everything). You make low-level things to turn into higher-level functions to do even higher level things with, and how joyful that is to navigate and use has a lot, if not everything, to do with how things are named.
LLM are great at creating code, obviously, but what is your (or anyone's) experience with them making code "better" in that way? Finding patterns in messy things and making it more "tidy", renaming things to be less verbose yet still descriptive, or even more descriptive, that sort of thing? Where you can "apply" agents to a codebase and have it come out more accessible to LLM and humans, because it's better code and less of it, if you will. I know rewriting things is more enticing and often more practically useful, but are there efforts/experiment in that direction? With actual code I can look at, comparing before and after?
I agree it would be nice to see some more formal experiments in this space but you can very easily experiment with this yourself. I had Claude rewrite a C++ simulation code to better adhere to the C++ core guidelines and it did a good enough job. Hard to quantify how good it did...
It's not about blaming a person, it's having a person or organization that has reputation to lose or gain and resources to fix it. Responsible AI coding usage increases both velocity and quality, but it's very easy to have issues become the responsibility of nobody.
I think it definitely breaks the "locus" of knowedlge acquisition. You know this dev worked on this component and can tell you about it.
That's not true anymore. All handoffs are "hard won" and everyone gets silo'd.
This stuff is supercharging my development because I'm unaccountable and I choose the level of technical intricacy based on what I expect to do with any piece. All the user facing stuff is not going to matter. Whoever comes after me will have docs, tests and code, but will need to remake the world in which the assumptions are made.
[dead]
> Software works because someone is accountable for it.
Good joke.
> THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
> They are hesitant to take their hand off the wheel because they don’t have full confidence the agents have the right guardrails in place to run off on their own.
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.
[1] - https://tinyurl.com/orchestration-imperative
[flagged]
I think this blog post is underbaked. I think it misplaces where the tension is, and also the skiing metaphor is attempting to simplify an explanation that's already simple.
The post describes the tension as being between leaders and developers. I don't really think that's where the tension is. I'm on a small team of all senior devs, and I've seen both sides -- skepticism and full embrace, and leadership was not pushing AI on us at all. On our team, no matter where we're each individually at on adoption, we're all pretty clear-eyed about the upsides and downsides. The upside is absurdly fast code production. The downside is losing touch with every line of code in the codebase.
There's no need to introduce the skiing metaphor, because the problem is simple: it's the devs' necks on the line when the system goes down or a customer record goes missing. When you get a call at 4 in the morning from the CEO, "Let me ask someone (AI)" isn't an acceptable answer. It's your job to know the failure modes like the back of your hand and be able to diagnose and rightsize in minutes. We've spent our whole careers guarding against those failures by agonizing over every line of code that goes into the product. With that understanding, it's pretty obvious why senior devs are hesitant to adopt something new without a clear picture of how they can be sure that the program isn't going to go down under load, isn't going to drop or mangle customer records, and when one of those things inevitably does happen, how to recover quickly. In a nutshell, job #1 for a senior dev is to account for every failure, and this becomes much harder when an automated system is pushing through 10x as much code.
I'm one of the devs who has chosen to adopt AI. As I reflect on that, I think the reason I'm willing to do so is because I have a level of certainty that I can work the pipeline to safely introduce more changes, faster. So far, I am getting mixed results, but that's not deterring me from continuing to try to reach an optimal point on the tradeoff curve.
A business ending software failure or security breach can occur from a single feature flag variable or 'minor' parsing bug. Usually its a long sequence of these, but it only takes one.
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.
Because LLM's can do amazing things, but they can also make huge blunders. Claude constantly makes incorrect assumptions, or implements the wrong thing, or claims there is a bug when there is not.....
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 almost like LLMs are another tool with strengths and weaknesses rather than a super human intelligence.
Its exactly what it is, a tool. Use it correctly it works fine but if you are not careful you can shoot yourself in the foot.
> rather than a super human intelligence
That's a strawman (or at least a weakman): only a very small number of people (perhaps overrepresented online) thinks current agents are superhuman at programming in practice.
Which is of course not the same group as those who expect new models to become superhuman in months/years.
I'm responding to the push to rebrand it as Super Intelligence coming from people in power (not just the current occupant of the White House). Whether or not they believe it to be super human, they seem to want us to see it that way.
And of course the whole point of tools is being superhuman, compared to humans without those tools. E.g. compilers are better than humans at converting C into assembly. "Just a tool" doesn't mean much.
I’ve seen the opposite. The best devs are aggressively embracing agents - producing more, and at higher quality.
This is why, to me, it's more interesting to ask the question "how are good devs attaining outsized successes with AI" than "why are good developers wary of AI?"
Yes, there are real reasons to be careful, but that's already obvious to everyone in the field. The real gold is in discovering how successful devs are managing these risks while also retaining the benefits.
Maybe good devs attain success with agents because they are wary of it, keeps them on their toes while maintaining a productivity boost.
From the article:
> 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.
I have a suspicion that eventually you won't have to be a developer to successfully create good software. I do think that familiarity with algorithm design will still help a lot. But ultimately, if your verification, testing, and observability regimes are good enough, the exact implementation shouldn't matter.
What you're not considering is that software implementation is a 2-way street. The process of reading what you wrote both elucidates something more about the problem, and elicits from you some aspects about the program's behavior that you do care about but didn't consider before.
LLMs for many months have been at a level where if you know exactly what you want, you can simply let the LLM bang out an implementation and never have to read it. But outside of simple problems, you probably don't know what you exactly want.
That being said, I've had considerable success ending every prompt with "ask me for any further details that I haven't considered" or some variation thereof.
I'd lean similarly, but those regimes you list aren't likely going to be done by accident.
Oh, you are 100% correct about that.
really depends on what you work on and risk profile of such projects and your level. I'm sure if i worked at a startup just responsible for shipping features as fast as possible, i'd be going all in. At my work, finding good ideas is hard and LLM's help in that regard but you can't move as fast as if you knew what to do. In a small company, there is just an endless amount to do.
I've seen devs who I once considered good veer heavily into architecture astronaut and/or "productivity hacking" territory with heavy agentic use, then invariably start posting like a hyperactive Linkedin marketing feed. I'm not sure what they're doing. I think they're building AI tools for other AI people to do AI things. It's certainly not reflected in consumer products in any way.
To be honest, I'm starting to get the feeling that heavy AI use gives you a form of brain damage. See also: https://www.fastcompany.com/91520702/y-combinator-garry-tan-...
lol, the list of issues that guy found (ironically using AI) is so minuscule, this honestly sounds like a ringing endorsement for Tan’s approach. Claude Code found all those issues, and fifteen minutes of Opus 5.5 would have fixed them all. Put an automated review step on your PRs and you’re good.
To be honest, if this is what you consider to be a form of “brain damage”, I suspect you might be using reasoning here motivated more by your skepticism (fear? hatred?) of AI than by your colleagues truly going off the deep end.
Every single bullet point is an eldritch horror story.
Yeah, I almost passed out when reading that there was an empty CSS file and that some images lacked descriptions. How will the world survive such horrors? /s
This is also my experience in my own bubble. Even my friends who were skeptical for the longest started finding ways to perform cool cross-org work with them and accelerate their coding.
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.
The problems is the best devs aren’t the ones doing all the work. You have shitty devs too who are barely thinking or checking anything mixing slop code in with what whatever the best devs are doing, so it all eventually turns to shit.
The job of the best devs is to build the system ("the harness") that let's anyone build near their level of competency by unloading their heuristics into the harness. That is what the most senior, most talented devs on the team need to be doing so that the baseline gets lifted across the board.
that's a pointless endeavor. The seniors should just be building everything, not wasting time working on a harness that won't guarantee results anyway.
The seniors shouldn't be building the product; the product team can build the product directly. There is no reason for a product manager to ask a senior engineer to fix the spacing or update the tab sequence for some workflow. The harness should be sufficient for them to do at least that. Get it right and a product manager should be able to build whole features if enough of the heuristics and system level constraints are in place.
It won't be long before the best devs are working and the shit ones are not
Assuming management has the ability to tell the difference and not just count lines of code or commits.
You're assuming that management cares about having good software more than it cares about replacing developers with a machine.
and if this trend will continue the good ones increasingly aren't going to be working either. hopefully they realize they are getting themselves there by cooperating
How to separate them if the code is already mixed?
this assumes it's easy to differentiate between the two groups.
Yes sir! 100 times this.
> How much can we trust a system when nobody has experience of building it this way?
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?
There is a point to source code:
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.
That's simply not true.
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.
Exactly, at what point do spec files become so precise that they are just another form of source code?
Probably at a point where my worries will be when my team of construction robots finishes my villa, rather than whether companies are prepared to ditch source code.
I think some definitely are. Especially if there is a system that sits on top of that and pokes and prods the binary to see if it behaves like it's supposed to.
Exactly! I wouldn’t be surprised if some day in the distant future, that’s where this all goes. Coding languages may in fact be on their way to being dead. You can imagine a world where, regardless the platform, the lowest level instruction format is output.
I can see a future generation of models. For now, LLM's train on human artifacts and they handle Python/TS well because of the overwhelming amount of code they've seen, combined with the semantic labels high level languages use that they rely on for reasoning.
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
How would we train those LLMs? Feed them binary executables along with their business requirement docs? Is the corpus of training data large enough to be effective? What happens when a new CPU architecture is developed? Where would the training data come from for the new machine code?
Exactly! That's why the "pelican riding a bicycle SVG" test is unfair. It's a token predictor, not an intelligence. What corpus of SVG data has the LLM been trained on? Only in the last 10 years has "drawing using data" been in existence. Midjourney can generate you a pelican riding a bicycle artwork easily. But instead, if the test is intentionally based on a task with no corpus, then you get garbage.
I would not be surprised if we ended up with binaries and Lean proofs.
isnt that kinda like downloading and using software a team you have no knowledge of has produced and released?
All you can go by is 'does it do what it says it does'
Yeah, all these devs pretending you can only trust code you understand, then going and pulling in 1000 random npm deps...
When people install npm packages, they typically only install ones the community trusts. These packages have clear APIs, open source, good docs, test coverage, security checks, and, importantly, usually no undocumented side effects.
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.
> When people install npm packages, they typically only install ones the community trusts.
This is wishful thinking. Devs add in dependencies to do mundane stuff all the time, regardless of provenance.
As others pointed out, the default install for many modern web dev frameworks includes hundreds of dependencies.
Gary Tan has said markdown is code. Personally I see my job as establishing the architecture, creating tests, lint rules, etc. for my agents. Monitor the code, but if there's an issue create a new agent that monitors performance, etc.
I feel like ever since we stopped reading assembly we don't really internalize our codebases.
[flagged]
It's just one "Buy Now" button. How hard could that be? /s
Feels like the obvious reason is that you don't have the mental map usually created by figuring out and writing the code yourself. So, not only is it annoying to debug AI generated code, but you're left trusting that the system didn't sneak something in that you don't know about.
You can definitely help limit this issue by having clear instructions for how the AI should work, but there's just a feeling you're telling someone else what to write, while being left on the hook for it if anything goes wrong.
That and a lot of developers like programming, and vastly prefer to it to the alternative process of "acting like a virtual manager".
"agents" are useful for people operating in domains they don't know or understand, and not for people who do. Or at least I've never seen a task in a field I'm comfortable in, improved by either "AI" or "an AI agent". Made worse, yes, but not improved.
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.
Are they though?
If you've been a tech lead of a group larger than, say, 10 people, you'll know the feeling of not having enough time to review all the code changes. But still, you're expected to and usually can contribute to important directional decisions. You have some confidence in being able to smell issues from patterns of software behavior. I think it might be people with that experience who tend to be more comfortable in delegating more to agents. That seems like the more likely predictive factor to me than "good" vs "bad" developers.
Good developers know that AI isn't necessary at all and no software got better since AI generated code. In fact it got worse.
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 don't trust code that I don't understand, or that I don't know someone experienced has reviewed."
proceeds to install 200 random npm dependencies
This joke is made a lot but I think most good developers take care in considering the npm dependencies they install. You can get a ton of dependencies pretty easily by just installing very popular ones like react, tailwind, nextjs, etc. If there's ever a dependency that I'm not familiar with then I make sure to take at least a cursory look over the repo to make sure it has a decent number of stars/community, is well maintained, has multiple contributors, etc.
That is great, but the reality is that your OS, the productivity software you use daily, and the dependencies downstream of the ones you review, are not actually being checked by you for code quality.
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.
I didn't mention the code once in my reply. Code is only one aspect of reviewing a dependency. Much more important is the community and support around the tool/dependency.
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.
Beyond ongoing support, community/number of contributors doesn't indicate anything, though?
And maintainability is a function of code, as it relates to humans, so it is a measure of the code itself.
One of the things I've actually seen companies considering (due to supply chain compromise attacks), is not just having an in-house package repo that trails public versions, but instead fully in-housing critical dependencies and essentially making them private forks that they (probably use LLMs to) maintain.
Basically cutting out the Chainguard-like companies that made private deps their business model.
You can argue that correlation doesn't imply causation, but typically more contributors means more people who have played a part in the code and so more eyes on the project to catch issues as well as a higher bus factor and less key person risk.
And larger community means there's more rewards for a successful attack and therefore fewer latent security issues (ie, obvious ones are more likely to be caught).
I think companies considering building in-house packages are just trading one risk for another. Especially with LLMs, it's going to be a lot easier to find vulnerabilities in your internal dependency than it would be in a battle hardened dependency used by 100s of others.
Honestly, I see good points in both of your comment sets.
But there really is a floor on how deeply a person can understand their own software. There has to be a "good enough" somewhere. As a C# dev, I can understand my entire codebase pretty deeply. And I've read enough of the .NET Core framework to understand some of the nuances of how a lot of the methods we rely on every day are implemented. But I've never once looked at the CIL that Roslyn has produced, and certainly not inspected the machine code that the runtime has compiled. I can't read or write Assembly. I don't really know anything about the x86 or ARM instruction sets. My understanding of the CPU is barely better than "it's transistors," and even lower than that, I have a vague awareness that neutrinos from space can flip bits and there are error correcting mechanisms for that, but I have no idea how they work. And yet, I'm able to write fast and reliable software.
There are super knowledgeable devs out there who pretty much DO understand the whole thing, but it's impossible to memorize every line of every version of framework that you're using or the unique alterations and upgrades to every piece of silicon that your program will run on, and as you guys pointed out, proprietary operating systems are basically completely opaque to our understanding.
So the question is really "where is the practical floor that you stand on?" And for me, personally, there is room for at least some areas of code at the application level that I'm OK with never having read myself.
>> I think most good developers take care in considering the npm dependencies they install
Evidence?!
No they don’t - developers just fly past installing whatever they need to make the damn thing work.
They don’t sit there thinking carefully about what each dependency means.
I think the person above is stating that this is distinguishing characteristic of "good" developers. By extension, the ones you are referring to are not good.
In other words, no true Scotsman…
I don't think this is the class of developer the article is referencing
We need to build systems where trust in the code is not needed.
I don't trust the JavaScript code I run in my browser, I don't need to.
A language with a strong enough type system and effects system could say, "this function updates the users preferences, and may not access the network, and may not access data from other users", and the compiler can ensure these constraints AT COMPILE TIME! Provably correct code.
Who knew it's possible to simply have perfect vuln-free code!
We security engineers are definitely shaking in our boots.
That's a strawman argument. I'm just saying that we need to find ways to wrangle the mountains of code coming out of LLMs into something we can trust, as best we can.
Probably not the same people.
Where do you find these guys? I haven't worked on a project with more than 20 dependencies, and usually those dependencies have 0 subdependencies so they're quite easy to audit.
Then you probably haven't worked much with JS.
The Jest test runner alone has 250 dependencies in its latest version, and v25 had over 500.
Not sure how you operate, but I've never worked on any project in my 10+ years as a professionally employed JS dev where we've shipped Jest in our release.
I don't audit all the code I run (I don't think anyone does), but I do audit all the code I _release_. What's actually important to you?
That's a fair point, and with newer package managers, at least the dependencies no longer automatically execute build scripts on install.
There were a few common sources of large runtime dependencies in the past. Like the browserify Node polyfills, babel-polyfill and runtime with core-js, React -> fbjs, Material UI -> JSS and plugins, styled-components.
It's also not trivial to tell whether a dependency you listed under devDependencies is actually imported and consequently bundled into your production build.
Since today we no longer need polyfills and the modern stack with Vite etc. doesn't have a sprawling dependency tree, I think things are now looking much better.
You don't have to ship a dependency for it to be a vulnerability; the shai hulud worm was attacking dev machines and cicd environments to steal credentials. The deps you run are absolutely just as critical.
Are you including transient dependencies in that count?
*transitive
Yes 20 total dependencies including transients. If a lib has many subdependencies I take this as a red flag and try to avoid it.
No react then?
https://news.ycombinator.com/item?id=39019001
React has no dependencies: https://www.npmjs.com/package/react?activeTab=dependencies https://github.com/react/react/blob/main/package.json
If you read the first comment on your link, you'd see why you're wrong:
> That's not _React_, that's `create-react-app`
The good devs I know avoid dependencies like the plague.
They're not. But some of them are! And it comes down to knowing how to work with agents in the best way. A good developer -- all in on Agentic development or not -- still knows precisely where to review, pause, rewrite, spike, and so on and so forth. I just don't see the problem here.
I’m weary of the culture of ship it if it passes tests even if someone (a reviewer) has concerns
It seems to me as a management problem, not a tech problem.
You can delegate responsibility, not accountability.
This is a key principle in management, and usually what makes people progress in their career: if you take accountability for the failures, you also own the successes.
As I see it, if someone is pushing accountability down the chain, they are not the leaders you want.
The best style of agentic development is when you tell it "no, you should do this instead". That implies that you have the knowledge to do so.
Non-developers that try vibecoding default to a "yes, and" style.
Also asking why and poking holes in their responses. You get to keep learning and it helps keep them grounded since they otherwise enter a self-reinforcing loop.
Because they are stubborn.
When even Linus is using agents it is time to accept it.
[dead]
[dead]
My experience as a senior software engineer is that generative AI is an incredible productivity boost for engineers that know what they need to implement. If I need to write a new service, I'm going to be able to do that extremely quickly with Claude Code or some other agentic tooling as long as I know what I want.
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.
The question is flawed. First you would need to define "Good Developers".
Everyone's answer is different.
Not wary really, but I do tend to micro manage the agent.
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.
Just because you’re not a good developer, doesn’t mean you can’t be a “good” developer.
[dead]
They are still hanging into the false belief that software quality matters to anyone besides good developers.
You don't get frustrated when things that should work don't?
I do, but increasingly, other people I know don't care. They'll just try again, or maybe they'll just give up on one thing and keep using the product.
My frustration doesn't matter to anyone except me.
After spending a few hours looking at some human written C with daybreak I no longer trust human made code. It's mostly slop.
Because they have a good sense of how things can go horribly wrong.
Why are good developers so wary of agentic development? Because they are good developers.
There's agentic development where you've designed, even at a high level what the goals and constraints are. Within reason, as doing 10 things at once is not compatible with actually thinking about a problem, no matter what your Adderall says.
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.
> Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production...I always felt there was something else, another fear hiding behind those obvious ones.
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.
> 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.
For me this is the big one. When you code by hand something (especially at the start of a project / feature), it gives you times and opportunity to evaluate different approach, like data-structure or overall architecture. When you're given agentic-generated code to review, those choices are already been made implicitly by Claude, and while it give you the impression that you understand the codebase, you actually haven't been able to process the tradeoff.
Of course, not 'hand-generated' code has the same ROI, and when you're about to do something derivative of something you already understand, agentic development is truly a huge productivity gain.
For me this is the difference between 'vibe coding' and 'coding with AI': Am I able to predict in advance the code that Claude is going to generate, and more importantly, am I able to be surprised when Claude doesn't generate the code I thought it would have (sometime for good technical reasons), or am I just looking at plausible-looking code diffs, and accepting thing without being able to understand the impact on the rest of the codebase. This for me is way more important than what percentage of code lines have been generated by AI.
I've had the opportunity to try both approach: one where I was given a vibecoded project and told to maintain it with Claude: I knew the details of some features, but haven't worked with the codebase enough to really understand the architecture, or be able to mentally reason about the codebase when I'm asked a question during a meeting.
On the another re-implementation of the same product, I've been given more leeway to develop how I wanted, so I've handcrafted the first few features in a transversal way (handling the file architecture, the routing, the way data and components are splitted, and how the API calls are handled), and then I've used Claude to generate the other feature (most of them I knew to be derivative of the first one). In the end something like 90% of the code is generated by Claude, but the end result is both much simpler because I knew where things should be simple and where edge case where, and most importantly I trust what I've put in production.
> For me this is the difference between 'vibe coding' and 'coding with AI':...
I think that entire paragraph was insightful and helpful in clarifying something I felt but wasn't sure how to express. Thanks.
Do you review and understand every byte of machine code being generated by your compiler? Do you understand all the implications of how it could interact with the underlying hardware, pipelining and prediction, etc?
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?
Not OP, but the issue for me is that for the longest time doing software development meant translating potentially nebulous requirement into strict computer logic.
The process of creation is often a back-and forth between that fuzzy concept in your head (or an natural-language spec that is often ambiguous), and the (usually reduced) physical object / drawing / computer program you've created to materialize this idea. That imperfect projection of your initial idea then helps you refine what this idea implies, and what are the different tradeoff you could take [0].
That back-and-forth has to be made when writing the computer code, even if it's going to be compiled after, because code needs to be detailed enough to force you into expressing the desired behavior with clarity. Prompting Claude on the other hand usually means that you let the LLM resolve this ambiguity for you.
In some case the details don't matter, and it's a productivity gain, and in other case the devils are in the details, and you've let Claude make important technical decision for you, even though Claude doesn't know how much those decision match the needs of the project.
Personally I think of my role as a software developer as someone who know technical possibility (and technical limitations), and weight the different tradeoff it implies to propose code that solves a business problem. And that's the crux of the issue with only creating code by prompting Claude Code: it gradually robs me of my ability to understand the technical possibility and limitation of the system.
[0] This idea has largely been taken from the very good book "Sketching User Experiences: Getting the design right and the right design", about the processus of ideation / sketching.
No, I don't.
And, for what I do, Python web apps, it's almost never a problem. It doesn't affect runtime performance, accuracy, maintainability, or bug frequency except in the rarest of cases. Finding non-determinism is even rarer. And, in almost all adverse cases, it would be considered a bug.
I therefore find your suggestion to compare machine code and LLM output questionable. I find them qualitatively different paradigms, not simply another step up in abstraction.
You can’t abstract away the need to capture requirements in a symbolic language. It doesn’t matter which programming or formal language you choose to specify your requirements in, but it cannot be natural language.
LLMs can only produce evidence. Producing proof requires a human
Two types of devs: Those who require proof before shipping and those who don't
Devs who require proof are shipping high quality. Devs who don't are shipping slop
One-shotting changes without checking them is highly irresponsible
Because many have built a career and identity on the ability to write code. And confused it with engineering. So it's a hard to swallow pill.
not sure whether I am good developer but for me it is half of
> The easy (lazy?) answer is that they love writing code, or they’re worried about their jobs.
and half of using proprietary SaaS being something I deeply dislike.
Why are good developers so wary of agentic development?
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.
Nah, good developers are wary of agentic development because they have a high degree of understanding and intentionality for their designs. And they see how it easily becomes a crutch for a lack of understanding or intentionality.
> 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.
And they see how it easily becomes a crutch for a lack of understanding or intentionality.
In other words, it "tends to undermine the very process that creates good developers".
Indeed, I think skills are like muscles... you need to keep using them well to stay strong. If you farm out all your thinking to an AI, your own skills and knowledge will diminish and your ability to design/debug/reason about your own (or any) code can fade.
as has happened time and again through history. software development skills will fade as models become genuinely better at creating, designing, architecting, engineering, testing, validating code at the level of fully complete products.
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.
Making a custom household object requires time, effort, and expense. Especially if you want it to be nice.
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.
Is there a reason you seem to believe this "jank" in the AI software world will stay the same forever? The policies, testing and general knowledge of the professionals are part of what's training the AI models... accurately passing all necessary software standards/certifications/policies are just a few (near future) prompts away.
The policies, testing and general knowledge of the professionals are part of what's training the AI models
Catch 22 --- The "professionals" need to be replaced in order to justify the cost of AI.
Once this done, where will the general knowledge to train AI come from?
AI is a self degrading feedback loop.
> Once this done, where will the general knowledge to train AI come from?
I think this assumes that all professionals will eventually disappear and be replaced entirely with AI, and I don't agree with that.
The existence of AI does not dictate that developers can or will no longer exist (and not everyone will even use AI). I think we will still have enough data to train from... and if not, then the AI simply won't be used for that and people will learn again the old fashioned way.
People will simply discount computer science as a viable career option. And it is already happening.
https://techjournal.org/the-great-computer-science-exodus-wh...
>> TL;DR Good developers’ caution about agentic development comes from knowing that built isn’t the same as working in production.
No it’s not about some superior knowledge of how things work in the real world.
Seems to me it’s mostly emotional reaction not logical, which is fine.
The important thing to understand is that emotional reaction won’t change when the tech improves - they’ll still hate AI.
I'd push back on the use of the term "good developers" here. Since the beginning of software development, software developers have had to adapt to ever changing technologies. The good ones adapt, and the bad ones fall off. A person could say that they were great at writing assembly back in the 70s or 80s, but almost nobody writes straight assembly nowadays, and if they do it's usually written as inline assembly. The environment has once again changed, and agentic coding is the change. The actual good developers will use coding agents to complement their skills and write better code faster, while the ones who can't use or refuse to use coding agents will fall off.
Also the article mentions "senior engineers", the term "senior" is thrown around so much these days — along with the term "engineer" — that it's beginning to lose all meaning. Everyone is a senior after 2 years of software development it seems. Honestly if a group of "senior" "engineers" and infrastructure consultants couldn't get an application working in a week with agents behind their back, I would doubt their expertise. Maybe that airline application is super complicated, but it looks like they let the agents run hog wild without any oversight, which no shit they didn't get a working application in a week. Anyone who has used agents for coding knows you can't do that and expect good results for anything more than a toy application. Also I didn't see a mention of which agents they used, they are far from equal. They could be using Claude Haiku on low effort for all I know.
I think this experiment would have been more interesting with 3 teams: One team with no agents allowed, one team who do full on vibecoding like it seems in this article, and the last which uses agents to complement developers.
[flagged]
[flagged]
[flagged]
[flagged]
[dead]
[dead]