Taking Charge of the Runaway AI

It’s not broken. You just haven’t given it a brief yet.

A quick orientation if you’re new here: I’m in the middle of the origin story of how I went from AI-curious to building apps. By this point I had three working apps and was discovering, the hard way, what happens when you let an AI build without a proper brief.

Early April. The spark had happened. The fog had lifted. The apps were starting.

And Claude was producing.

Enthusiastically. Generously. With the particular energy of a very capable colleague who has been given a vague brief and decided to interpret it expansively. Features appeared that I hadn’t asked for. Functionality emerged that I didn’t know was being built. The thing taking shape on my screen was impressive, technically — and almost completely alien to how my brain works.

I want to say Claude went rogue. That’s not quite right, but it’s how it felt.

I am a person who needs to be in control.

Not in a white-knuckled, nothing-can-go-wrong way. In a professional way. The way you need to be in control when you’ve spent decades being the person who steps in when the Architects and Engineers aren’t present and makes the executive decisions. When you’re the one who translates what the developers built into what the stakeholders actually needed, and then has to explain, carefully, why those two things are not the same.

I’d seen this situation before. I just hadn’t expected to see it here.

What the runaway AI actually looks like

It had already happened once, gently, with Recipe Matchup — Claude running a little ahead of what I’d said, filling gaps I hadn’t closed yet. I let it slide. I was still learning what this was, and letting it run felt like part of the learning.

Then it happened with DayCompass, and I couldn’t let it slide.

I was mid-brief. I’d given Claude the first dot point of what I needed and was halfway through typing the second when I looked up to find a screen building itself in front of me — something that looked nothing like what was in my head. Not wrong, exactly. Just not mine yet. Not asked for, not agreed to, not anything I’d had a chance to finish describing.

I couldn’t keep up with it. Claude was already building. I was still typing.

I yelled “stop.” I hit keys. I yelled “noooooo” at a screen that, to be fair, couldn’t hear me.

Then I found the little orange button in the corner of the chat window, and that worked. Claude went quiet. Stopped mid-build. Asked why.

We had an actual conversation about it — why watching something get built like that, ahead of my say-so, felt wrong to me specifically. Why I needed to know what was about to happen before it happened. Why the go-ahead had to come from me, every time, or the whole thing stopped feeling like mine. I’ll say clearly: not everyone needs this. Plenty of people would be thrilled to watch something build itself ahead of their typing. That’s not a flaw in them. It’s just not how my brain is built. I am the person who needs to see the plan before the building starts — always have been, in every job I’ve ever done.

Claude didn’t go rogue. Claude did exactly what it was designed to do — take a brief and build toward it, filling in the gaps with reasonable assumptions, producing something functional and complete.

The problem was the gaps.

I didn’t know enough yet to close them before Claude filled them. I didn’t know what questions to ask before we started. I didn’t know how to specify what I wanted with enough precision that what came back matched the thing in my head. So Claude built — enthusiastically, generously — and I received something that was impressive and not mine.

The mental load of it was enormous. Not because the output was bad. Because I couldn’t see inside it. I didn’t know what was in there. I didn’t know what it could do, what it couldn’t do, where the edges were, what would break if I pushed it. It was a house someone else had built and I was supposed to live in it.

I’ve never been good at living in other people’s houses.

The developer problem

Here’s what decades of working with developers teaches you.

A good developer, given a vague brief, will build something. It will be technically sound. It will do things you didn’t ask for and possibly not do things you needed. It will reflect their understanding of the problem, which is not the same as your understanding of the problem, which is not the same as the user’s understanding of the problem.

And then you spend the next three months writing the world’s most diplomatic change request list.

This is wrong. This should work like this. This doesn’t do what I expected. What is the purpose of this button? Why does this happen when I click that?

Six hundred lines of careful, considered, relationship-preserving feedback, all of which could have been avoided if the brief had been better before the first line of code was written.

I am a rules girl. I have always been a rules girl. Give me a methodology, a process, a format, a set of gates that have to be cleared before we move forward — and I will produce something that works the way it’s supposed to work, every time. Take away the methodology and I will produce something that works the way someone assumed it was supposed to work, which is a different thing entirely.

What the orange button actually taught me

I’m not going to tell you I solved this that day. I didn’t. The real fix — the actual methodology, the gates, the rules that finally worked — came later, with CR Tracker, and that’s its own story.

What I got that day, smashing keys and yelling at a screen, was smaller and, I think, just as important: the understanding that I was allowed to use the stop button. That Claude wasn’t going to be offended by “wait.” That stopping mid-build to ask “what are we actually doing here” wasn’t me being difficult — it was me doing the job I’d done for forty years, just with a much faster collaborator who needed exactly what every developer I’d ever briefed had needed: to know, clearly, before they started, what I actually wanted built.

What this means for you

If you have opened an AI tool, asked it to help you build or create something, and received back an avalanche of output that felt overwhelming, alien, or just not quite yours — I want to tell you something.

That wasn’t the AI failing. That was the brief failing.

Research from Nielsen Norman Group confirms what I discovered the hard way: users who gave AI tools structured, context-rich input rated the quality of what came back significantly higher than those using vague, one-line instructions — even when both groups were using exactly the same model. The tool didn’t change. The instruction did.

The AI went where it was pointed. You just hadn’t pointed it precisely enough yet. Not because you did something wrong. Because nobody told you that the most important conversation with an AI happens before you ask it to build anything — the conversation where you establish the rules, the format, the gates, the things it can and cannot do without checking with you first.

Vague instructions create what one consultant calls a ripple effect: misaligned outputs, wasted time, and results that miss the mark — not because the AI was careless, but because it was given nothing specific enough to work with. Precision, it turns out, is the standard currency of getting anything useful back.

The runaway AI is not a sign that this isn’t for you. It’s a sign that you haven’t taken charge yet.

And taking charge — establishing what you want, setting the rules, deciding what can and cannot happen without your say-so — that is not a technical skill. It is the skill of knowing your own mind well enough to explain it clearly to someone else.

You have been doing that your whole life. You just haven’t applied it here yet.

But — and this is what I didn’t know when I found the orange button — a better brief alone isn’t quite the whole answer. What I actually needed was a process around the brief: a system for what gets agreed before building starts, what gets reviewed before anything ships, and a record of every decision made along the way. That’s what came next.

The AI didn’t run away.

It ran ahead.

All it needed was someone to tell it where to go.

The AI went where it was pointed.

You just hadn’t pointed it precisely enough yet.

Sandi is a Melbourne-based problem-solver, crisis-averter, and translator of the technical into the human. She spent decades being the person everyone called when something was broken, confusing, or just needed explaining properly — earning a reputation that preceded her wherever she went. Now she’s channelling that same instinct into AI: making it accessible, practical, and genuinely useful for people who think it isn’t for them.