AI is a co-worker you onboard — a founder's setup for daily work and code, and where it goes wrong

The frame AI is a force multiplier for a team of one or two. It is not a co-founder and it is not going to build the company while you sleep. Think of it as a fast, widely-read colleague who has never seen your business, is confidently wrong a few times a day, and needs everything spelled out. Used like that, it gives you back hours. Used as an oracle, it quietly ships bugs and sends bad emails under your name. Two loops run through a founder's week: the thinking loop — research, drafts, decisions, comms — and the building loop — the codebase. AI helps with both, in different ways, and the habits that make it safe are the same for each. One rule sits above the rest: you own the output. "The AI wrote it" is not a defence for a broken migration or a cold email that misread the room. The setup — what to turn on this week Keep it small. Two or three tools you open every day beat ten you trialled once. · A chat assistant, kept open in a tab — Claude or ChatGPT. This is where research, drafts and thinking out loud happen. · A coding agent in your terminal or editor — Claude Code, or Cursor if you want it in the IDE. Anything that touches the codebase goes through this, not copy-paste out of the chat tab. · Meeting notes that transcribe and summarise — Granola, Otter, or whatever your call software already includes. Turn it on for every call and stop taking notes by hand. · Optional: inline autocomplete while you type code. Useful, but the least important of the four — leave it until the rest is habit. That is the whole stack. Add to it only when a real task keeps not fitting. Daily workflow — where it saves hours Inbox and comms. Paste a long thread and ask for the state of play and what it needs from you. Draft the reply, then edit it down. Turn a call transcript into a list of who owes what by when. Research. Competitor teardowns, pricing-page comparisons, "explain this regulation like I have to comply with it next month". A genuine head start — but treat every fact, number and name as unverified until you have checked the source yourself. It will invent a statistic with a straight face. Writing. PRDs, landing copy, investor updates, job descriptions, the cold email you have rewritten four times. It drafts, you edit. The draft is usually most of the way there and saves the worst part, which is the blank page. Decisions. Describe the situation and ask it to argue the case you are not making. Use it to pressure-test a plan, not to make the call — the judgement is yours, and it does not carry the consequences. Ops. A SQL query from a plain-English question. The spreadsheet formula you always have to look up. A first read of a contract to flag what is unusual — then a human before you sign anything that matters. Development — how founders build faster with it Scaffolding. "Add an endpoint that does X, match the style of these two files." Point it at the real files and the real conventions and you get something close to your codebase rather than a generic example. Tests. "Write tests for this module, cover the edge cases and the error paths." Then read them — a test you did not check is not coverage, it is decoration. Debugging. Paste the error, the stack trace and the file it points at, and ask for the three most likely causes. One of the highest-return uses there is. Code review. Run it as a first pass before you open the pull request, or before a teammate looks. It clears the obvious things so a person can spend their attention on the ones that matter. Learning. Point it at an unfamiliar codebase, or a framework you have not used, and ask how one specific thing is wired together. A faster way in than the docs — as long as you check what it says against the code. The boring wins. Commit messages, doc comments, renaming something consistently across forty files. Small, dull, and it does them without complaint. How to work with it so the output is worth having Context is the whole game. The difference between a useless answer and a great one is almost always how much you gave it — the actual files, the constraints, an example of what "good" looks like. Vague question, vague answer. Work in small steps and check each one. A 300-line change you did not read is a liability, not a shortcut. Ask for one thing, review it, ask for the next. Keep a person in the loop for anything you cannot undo, or anything the outside world sees: money, database migrations, emails to customers, legal terms. Let it draft; you send. Never paste secrets, API keys or customer data into a tool you do not control. If you cannot explain what shipped, you are not finished. The point is to move faster, not to understand your own product less. Pitfalls before they bite · Invented APIs. Function names and library methods that look exactly right and do not exist. Run the code. · Confident wrong answers on anything numeric, legal or recent. The model has a training cut-off and no shame about it. Verify. · Skill fade. The thing you stop doing yourself is the thing you get slower at. Keep your hand in on the parts that matter. · Cost and lock-in. Know what you are paying each month, and keep your prompts and workflow portable enough to switch tools without a rebuild. This week Pick one chat assistant and one coding agent. Use only those for five working days. Run every PRD, investor update and cold email through the assistant as an editor before it goes out. Turn on transcription for every call. Keep a note of the tasks it is bad at. That list is where your time actually goes, and it is worth more than anything above it.