Forem: Lars Faye | Confident Coding

Agentic Coding is a Trap | Remaining vigilant about cognitive debt and atrophy.

Lars Faye | Confident Coding — Thu, 30 Apr 2026 01:47:47 +0000

"AI does the coding, and the human in the loop is the orchestrator"

This is the sentiment being hyped up around the industry currently: traditional coding is all but dead, and Spec Driven Development (SDD) is the future. You generate a plan, and disconnect from writing any code. The agents know better, and handle all the implementation. You are there as the expert, to provide "good taste", review the outputs, and constantly steer the agent(s) to execute the plan that you meticulously put together.

The workflow takes many shapes at this point, but in general, it is a process where someone defines the project's requirements (simultaneously at a micro and macro level), generates a plan, and then pulls the slot machine lever over and over, iterating and reiterating with often multiple agent instances until it's done. All the while, putting a growing distance between the "orchestrator" and the code that is being generated and committed.

Coding Agents are helpful, and powerful, but there's already some quantifiable trade-offs that need to be discussed:

An increase in the complexity of the surrounding systems to mitigate the increased ambiguity of AI's non-determinism.
Atrophying skills for a wide swath of the population.
Vendor lock-in for individuals and entire teams (Claude Code outages have already had entire teams at a stand-still).
Fluctuating and increasing costs to access the tools. An employee's cost is fixed; tokens are a constantly moving target.

Being successful with this approach to coding agents hinges on a rather crucial element: only a skilled developer who's thinking critically, and comfortable operating at the architectural level, can spot issues in the thousands of lines of generated code, before they become a problem.

Yet, in an ironic twist of fate, it's the individual's critical thinking skills and cognitive clarity that AI tooling has now been proven to impact negatively.

Not Just Another "Abstraction"

A common refrain we hear in the community is that programmers are just "moving up the stack" and into a different type of abstraction. Whether or not these tools are really an abstraction layer in the first place is not a settled matter; a higher level of ambiguity is not a higher level of abstraction.

If we put that to the side though, it is true that programmers tend to be wary of new languages and new ways of programming. When FORTRAN was released, programmers were skeptical of it, too. They had similar claims: it was likely to introduce more bugs and instability, and writing assembly directly was more efficient. Later, there would be discourse around the integration of compilers introducing too much "magic" into the process. These were normative arguments around a fear of what might be lost if these new technologies were embraced.

The difference with what is happening today is that those previous fears were speculative and theoretical. In just the short few years that AI tooling has existed, we are already seeing significant impacts. These aren't just junior developers, but even those with a decade (or more) of experience:

Junior developers are faced with an even steeper climb, as we truncate their ability to work with code and replace it with reviewing generated code. Reviewing code is important, but it's only 50% of the learning process, at best. Without the friction and challenges that come with working with code directly, their ability to learn is seriously diminished.

Studying this phenomenon takes time, so anecdotal evidence is important to gather to get a real-time view of the situation. But it has also been studied, and there are numerous reports reinforcing that this is a real phenomenon.

It actually is different this time.

When a C++ developer moved to Java or Python, they didn't complain of brain fog. When a sysadmin moved to AWS, they didn't feel like they were losing their ability to understand networking.

A Senior Engineer losing their coding edge and becoming "rusty" over time as they move into managerial roles and practice coding less is not a new phenomenon. This was the natural progression of expertise: an engineer who had decades of coding, friction, and experience logged would have the time and experience to solidify those skills and wisdom. And they could apply that wisdom when their job became less about syntax, and more about higher-level architectural decisions. Those individuals are not only exceedingly rare, but you won't get the next wave of seniors if we're all abdicating the friction of writing, problem-solving, and debugging.

What is happening right now is a trend where developers, who've never had that longevity or the 30+ years of friction that led to that deep understanding, are being moved into higher-level workflows requiring the same skills to manage the AI agents that the senior engineer took decades to obtain.

However, Senior Engineers aren't immune, either. Simon Willison, a developer with nearly 30 years experience, has reported not having a "firm mental model of what [the applications] can do and how they work, which means each additional feature becomes harder to reason about"

The "Skilled" Orchestrator Problem

Buried in a recent study by Anthropic was a surprisingly honest moment when speaking about the risks of engaging with coding agents on a regular basis:

One reason that the atrophy of coding skills is concerning is the “paradox of supervision” [...] effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from AI overuse.

