Skip to content

How We Let AI Help Build WorkWingman — Without Letting It Hurt You

(Plain-language twin of mcp-dev-tooling.md. Same rules, no jargon.)

WorkWingman is built with a lot of AI help. That should make you slightly nervous, and it makes us slightly nervous too — which is the point of this page. AI writing the app that fills in your job applications is only safe if the AI is kept on a short, deliberate leash.

Here's the leash. Every rule below exists because of a specific way this could go wrong.

The tools have version numbers nailed down

An AI assistant can plug into helper tools — a linter that checks code style, a tool that knows the Angular framework. Those helpers are downloaded packages, and packages update.

The lazy way to wire one up is "always fetch the latest version." The problem: whatever that package becomes tomorrow runs inside our AI's brain, automatically. If someone takes over that package and publishes a malicious update, it walks straight into the tooling that writes your app. That's not paranoia; it's one of the most common real-world software attacks.

So every tool is pinned to an exact version. Upgrading is a decision someone makes and reviews, never something that just happens overnight.

Tools can read by default. Changing things takes permission.

The helper tools are split into two piles.

Reading — check this file for mistakes, look up documentation, list the projects — happens freely. Reading can't change anything.

That's not the same as harmless, and it's worth being precise about: reading can still pull sensitive information somewhere it shouldn't go, or drag hostile instructions into the AI's head (see the prompt injection bit below). So read access is scoped too — each tool sees only what its job needs. The point isn't that reading is safe; it's that reading is reversible, and changing things often isn't.

Doing — run a command, start a server, rewrite a batch of files — always stops and asks a human first. Not because the AI is expected to misbehave, but because "ask first" is cheap and "undo it afterward" often isn't.

We turned down an AI that fixes failing tests

This is the one worth understanding, because it sounds great until you think it through.

There's a tool that watches your tests fail and automatically rewrites them until they pass. Tempting: no more broken builds.

Here's why it's poison. WorkWingman's tests exist to catch it when the app breaks — when it fills a form wrong, mangles your resume, or loses your data. A test that fails is the app telling you something is broken. An AI that "fixes" the test has not fixed the app. It has removed the smoke detector because the smoke was annoying.

You'd be left with a green checkmark, a broken app, and no way to tell the difference. Rejected — and it stays rejected unless someone can show a version that provably can't touch the tests' ability to fail.

We turned down the hacking toolkit

There's a category of tool for breaking into systems — legitimate, used by security professionals to test their own defenses. Someone could reasonably suggest wiring one up to check WorkWingman's security.

We won't, because of how AI agents actually fail. An AI reads text from the outside world — job postings, web pages, emails. Hidden instructions in that text can hijack what it does next; it's a real attack called prompt injection. An AI that can be talked into things should not be holding a weapon. One poisoned job posting and the app on your computer is attacking someone else's servers, in your name, from your IP address.

We test our own security a different way — an automated scanner that probes WorkWingman's own interface for common flaws, with no ability to touch anything else.

The robots don't check their own homework in the final gate

Before any change lands, plain, boring, non-AI tools check it: style, formatting, code analysis. Deliberately not AI, because those checks need to give the same answer every time. A gate that can be talked into agreeing is not a gate.

AI helps write the code. It doesn't get a vote on whether the code is acceptable.

Each tool gets only the secrets it needs

Helper tools launch as separate programs, and by default a program inherits every password and key floating around the session that started it. A linter does not need your API keys. So each tool is handed only the specific values it needs, and nothing else — and no secret is ever written into a file that gets committed. A check runs before every push to make sure.

The one tool we can't pin, and what we do instead

Every rule above assumes we control the tool's version. One doesn't play along: the connector to Jira (the tracker where WorkWingman's work is planned). It's a service running on Atlassian's computers, not a package on ours. There's no version to pin, and it can change under us with no warning and no diff to review.

We can't fix that, so we compensate: it's allowed to read tickets, and every ability to change anything — create, comment, move — asks first, every time. When you can't trust the tool to stay the same, you make sure it can't do anything irreversible alone.

Learn more