There's a specific kind of embarrassment that comes from opening your own codebase two weeks after writing it and not recognizing it. Not because you forgot what you built, but because you're not sure you're the one who built it.
That happened to me while I was putting together the early skeleton of Quiro's AI editing agent, the part of the app that watches a screen recording and decides what to zoom into, what silence to cut, where a caption should land. I remember the exact moment, actually. It was late, I'd been going back and forth with an AI coding assistant for maybe three hours straight, and I opened a file to fix a small bug and just... paused. There was a whole abstraction layer in there (a queue, a dispatcher, some kind of event bus) that I didn't remember deciding to build. It worked, technically. It also had nothing to do with the shape of the problem I was actually solving. It was there because at some point I'd asked for "a way to handle multiple edit requests" and the model had reached for the most generic, most textbook answer to that question, and I'd said "looks good" and kept moving.
I want to be honest about how that happens, because I don't think it's really about the AI being wrong. It's about a very specific trap that only exists once a tireless, endlessly agreeable collaborator is in the loop with you.
The trap nobody warns you about
Here's the thing nobody tells you when you start pairing seriously with an AI coding tool: it will never get tired, it will never push back unless you ask it to, and it will produce plausible code at a speed that completely outpaces your ability to evaluate whether it's right. Plausible is the dangerous word. Plausible code compiles. Plausible code passes the obvious test case. Plausible code looks, at a skim, like something a competent engineer would write, because it's trained on a mountain of competent engineers' code. What plausible code does not reliably do is fit the actual shape of your actual problem, the one that only exists in your head and in the handful of decisions you've made so far that haven't been written down anywhere.
Normally, when you're coding alone, your own fatigue acts as a kind of governor. You get tired of typing boilerplate, so you go find the shortcut. You get tired of re-deriving the same logic in three places, so you extract a function. Friction, annoyingly, was doing some of your architectural thinking for you, just by making the lazy path and the good path the same path more often than you'd expect. Take the friction away (hand the typing to something that never tires), and that governor disappears. You can generate an entire subsystem in the time it used to take to write one function signature. Which means you will, whether or not that subsystem should exist yet.
I built and half-liked that queue-and-dispatcher thing for about two days before I admitted it was solving a problem I didn't have. Quiro's agent, at the time, needed to do one thing: take a recording, reason over what happened in it, and call a small number of well-defined tools: zoom here, cut this silence, add a caption there. It did not need a generic multi-consumer event architecture. It needed eight tools and a model that knew how to pick between them. I ripped the whole layer out. It felt like a waste of two days. It was actually the two days that taught me the lesson this whole post is about.
Deciding the shape before asking for the fill
What I do differently now (and what I wish someone had just told me plainly instead of me having to embarrass myself into it) is decide the shape of a feature completely, on paper or in a plain comment block, before I open a chat window with any AI at all. Not a full spec. Just: what are the nouns, what are the verbs, where does state live, what's allowed to change what. For the editing agent, that meant sitting down and writing out, by hand, the exact list of things the agent is allowed to do to a recording. Auto-zoom on a click. Remove a silence. Remove a filler word. Generate captions. Add an annotation. A small number of named, boring, specific verbs (eight of them, in the end), each with a fixed JSON schema for its inputs. No open-ended "edit this recording however you see fit." A closed set of moves, decided by me, in a normal state of mind, before any model got involved.
Once that shape existed, working with an AI assistant on the implementation stopped being dangerous and started being genuinely wonderful. I could ask it to implement the "remove silence" tool and know, going in, exactly what the function's contract should look like, so I could tell in about four seconds whether what came back matched. The model wasn't deciding the architecture anymore. It was filling in a shape I'd already committed to. That's a completely different working relationship than the one I had during those two lost days, where I was essentially asking a very fast, very confident intern to also be the architect, and being surprised when the results didn't hold together.
I think this is the actual, unglamorous answer to "how do you use AI coding tools responsibly," and it's less exciting than most of the takes I see on it. It's not about which model, which IDE plugin, which prompt template. It's about whether you did the boring, slightly old-fashioned thing of deciding what you're building before you handed anyone (human or model) a blank page and asked them to start typing. The fastest way to convince yourself a design is finished is to let a tireless collaborator start producing convincing-looking output against it. The output will always look done. The only thing that tells you whether it's actually done is whether you knew the shape first.
What I'd tell past-me
If I could go back to that night, the one where I opened my own file and didn't recognize it, I wouldn't tell myself to stop using AI tools. They're genuinely how I ship as much as I do now, and I'm not interested in pretending otherwise for the sake of sounding like a purist. I'd just tell myself: you're allowed to think first. Slower, on purpose, with nobody generating anything, for as long as it takes to know the eight verbs instead of zero. It costs you an evening. It saves you the two days I actually lost, and probably a few more I got lucky enough to avoid. Architecture doesn't get to be the thing you clean up after the fact anymore. It has to come first, because the thing that used to force it to come first (your own tiredness) isn't there to save you anymore.