Sandor Nyako, Director of Software Engineering at LinkedIn who oversees 50 engineers, has noticed it proliferating throughout the organization and requested his team not to use them for "tasks that require critical thinking or problem-solving."

"To grow skills, people need to go through hardship. They need to develop the muscle to think through problems," he said. "How would someone question if AI is accurate if they don't have critical thinking?"

There is also the question of what constitutes "overuse". We already have evidence, both data-driven and anecdotal, that these skills can atrophy and dissipate rather quickly (within months in some cases).

This is the contradiction that has many AI boosters talking out of both sides of their mouths: The use of coding agents is actively diminishing the very skills needed to effectively manage the coding agents.

LLMs accelerate the wrong parts.

Contrary to the current narrative that is being espoused, we didn’t necessarily need to write code faster. Especially code we didn’t fully understand, and particularly in huge swaths that we couldn't review in reasonable time frames.

Before AI, a (good) developer's priority list might look like:

Understanding of the code and its relation to the codebase
If the code is aligned with the documented and efficient standards
As few lines of code as needed to accomplish the goal (while maintaining readability)
Turnaround time

Agentic coding, and LLMs in general, completely invert this list.

Their capabilities and usage tend to focus on speed by increasing the amount of code that can be generated in a specified time frame. Speed is a natural byproduct of high aptitude. When it's forced, it always leads to lower accuracy. The integration of these tools doesn't tend to focus much on deeper understanding or conciseness.

Can they be used that way? Yes, with determination, they certainly can be.

Are they? No, not really; forced mandates and hype around token usage across organizations is demonstrating as such.

Coding === Planning

There is a divide between developers that isn’t highlighted as much: Some of us plan, and think, better with code. Thinking and working in code isn't just meaningless drudgery; it forces you to think about things on a technical level that involves everything from security to performance to user experience to maintainability.

In a recent interview discussing "Spec Driven Development", Dax, the creator of OpenCode (an open-source coding agent, no less) was quoted saying:

“When working on something new or something challenging, me typing out code is the process by which I figure out what we should even be doing.

I have a really tough time just sitting there, writing out a giant spec on exactly how the feature should work.

I like writing out types. I like writing out how some of the functions might play together. I like playing with folder structure to see what the different concepts should be. And this is all stuff that I think most people—most programmers—have always done. I don't really see a good reason why I would stop that personally, because it's how I figure out what to do.”

What you say is often not what you mean, and LLMs fill in ambiguity with assumptions (or hallucinations), which leads to: more review, more agent revisions, more tokens burned, and more disconnection from what is being created. Inversely, You can marvel at the most beautiful, unambiguous, perfectly structured prompt you've ever written, and the LLM can still output a hallucinated method because it is fundamentally a next-token-prediction engine, not a compiler. You cannot replace a deterministic system with a probabilistic one and expect zero ambiguity.

Even the most AI-enthusiastic senior developers are starting to see this disconnection as a looming and growing issue.

Vendor Lock-In

When I was browsing LinkedIn during the Claude outage that occurred a bit ago, I noticed numerous posts highlighting that certain developers and engineering teams were at a standstill. Their workflows, their own own coding abilities, had already reached a point where they were largely dependent on these vendors. What used to be a skill that they could execute with just a keyboard and text editor suddenly required a subscription to an AI model provider.

You can't predict your token cost.

Model providers are heavily subsidized, and the models themselves are built on shifting sands. Every new model release follows the same pattern of high benchmarks, followed by hype, followed by the reality of usage and everyone complaining of them being "nerfed" and burning through 2x-3x as many tokens to get the same job done.

You know how much your employees cost; you have no idea how much your token costs will be day to day, month to month, year to year. If your entire team is using agentic coding as the default, your expense account will need to remain highly nimble. As Primeagen said recently: "when you use these fully agentic workflows, the model providers essentially own you".

It's not unreasonable to play this pattern forward, where we could be creating an industry where you need to pay for token consumption to accomplish something that used to be the product of your own critical thinking and problem-solving abilities. This would resemble a type of "vendor lock-in", but for an entire industry skillset (and I'm sure the model providers are gleefully rubbing their hands in anticipation for that). The financial, and intellectual, rug-pull could come at any moment, and local LLMs are nowhere near ready to scale to absorb that level of usage.

This isn't theoretical conjecture; it's being reported on right now. Even the model providers themselves are bringing it to light. Yet another Anthropic study showed a precipitous 47% drop-off in debugging skills:

