# How to Use AI at Work: Think Bigger, Check Harder > Most teams use AI to do the same work faster. Ask it for better work instead: the outcome, the evidence, an expert's methods. Then check harder than before. Source page: https://mnpsystems.ca/blog/think-bigger-with-ai/ Published: Nov 4, 2026. Author: MNP Systems Team. Category: AI. Topics: how to use AI at work, AI prompts for work, AI brief, ambitious AI use, AI agents, critical thinking with AI, cognitive surrender, intent debt, verifying AI output, AI for small business. Narration (MP3): https://mnpsystems.ca/audio/blog/think-bigger-with-ai.mp3 Video summary (MP4): https://mnpsystems.ca/video/shorts/think-bigger-with-ai.mp4 MNP Systems is an engineering consultancy based in Brampton, Ontario, Canada, that takes work from anywhere: remotely, or on site where a job needs hands on the equipment. Contact: https://mnpsystems.ca/contact/, contact@mnpsystems.ca, or call 1-888-338-1090 (toll-free; an AI receptionist answers). Most people use AI to do the same work faster: the same report, the same email, the same spreadsheet, in less time. The bigger gain is to ask it for better work. Aim it at the outcome behind the task, give it the raw evidence and the methods an expert would use, and have it borrow methods from other fields. The catch is that more ambition needs more judgment, because the more polished the result looks, the less anyone checks it. So the habits that matter sit on either side of the work: before the tool starts, write down what you want and why; before you put your name to the result, know what it decided, what its checks proved, and what could still be wrong. This post is for owners, managers and engineers whose teams already use AI tools and suspect they are getting a fraction of what those tools can do. It builds on writing by two people we have found useful on the subject. Felix Rieseberg, an engineering manager at Anthropic, wrote a tutorial on being more ambitious with AI models. Addy Osmani wrote about keeping critical thinking alive when agents do the work, and about two kinds of debt that build up when they do. The frameworks named below are theirs, and the links to the originals are at the end. The examples, the order they are put in, and the tool at the end are ours. ## More than speed Rieseberg describes four ways to be more ambitious with an AI tool, and the first is the one nearly everyone stops at. 1. **Speed.** Do the same work in less time. Useful, and already well understood. 2. **Altitude.** Aim at the outcome behind the task, not the task. 3. **Depth.** Do the work the way the best specialist would: from raw data, with the right methods, checked by someone other than the author. 4. **Range.** Bring in methods from other fields. Speed changes how long the work takes. The other three change what the work is. They are also where the risk grows, which is the second half of this post. ## Altitude: ask for the outcome, not the task A request names a task. Behind it is an outcome somebody wants: something that should be different once the task is done. Asking for the outcome lets the tool suggest a better task. Rieseberg's example is a quarterly business review. Asked for the review, a model updates last quarter's slides with this quarter's numbers. Told what the review is for, which is catching problems early and moving money and people to the right places, it can start with the decisions that are due. Pushed further, it can design something better than a quarterly deck, and show from the business's own history that the new design would have caught problems sooner. The same move works on smaller jobs. "Write a follow-up email for the quotes we sent last month" is a task. The outcome is that more quotes become jobs. Aimed there, the tool might write the email, but it might also point out that half the quotes went out a week after the site visit, and that the delay, not the email, is where the jobs are lost. Two things keep altitude from turning into a tool that wanders off: name the outcome, and name the boundaries it works inside. More on the boundaries below. ## Depth: raw material, expert methods, an outside judge "I want a deeper version of this task, not a bigger one," is how Rieseberg puts it. Depth means three things. - **Start from the source.** Give the tool the export, the records, the customers' own emails, not your summary of them. A summary has already decided what matters, and the tool will only ever agree with it. - **Use the methods a specialist would.** A statistician checks base rates and outliers before drawing conclusions. An operations engineer maps every step of a process and how long each one waits. Ask for the method by name, and the result changes. - **Get an outside check.** A model grading its own work is the author marking their own exam. Test the result against something it did not write: last quarter's real numbers, a second reviewer, a test set before it started. ## Range: borrow methods, not personas Range is bringing in disciplines that do part of the job well. Rieseberg's advice is to "replace the nouns with verbs": a deck is a noun, while "help leaders decide under uncertainty" is something being done, and other fields are good at doing it. An analyst tests the numbers. A journalist finds the story and leads with it. A skeptic argues the case against. He also warns that "it is easy to accidentally engage in role play". Telling a model to be a journalist gets you prose that sounds like a journalist. Asking it to find the one thing the reader must take away and say it first gets you the journalist's method, with a result you can check. Ask for the job, not the costume. ## More ambition needs more judgment Here Osmani's writing takes over, and it is the part most teams skip. As AI output gets better, obvious mistakes get rarer. Most of what comes back is polished and mostly right, and polished, mostly right work does not invite a second look. So the checking quietly stops. Osmani describes a range. At one end is offloading: you hand over the how and keep the what, still judging whether the result makes sense. In the middle is deferral, treating the output as settled. At the far end is what he calls cognitive surrender: you stop forming your own answer at all, and "the AI's output becomes your output". He cites research in which people shown a wrong AI answer mostly accepted it, and grew more confident while doing so. None of this is an argument for using AI less. It is an argument for being deliberate about where your thinking stays, and three of his ideas make that practical. ## If the why is missing, AI guesses Osmani calls it intent debt: the goals, constraints and reasons behind important choices that were never written down anywhere others can read. Code, documents and spreadsheets record what was decided. They rarely record why. A person who was in the room remembers; an AI tool starts each session knowing only what it is given. Ask it why something is the way it is and it will produce a plausible reason, which is not the same as the real one. "An agent can't generate intent, because intent is the one input that has to come from you." Four things are worth writing down before any important piece of work goes to a tool: - **The outcome:** what must change. - **The constraints:** what must not change. The budget, the deadline, the systems you already run, what you have promised customers. - **The rationale:** why those boundaries matter. - **Done:** what evidence will count as finished. We do this ourselves. The instructions our own AI tools read when they work on this website record each decision with the date it was made and the reason for it, so a tool working on the site months later does not undo a choice whose reason it cannot see. ## Can you explain what changed? The second idea is comprehension debt: the gap between how much work exists and how much of it anyone actually understands. It grows whenever output arrives faster than understanding, and it stays invisible until someone has to change the work or explain it. Before you sign off on something an AI tool produced, three questions close most of the gap: 1. What did it decide that I did not ask it to? Defaults, scope, a requirement quietly reinterpreted. 2. Why do those choices work, in my own words? 3. Where could I rebuild the details if someone asked me? You do not need to memorise everything the tool did. You need to know how you would find out. ## A green check is a clue The third idea is about verification. In Osmani's words, "the bottleneck has shifted from coding to being sure you're right". A test can pass and miss what matters. A summary can say "all checks passed" about checks that never looked at the hard part. His rule fits on a sticky note: "When a check goes green, ask what it proved." Then ask what it did not. This is familiar from our engineering work. A test suite that passes in a simulator says nothing about the timing on the real board, which is why hardware-in-the-loop testing exists. The same applies to anything an AI tool hands back: define what verified means before it starts, read the evidence before the summary, and name one thing the checks did not cover. How hard to check depends on what is at stake. "Where the stakes are low, feel free to delegate entirely," Osmani writes. A first draft of an internal note can be skimmed and sent. Anything involving money, safety, someone's job or a promise to a customer deserves a reviewer who did not write the brief, and an author who can explain the result without the tool's words. "You may offload the work and much of the auditing," as Osmani puts it, "but not the accountability." ## One request, reworked Here is the follow-up email from earlier, taken through each idea in turn. - **The request:** write a follow-up email for the quotes we sent last month. - **Altitude:** more quotes become jobs. If the email is not the biggest lever, say so before writing it. - **Depth:** attach the list of last quarter's quotes with the dates they were requested, sent and won or lost, and a few of the replies customers sent. Look for the pattern before writing anything. - **Range:** test the numbers as an analyst would, then argue the case against your own conclusion. - **Intent:** no discounts, because margins are already thin; keep our usual tone, because these are people we have met on site. - **Done:** every claim about the pattern points to rows in the list, and the email is tried on the next ten quotes before it goes to all of them. Written out as a brief you can adapt, it reads something like this: > I need to achieve [outcome] for [audience]. Context and constraints: [details], and why they matter: [reasons]. Before you start, tell me what decisions are missing and what raw evidence an expert would need. Apply relevant methods from other fields, as jobs with results I can see. Build a practical solution and check it against [success criteria]. Show me the evidence, the decisions you made that I did not ask for, and what remains unverified. ## Keep the front and back of the work human The ideas above fold into one habit with three steps. - **Before:** form a hypothesis. Write down what you think the answer is and what success looks like, before the tool starts. Then you can tell whether the result surprised you, and a surprise is where checking pays. - **During:** give a clear brief. The outcome, the boundaries and the reasons for them, the sources, and how the result will be checked. - **After:** name the blind spot. Review the evidence rather than the summary, and write down one thing that was not checked. The middle can belong to the tool. The front and the back belong to the person whose name goes on the work. ## Try it on your own work We built a tool that does the writing-down for you. The [AI Brief Builder](https://mnpsystems.ca/tools/ai-brief/) asks seven questions about one piece of work you are about to hand to AI and writes the brief: the outcome behind the task, the evidence and methods, the methods to borrow, the boundaries and the why, and what will count as done. Under it are the questions to answer before you sign off, set by what is at stake. It runs in your browser, and the brief pastes into any AI tool. If you want a whole team working this way, briefing AI on real tasks and checking what comes back, that is what our [AI training for teams](https://mnpsystems.ca/ai/) does, on your own work rather than on examples. ## The originals The ideas above are summarised and adapted. Read them in the authors' own words: - Felix Rieseberg, [How to be more ambitious: a tutorial for humans with models](https://felixrieseberg.com/how-to-be-more-ambitious-a-tutorial-for-humans-with-models/) - Addy Osmani, [Critical thinking when agents do the work](https://x.com/addyosmani/status/2117512471930167377) - Addy Osmani, [The Intent Debt](https://addyosmani.com/blog/intent-debt/) - Addy Osmani, [Cognitive Surrender](https://addyosmani.com/blog/cognitive-surrender/)