Why are good developers so wary of agentic development?
martinfowler.com
martinfowler.com
Software works because someone is accountable for it. Pair Programming, Test Driven Development, and now Agentic coding all to one degree or another damage the network of trust.
- Pair Programming (There is no one person accountable for the change.) - Test Driven Development (The test pass, so my software is good) - Agentic Coding (My prompt was good, so my software is good)
AI is great for software development... As long as you review and understand each change it makes. Because YOU are going to be held accountable for what the software does.
This is the exact mentality behind corporate software and why nobody gets fired for using IBM, Oracle, Azure...
Accountability is a poor proxy for quality because there are so many ways to frame an incident never those responsible really get accountable.
Software works because developers care about the product. If something goes wrong the entire team is accountable, so they work together on something as one.
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.
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?
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.
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.
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.
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.
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.
Mistakes are a cost of doing business with engineering, even the kinda sorta engineering programming looks like. An environment that helps to prevent mistakes from making it through testing and review should be the focus, but I guess there is value in identifying an individual as being especially mistake prone.
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.
You are far, far behind where the industry currently is, and where the puck is moving with statements like that. Check out how pstack (from poteto) handles this, and look at what Spawn (game company) is doing as a couple off the top of my head examples.
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.
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.
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.
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.
What it does speak to me is that only the most senior engineers still have a significant role.
The biggest pocket of skilled holdouts I've noticed are in more artisan spaces where the craft of coding is part of the art. Things like old-school indie game developers where they're still sweating the assembly output and clock cycles.
> they are not hesitant to use a coding assistant, they are hesitant to go all in and let the agents do all the execution.
They are embracing the use of coding agents, but they still want to be in control. That also matches what I see from my most talented colleagues. They outsource certain tasks to the AI and verify the output.
My somewhat unpopular opinion is that only very good developers are able to use AI coding tools somewhat safely. They could have written the code themselves, but it's faster to have the agent do and then verify. The rest of us couldn't write the code, at least not when we start on a project. When we finish, we have some of the skills and could rely more on the AI tools if we were to do it again.
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.
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.
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-...
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.
If humans are no longer reading the LLM outputs and internalizing the codebase themselves, there's no longer much point to source code. The coding assistant might as well take a natural language prompt and directly hand you an ELF binary that passes a test suite. Are companies ready for that?
Also, consider token efficiency. Imagine how many tokens would be torched just translating an import statement of a popular library to its binary equivalent, let alone a big complex program
It makes no sense to remove this information, as it also helps the LLM to make better coding decisions and to apply better abstractions.
Things like classes, macros (as in lisp, not as in C), design patterns, etc. They are all easily expressed in programming languages, and currently compilers are fundamental to help LLM find and fix bugs.
All you can go by is 'does it do what it says it does'
Engineers introduce these packages into their own projects that have far fewer of the above guarantees than OSS, are built under pressure from deadlines, and have a constantly churning set of maintainers.
I think from the perspective of a business its own code does call for greater scrutiny than its dependencies.
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.
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.
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.
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.
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".
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.
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.
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.
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.
proceeds to install 200 random npm dependencies
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 Jest test runner alone has 250 dependencies in its latest version, and v25 had over 500.
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?
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.
Part of using software is just going off how well it works.
When one Linux flavor starts to have issues, most people don't do a dissection on why, they just switch distros. Or web browsers (I've lost count of the back-and-forth between FF and Chrome performance over the years, nevermind all their precursors). Or office suites.
Pretending that the code is what really matters, and not what the code does, is elevating the paint quality over the painting.
When dealing with LLM output, you're getting a 1 of 1. There's no way to measure the community, number of contributors, or how maintainable it is.
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.
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.
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.
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 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.
We security engineers are definitely shaking in our boots.
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.
> 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.
In other words, it "tends to undermine the very process that creates good developers".
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.
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.
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.
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.
https://techjournal.org/the-great-computer-science-exodus-wh...
Non-developers that try vibecoding default to a "yes, and" style.
When even Linus is using agents it is time to accept it.
He has nothing to lose
Some people still have a future to build :)
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.
Everyone's answer is different.
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 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.
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.
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
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.
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 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?
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.
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.
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.
I think that entire paragraph was insightful and helpful in clarifying something I felt but wasn't sure how to express. Thanks.