“Incorporating AI aggressively into the workplace—especially in software engineering—inevitably comes with trade-offs...developers may lean on AI to deliver quick results at the expense of building critical skills—most notably, the ability to debug when things go wrong.”

There's a way to avoid all of this, of course. LLMs are a powerhouse technological advancement, and when used responsibly, they can be a stellar tool for learning and upskilling. They enable me to dive deeper and wider into concepts and techniques, expanding understanding and enabling exploration of new ideas that used to be more arduous and time consuming to experiment with. This is where I think they will offer the industry the most long-term value.

My Approach: Demote AI's role

I'm certainly not advocating for typing code out manually. Programmers have always been looking for ways to create code without having to write code. This is why we even have Emmet, autocomplete, and snippets in the first place. Even COBOL was designed to encapsulate more instructions with less writing by using "English-like" words such as MOVE and WRITE. jQuery's motto was "write less, do more". LLMs are another addition to this array of code generation tools.

What I am advocating for, though, is leveraging LLMs and coding agents as secondary processes. A way that doesn't sacrifice the individual's skills at the altar of productivity. You can flip the script and lean on them to brainstorm the planning parts of the process while staying actively engaged throughout implementation, delegating to them on an as-needed basis. You can leverage the productivity gains, and mitigate the comprehension debt.

My daily workflow:

I use LLMs to help generate specs and plans, while I facilitate the implementation. This is an inversion of the "orchestration" workflow; I am still manually coding anywhere from 20% to 100%, depending on the task.
I very often am writing pseudo-code when I do engage with the models, closing the distance between the request and the generated code.
I use the models as delegation utilities for ad-hoc code generation and interactive documentation, as well as research tools so that I can constantly ask questions, iterate, refactor, and gain clarity around my approaches.
I never generate more than I can review in a sitting. If it's too much to review, I slow down and split the task up, manually refactoring where needed to ensure a comprehensive understanding of the end result.
I never ask an LLM or agent to implement something that I've never done before or couldn't do on my own, except perhaps purely for educational or tutorial purposes (and often discarded afterwards).

If I had to TL;DR this list, it would be: Use them like the Ship's Computer, not Data.

(any Star Trek fans should get the reference)

### I'm not going faster, but I'm doing better quality work.

The productivity gains from these models are real, and so is the friction and understanding that come from engaging with the work on a tangible and frequent basis.

Despite the countless failed attempts at trying to democratize coding while not understanding coding, we're faced with the reality that you cannot understand code without engaging with it. And it's become clear that if you don't keep engaging and writing it, you can lose touch with that understanding, which will in turn make you a less capable orchestrator in the first place, rendering this phase of AI coding a strange and needlessly stressful interlude.

Perhaps I am worrying too much, but history contains lessons.

This all feels similar, though, like another large experiment we're running on ourselves. We've been through a similar period with the introduction of social media without understanding the long-term implications, and we're now faced with attention deficit (amongst many other issues) on a wide scale.

This time, we're gambling with something much riskier.

“People who go all in on AI agents now are guaranteeing their obsolescence. If you outsource all your thinking to computers, you stop upskilling, learning, and becoming more competent.”

– Jeremy Howard, creator of fast.ai

Full article can be read at: https://larsfaye.com/articles/agentic-coding-is-a-trap

My AI workflow seems to be the opposite of what the industry is encouraging, and I don't care.

Lars Faye | Confident Coding — Sun, 29 Mar 2026 19:32:00 +0000

The general consensus is that you should spec out your project, requirements, generate a bullet-proof plan, and then implement it via some kind of agent workflow. I've attempted this numerous times, and yes, it works...sort of. It can produce an application to the spec, but the main issue I continuously run into is that it's really hard to think about all the nuances and caveats ahead of time, and its not until I see something start to come together where I realize I need to think about things differently. Any ambiguity and the LLMs fills in with assumptions (or hallucinations).

I can just keep iterating with the agents, but its just more token usage, more code churn, more disconnection from the codebase, and more potential complexity as I am needing to trust the agent to refactor appropriately. It can be done, but I personally find it exhausting and rather annoying.

Lately, I've started to do the opposite, which I'm sure the AI bros would balk at: I use the LLM to generate the plan, and I do the implementation. Especially starting from scratch, deciding how to architect and plan an app out can be challenging, and I often like to see examples of other architectures to help me decide how I want to structure things. In the past, I'd often look for starter repos as inspiration and then begin putting things together after getting some initial direction.

