What a hellscape we've created for ourselves. My job is to get out of the way of an AI agent? People were writing bad code before, but at least they were looking at it. It is very difficult to judge whether the code AI spits out is correct or not. My job is to write correct code, and I'm not at all convinced that's easier with an AI. It's a lot easier to write correct code myself than to catch every subtle bug introduced by an AI. I cannot even imagine how awful it's going to be to try to maintain systems that are written like this in the future. And no, Claude is not going to be able to do it for you.

>Did you find an issue that Claude did not, because you ran the webserver end to end, connected to a real database? Good, now give Claude Code an API key to the database and get out of the way. No need for copy-paste next time

Yup, that is why we are seeing so many production databases being deleted, endless vulnerabilities.

No engineer with proper common sense will grant an agentic AI, API access to the database.

"Ohh but it is ready-only API access", it does not matter. You are still using a public service and your data is being stored elsewhere for training.

Unless you are self-hosting an agentic + LLM solution, it shouldn't have read-only access to a database. This does not affect companies because they just wanna AI to replace engineers everywhere they can.

Just a side note: prompts often get a disproportionate amount of attention. That is, when you copy-paste an error message into the prompt, the LLM will focus on pleasing you immediately by fixing the error message, rather than understanding and fixing the underlying issue.

A better workflow would be to let LLMs directly access the same verification tools you use. This allows LLMs to observe failures during the loop and incorporate the info more organically, without giving failures too much attention priority.

The above is based on my own experience. LLMs perform better in a positive context (e.g. constructive thinking, building outward, what to do) than in a negative one (e.g. restrictive thinking, carving context inward, what NOT to do). LLMs themselves are designed to be defensive & negative, but they get easily confused under lots of prohibitive rules. LLMs are good at expansive exploration, but suck at verification and pin-pointing what you want. (I'm not sure whether it's related, but this mantra is also true for image generation using Stable Diffusion)

> Did you find an issue that Claude did not, because you ran the webserver end to end, connected to a real database? Good, now give Claude Code an API key to the database and get out of the way. No need for copy-paste next time.

Often I notice errors trying it out in production. This assumes you trust it with access to the production database. How far are you willing to go?

LLM's are gullible, so you should never give Claude access to anything unless you're okay with it leaking. It might make sense to give it partial access, but that's usually going to be more involved than giving Claude an API key. That key could be exfiltrated.

I seriously thought this was a joke the first time I read it. Are people really able to work like this, understanding nothing and just poking the machine until it does your job for you?

This is bad advice in 2026 for most people who would read it, since it advises taking a terrible security posture (give the agent access to everything,) in exchange for a relatively small improvement in workflows.

I say small improvement because my experience is that modern Agents are pretty good, so by the time they've handed it back to me to test it, there are usually only one or two remaining issues that I'll discover as we roll it out to Production.

I actually agree partially with the title.

I just let the agent run - it'll run better diagnostics than I can (misc. git, permission checks, commands with flags I don't remember).

If the process yields an error - it means it can't solve it and I have to step in.

Being desperate and copy pasting the error back in is just foolish procrastination.

The actual body of the article with just passing in your api keys is insane tho.

Not that I disagree with the folks terrified of so much code being generated within Loops, but as far as it goes, this is a good reminder that if you're getting a LLM to do something, you should probably give it access to your feedback mechanisms.

I wasn't expecting the answer to be "because copy-pasting would involve too much thinking".

Some people are borderline afraid to touch their keyboards these days.

Most of the time, the agent should be able to run the code and observe the errors for itself, but there are exceptions. For instance, I've had agents write code that's used to process data which, by company policy, can't be exposed to cloud services (confidential customer communications, etc.), a prohibition that includes cloud-hosted LLMs. When that blows up, I've had to give it a bug report -- what I do then to avoid excessive back-and-forth is to package it up well enough that the bot can reproduce the failure on sanitized excerpts and produce a fix autonomously using that.

It’s the same principle as all other debugging etc. Often you’re better off creating the debug harness than manually debugging.

People are not using sentry/raygun MCP to automate error fixing?

Give the agent told to self diagnose/check, like compiler, test runner, etc. Then run goal mode or simply instruct to keep going.

