If you're building an app with AI — not because you chose to learn programming, but because AI made it possible to build without learning programming — there's a feeling you know well and probably haven't named.
It's the moment after the agent says "Done!" and you don't know what it did.
You can see the app. You can click around. It looks right. But "looks right" and "is right" aren't the same thing, and you have no way to tell the difference. You don't read code. You can't open the files and check. So you test what you can see, and you hope nothing changed underneath that you can't see.
That hoping is the problem. Not because you're doing something wrong — you're doing everything available to you. But the gap between what the agent changed and what you can verify is where things go quietly, invisibly sideways.
What "going sideways" actually looks like
It's not dramatic. Your app doesn't explode. What happens is smaller and harder to catch.
The agent decides your app needs a feature you didn't ask for. Maybe it adds a connection to an external service. Maybe it restructures how your data is stored. Maybe it pulls in a library you've never heard of to solve a problem you didn't know existed. Each of these is the agent being helpful — and each of them changes your app in ways you can't see, can't evaluate, and didn't agree to.
You find out later. The app does something unexpected. Or a build breaks and the error message means nothing to you. Or — worst case — you don't find out at all, and the change sits there, baked into your project, doing something you never intended.
A programmer would catch this in seconds. They'd look at the diff — the list of what changed — and say "why did you touch that file?" They have a mental model of their codebase that acts as a natural check on agent behaviour. They can do code review.
You can't do code review because you don't read code. And every AI coding tool on the market assumes someone is doing code review.
What scope lock does instead
Throughliner takes a different approach. Instead of asking you to catch problems after they happen, it prevents the agent from creating them in the first place.
Here's how that works, concretely.
Without scope lock, a session looks like this:
You tell the agent "add a login page." The agent builds the login page. While it's at it, it notices your app doesn't have password reset functionality, so it adds that too. It also sees that your user data isn't encrypted, so it pulls in an encryption library and restructures your database. It tells you "Done! I added the login page, plus password reset and encryption for your user data."
Every one of those decisions might be good. But you didn't make any of them. The agent decided your app needed them, and acted. You now have three features where you asked for one, built on architectural choices you didn't participate in, using a library you've never heard of. And if any of it is wrong, you have no way to know.
With scope lock, the same session looks like this:
You tell the agent "add a login page." The agent builds the login page. While working, it notices the password reset gap and the encryption concern. But it can't act on them — they're outside the scope of what you asked for. So instead, it writes them down: "noticed: no password reset flow" and "noticed: user data isn't encrypted — potential security concern." Those notes go into your project queue for you to look at later, during planning. The agent finishes the login page and stops.
You now have one feature, the one you asked for. The other observations aren't lost — they're recorded, waiting for you to decide whether they matter. But they're your decisions to make, not the agent's.
Why this isn't just a "nice to have"
For a programmer, an agent that goes beyond scope is annoying. They catch it, undo it, move on.
For a non-coder, an agent that goes beyond scope is invisible. You don't catch it. You can't undo what you can't see. And every unauthorised change compounds — the next session's agent builds on top of changes you never approved, which become the foundation for more changes you never approved. Your app drifts further from what you intended, and you have no way to trace when or why it started.
Scope lock breaks that cycle at the source. Not by teaching you to review code. Not by adding a step where you approve things you can't evaluate. But by making sure the agent only does what you asked, and records everything else for you to decide on in your own time.
I've written more about what scope lock is and how it works, and about how the rest of the industry is approaching this problem. The short version: scope control is starting to get attention, but every other solution assumes you're technical enough to define the boundaries yourself. Throughliner builds the boundaries into the workflow, so you don't have to know what to restrict — you just have to know what you want built.
That's it. You say what you want. The agent does that and only that. Everything else gets written down, not acted on. And the gap between what happened and what you can verify gets as small as it can be, without asking you to learn to read code.