With these AI tools, I can work with them to tailor an architecture and structure that suits my exact needs, plan the entire app, and then...build it myself.

Sure, I use these AI tools alongside to delegate tasks to and implement features on an as-needed basis, but its highly incremental and I'm still "manually" coding a good 50% of the project.

This flies in the face of how I think the industry is hyping things and seemingly the opposite of the "let AI do the coding, you only do the planning & review" workflow, but I really don't care. Anytime I've done that, I could feel the atrophy of my critical thinking setting in within a few days, and feeling like I inherited a codebase rather than helped create one.

Thinking in and working through the project in code isn't just drudgery; it forces you to think about things on a technical level that involves everything from security to performance to user experience to maintainability. Trying to do that while staying in the "natural language" mindset doesn't get specific enough, and specificity is absolutely essential to doing this work successfully.

I'm thinking of putting together a course that focuses on webdev troubleshooting and debugging.

Lars Faye | Confident Coding — Tue, 24 Mar 2026 21:00:48 +0000

I've been in the industry a while (back when tables were used for layout) and I've learned most of what I know through reverse engineering and breaking things/putting back together. I've always had a knack for it, and have helped a lot of developers over the years with tips and tricks I picked up along the way. I've had instances where I've found the solution in minutes that other developers were spending hours on. It's not like I was a better developer, it just seemed I had a process and mental framework whereas they would get overwhelmed on where to start.

My theory is: if developers can be more confident they can troubleshoot problems, they're less likely to feel imposter syndrome. I find I'm at my happiest when I'm being helpful and working with other developers, so I'm moving on something that I've wanted to do for over a decade and put the course together.

I'm working on content, and I'm still proving the concept out, so curious what you guys think. I want to focus on frontend workflows, although IMO, debugging skills are pretty universal.

Landing page: https://confident-coding.com/

Everyone Can Delegate Now | AI is enabling every knowledge worker to learn management skills.

Lars Faye | Confident Coding — Mon, 23 Mar 2026 23:30:32 +0000

Delegating was once reserved for managerial positions.

The ability to effectively delegate and outsource tasks was the primary role of a manager, who had, ideally, already spent time "in the trenches" doing the work they now assign to others.

Compiling data and generating reports, creating slideshow presentations, implementing features per client requirements...this delegation process flowed from the project managers and was distributed across the team.

Delegation was a skill that had to be honed and refined. You would move up the chain and take on higher-level work, orchestrating, rather than doing.

AI tools can empower individuals to learn delegation.

Because of their general ease of use, AI tools have proliferated quickly and we're still trying to pin down exactly what role they can effectively play, and how integrated they should be. The major shift that I have observed in the workplace, however, is that their introduction has created an opportunity where now everyone has the ability to leverage them for delegation, no matter the type or scope of task.

The ability to delegate is an empowering skill to practice. It offers a sense of freedom to the individual who might be facing down an exhaustive list of tasks: they don't have to do it all themselves. They can learn how to manage a workload efficiently because there's a way to relieve some of the pressure.

Tasks that were once required to be completed by an individual (e.g. populating a spreadsheet, drafting an email) can now be outsourced to a system which can loosely emulate human interaction. AI tooling has zero interface learning curve. Anybody can type into a chatbox. Just upload your request, requirements, and documents, and get a response. A draft of a report could be generated while you are on your lunch break, or article topics could be researched while you respond to emails.

Using AI tooling for delegation is different from delegating directly to humans, but there are core similarities:

Analyzing one's own workload and learning how to prioritize effectively
Breaking up large tasks into smaller, actionable pieces
Deciding what can be completed oneself versus what can be assigned to "someone else"

In the past, all these tasks would sit on someone's desk until they were able to get to them. If there wasn't enough time in the day, the work didn't get done (and the backlog grew).

AI delegation is a skill that needs to be learned.

While it's an empowering skill, delegating doesn't come naturally to everyone, and we should not conflate the ease of use of the tool with mastery over delegation as a skill. Delegating to AI in particular comes with some extra "gotchas", as well:

I've witnessed individuals not providing enough guidance and context, resulting in half-baked and incorrect results (this isn't all that different with humans, either!)
I've seen people blindly using responses without verification because they are delegating work outside their domain of expertise
I've worked with people who didn't understand the nature of context window limitations and how to break their task up into smaller pieces, eventually being forced to abandon it and start over