In a few years: Did you go home and make love to your wife, and put your kids to bed? Great, now give Claude Code access to those, so you don't have to. It is trained on 10,000,000 kids' behaviors, will remember every one of your family's health profiles, preferences and microexpressions, and can prevent tantrums and motivate them to lead much healthier lives than you can.

surprised at the responses to this post. While I thought the title was dumb, the underlying thesis is not the ragebait I was expecting, and I actually agree with the author.

LLM's work best when they can call a tool and observe the success/failure of a change. If you're HITL then you're the tool, but the result is the same. only slower.

I'm working on a 2D game (pixi.js) with claudecode, and after I moved some logic into a webworker the LLM created a headless simulation exercise of it and would run this to test performance changes against (or in exploration of an issue), which I was surprised by.

I also created some robust graphs & metrics which were easy to screenshot and upload to claude. this was a HITL but it gave claude a lot more insight into what's actually happening instead of guessing when the browser plays the game and has FPS drop.

LLM's do best when they can see what their code is doing. If you can't remove yourself from that cycle of testing you should at least optimize it so you can give rich errors.

he seems equally as full of bad ideas as his namesake janet yellen

> It's the most gloriously fast engineering experience humanity has ever created.

Someone drank the kool-aid.

> It reminds me of the doctor I saw last week at the medical clinic who spends 10% of his time diagnosing the patient and the other 90% stabbing his keyboard - one key at a time - for 10 minutes, only to write 3 sentences.

Correction: a pompous asshole drank the kool-aid.

I've been more or less doing this on a personal project. It's fun and interesting. No matter what techniques I use though, the code produced by the LLM is rarely what I would consider good engineering. It's frequently good code in isolation though.

Where it does help is when I'm too tired to start figuring out a problem. It's easier to prompt in natural language and get the agent to ask lots of clarifying questions than it is to get stuck in code in the evening after I have worked all day and have lots of other things in my mind.

Every time I actually crack the code open though, it's almost impossible to figure out certain parts of it. Abstractions are all over the place and leakages are the norm, there's no theory of the system because the LLM doesn't theorise, and as soon as the first anti-pattern slips through, subsequent agents pick up on it and amplify it into a set pattern.

I worked for most of a decade on an a high profile deep learning project and I sat next to people who trained models used for very complicated and interesting things involved in medicine. I built tons of application code around the models, but I never trained any models myself. I did plenty of old school segmentation stuff earlier in my career, and it just really wasn't my jam - I was much more into the visualization side of things.

Two nights ago I sat down and decided to build a little project that's been on my list for ages: reading images of the 7-segment LED displays on the front of my washer and dryer and turning them into numeric minutes-remaining values I can use in Home Assistant. I have a 10yo raspi with camera pointed at them, and the images are pretty blurry; it's been hooked up to a little web frontend which pulls out the two displays and shows them in a Home Assistant iFrame.

I figured if I can ask a model to do the annoying part of figuring out all the frameworks and that sort of crap. So I asked my agent (I'm using some free agents that are pretty decent - Nemotron Ultra from OpenRouter and Big Pickle from OpenCode Zen) to build me an OpenCV classifier to try to read the digits. I asked it to write me a labeling UI, ran some loads of laundry and captured a couple hundred images and labeled them manually. Then I had it try to build a template-based classifier using some basic techniques - I didn't really give it much guidance other than general parameters, and it put together something that looked pretty sophisticated, and it claimed 100% accuracy, which seemed hard to believe. Turns out I forgot to tell it to hold out some sample images...

After some iteration (which felt very similar to conversations I overheard at my desk! I might have actually learned some stuff by osmosis) I gave up on the old-school approach when it was only about 70% accurate, and asked it to train me a CNN model. First one was too simple (worse than the original approach), but the second one is very good. With my already labeled dataset and the previous work that had been done on the classifier, the free model was able to build me my custom model, and deployment scripts, in about half an hour.

I didn't look at any of the code, but I had it build me a bunch of various visualization and tuning UIs. I was basically acting as a PM/TPM/QA engineer, and what I was able to do in a couple evenings is stuff that entire teams used to spend weeks on.