So, while the interface for an AI tool does not have a learning curve, these tools have an element of unpredictability & unreliability, and the responsible party needs to heavily scrutinize the outputs. If someone is not careful, it could end up proving to be more time consuming than doing the task manually (and you end up being more of a "micro-manager" than a "delegator").

Now that everyone has a potential delegatee they can assign work to, this is a skill that will need to be learned by everyone who is in a knowledge work role. The ability to offload some of their responsibilities and tasks and mitigate some overhead can teach essential lessons around management and leadership.

Efficiency breeds expectation.

Still, there are legitimate concerns that it won't reduce workload. When personal computers were rolled out into office spaces in the 70s/80s, the role of the secretary, with the narrow discipline of answering phones and taking messages, transformed to include word processing, electronic filing, spreadsheet management, and print queues. This resulted in a higher workload and more skills to learn.

Giving every individual the ability to delegate their work could create a situation where the increased amount of the 'resource' (an individual's productivity) ends up being consumed at an equal rate, negating any efficiency gains or resulting in burnout.

Delegation is likely to evolve the workforce.

The ability for workers to delegate is a skill that is going to have to be continuously refined over the years to come. For the employer, it should not be an excuse to merely shoehorn more work into a workday, but to reduce stress on the individual and to create space to do better work.

For the employee, whether a manager or a team member, individuals need to be mindful about what they are offloading. If someone delegates all of their workload to others (or to AI tools), they will end up in a "placeholder" role, rendering their own position all the more easy to replace (and creating their own potential cognitive atrophy).

These tools also offer tremendous opportunity in shaping how we can not just get more work done, but get better work done, as the ability to delegate can hone critical thinking, build managerial skills, and give every individual a sense of personal power.

Your Indispensable Value in the AI Era

Lars Faye | Confident Coding — Sat, 21 Mar 2026 18:23:37 +0000

"In a world where the cost of answers is dropping to zero, the value of the question becomes everything."
— Brit Cruise, the AI Paradox

LLMs and their adjacent AI tools have provided us with something truly novel: the ability to ask anything, at any time, and receive an answer. We might have thought Google was playing this role, until these tools showed us that what we had before was a ubiquitous digital encyclopedia, and what we have now resembles a librarian who will attempt to answer any question, regardless of the complexity or the absurdity.

When you have a tool that has all the answers, what value do you have to bring?

It turns out: a whole lot. More than you probably thought, too.

The Question is the Value

If I were asked by someone to describe what it's like be a developer (or programmer, or coder, whatever you identify with), I would describe it as a state of being in which one is ceaselessly asking questions:

Why doesn't this work?
Why does this work?
Is there a better way to approach this?
How can I build this feature?
Should I refactor this code?
What happens if I change X?
How does it behave when I move Y?
What happens if I remove Z?

Turning Blue to Purple

Many moons ago, circa 2010, I was hired to build an eCommerce site using CS Cart, a platform that was still in its infancy (even eCommerce was not that old by that point). During the checkout process, I got an obscure mySQL error, and I wasn't super experienced with SQL at the time, nevertheless something specific to CS Cart.

Off to Google I went, hoping to find an easy answer (spoiler: nope). I quickly turned every blue link I found to purple, with no clear resolution. So, I kept asking.

Each time I reformulated the question, I would get slightly different results, which led to refining the question. I was piecing together jigsaw puzzle without the picture, and each piece showed me the shape of the next piece I should begin sifting through the box for. Each reformulation of the question was another potential shape that could fit.

Eventually, after creating page after page of purple links, I gathered together enough pieces to formulate the actual question that I needed to answer. And once I had that question, the answer was immediate, and self-evident. After a solid day of searching (punctuated with many walks around the block), I found the answer!

Or, more accurately: I found the question.

The answer was the result of the labor, it was the outcome. As Brit Cruise also said in his scintillating video, finding the question itself is the work.

Nothing Is Becoming Simpler

From the introduction of GPT 3.5 to the latest models and tooling, answers are now abundant. Whether or not they are the correct answers...that is a problem that remains unchanged even with the latest frontier models. And it's a problem that is only solveable by those that know the power of asking the right questions.

I realize that with modern troubleshooting tooling and the assistance of AI models, that particular debugging session would have likely been resolved differently, and likely quicker. This is a wonderful turn of events; this is how progress works. That is that is applying an old problem to new tooling, though. The problems we face now are very different, and the challenges we face at any point in time, scale to the complexity of industry.

Programming and development are far more complicated in modern times than they were in 2010, if not just due to the sheer number of abstractions we've created for even the simplest features.

I recently found a great article by Paul Herbert who demonstrates this so effectively:
The Incredible Overcomplexity of the Shadcn Radio Button

For example, troubleshooting a Docker issue is orders of magnitudes more complex than anything I encountered in 2010, because the state of technology to support something like Docker did not exist then, but it does now.

As the tools grow in capability, the complexity grows. And as things get more complex, we encounter novel problems. We'll need more people who are able to approach these novel problems to help solve them, who know how to ask questions, how to research, and how to formulate new questions to navigate these new problems.

AI Cannot ask the Question For You

It's been a few years now and it's quite apparent that LLMs and AI tools are not going to simplify anything about what it means to program and create software. Peruse OpenAI's Harness engineering write-up, and it's clear to see that the new way to approach programming, seems to still be the same fundamentals as programming, but with more abstractions between you and the result, and with potential higher complexity due to the sheer volume of code that can be generated in shorter amounts of time. Which will lead to more complex software, which leads to more complex issues. Software is not a static industry, and we constantly scale the capabilities of the software to the capabilities of the tools.

What remains is the most valuable discipline that you can cultivate: how to ask effective, productive questions. And once you receive an answer to that question, how to take that answer to reformulate the next question, performing this process recursively until clarity comes. This is the process of "critical thinking", but that phrase handwaves away the mechanics of what it means to do just that. Being able to distill a general question into a highly specific one involves relentless scrutiny, ongoing experimentation, and being comfortable residing in a state of unknowing for an unspecific amount of time. This is the true job description of the programmer.

AI models cannot think for you, and they cannot formulate the question for you. They can certainly be a tool that helps you on your research path, but they are still bound by their training data, and they cannot escape the weighted dice that determines their paths which drive to their outputs. Their ability to generate answers is unmatched, but those answers are highly sensitive to the original input & context, and fundamentally untrustworthy by their very nature. That's OK, because they still have tremendous value, but only when someone is present and capable to sift through the noise, distill the truth, and verify the answer (or perhaps, the next question).

The Answers are Cheap Now

As Brit Cruise stated in a beautifully succinct manner: in an era where AI tooling has dropped the cost of answers to near zero, the value resides in asking the right questions. And while AI tools have exacerbated this situation, I would postulate that the value has always been in asking the right questions.

And when you have an infinite answer machine, your ability to ask good questions becomes infinitely more valuable.

View the article at: https://larsfaye.com/articles/the-question-is-the-work

Interesting in learning how to ask better questions? Check out Confident Coding

Your AI generated code is "almost right", and that is actually WORSE than it being "wrong".

Lars Faye | Confident Coding — Fri, 20 Mar 2026 15:13:02 +0000

"Almost right" will make it past reviews.
"Almost right" will pass tests and linters
"Almost right" will make it in your codebase, and wait for the right mix of reasons to create a potential catastrophe.

Yes, AI tools enhance your work and empower you to "punch above your weight". You also need discipline and practice, and you can give yourself permission to slow down and learn what is happening on a deeper level.

While the industry is pushing relentlessly for handing over control to “agents,” I propose a more measured approach, and recommend that the default mode when working with LLMs should always be scrutiny and skepticism. The trust needs to be earned, not granted.

When working in areas where the training data is robust and plentiful and the requests are clearly architected with proper context, they have a fairly high accuracy rate. Nevertheless, the real work happens in the nuance and the details, and they are renowned for introducing application-breaking issues through seemingly innocuous additions or changes. Every response should have a “trust, but verify” approach.

Anthropic themselves support this approach:

A security engineer highlighted the importance of experience when Claude proposed a solution that was “really smart in the dangerous way, the kind of thing a very talented junior engineer might propose.” That is, it was something that could only be recognized as problematic by users with judgment and experience.

It's only by knowing how to code, and practicing your coding on a regular basis (and your debugging, which I'm starting a course on), will you learn the skills to be able to catch those "almost right" solutions that these models provide, and be able to vet them properly, and ensure you're not pushing up a time bomb to your repo! 💣