Work like an engineer

Four principles to work by

Four habits worth keeping in mind — and worth telling the AI — when you're building today. They cover most of the "why did it do that?" moments people hit. The difference between AI quietly rewriting half your file and AI pausing to ask.

Know when to use AI

AI is non-deterministic — ask it the same question twice and you might get two slightly different answers. That's a feature for some tasks (judgment, generation, summarization) and a bug for others (classifying the same thing consistently, thousands of times).

If a task has a right answer that should be the same every time, that's a deterministic task. Filters, rules, and plain code will do it cheaper, faster, and more reliably than AI ever will. For those tasks, don't use AI to run them — use AI to build them.

• Expensive way. Have AI read every email in real time and decide if it's priority. Costs money per email, adds latency, and the answer can drift day to day.
• Better way. Paste 200 of your recent emails into Claude. Tell it what priority looks like for you. Have a conversation to design a set of Gmail filters that would catch them. Then set those filters up (or have AI do it). Gmail now runs the classification — deterministically, for free, forever.

You're still using AI. You're just using it to build the tool, not to run the tool.

Know what to handle carefully

Three categories of information you should never paste casually, commit to a repo, or share in a chat:

• API keys and tokens. Treat them like bank passwords. If one leaks, whoever has it can run queries that cost you money, read your data, or send messages on your behalf. Never paste them into chat, never commit them to a repo, never share them in Slack. If you think one got exposed — rotate it immediately.
• Personal information (PII). Real names, emails, phone numbers, addresses, health data. Anonymize before asking AI to analyze real customer data. For personal projects, your own data is fine; for work, follow your company's rules.
• Proprietary or confidential work information. Anything you'd mark "internal only." Many companies have specific AI-use policies — read yours. When in doubt, ask your team before pasting.

• Read permission scopes before you connect. "Read your calendar" and "read and modify your calendar" are very different asks. Don't rubber-stamp the approval screen.
• Test destructive actions on one item first. Before you let an agent loose on your whole inbox, have it run on a single email. Sends, deletes, and overwrites are easy to fire off and hard to undo.
• Read what AI wrote before accepting it. It's the #1 way people end up with bugs they can't explain. Even a 10-second skim catches most of them.

Use the least access that gets the job done

When you connect an AI or an agent to your data — email, calendar, docs, a database — start with the minimum access you can get away with. Engineers call this principle of least privilege. It's one of the most reliable ways to not ruin your own day.

• One-time export. Download the data, feed it in, done. No live connection. Great for analysis or designing a rule-based system (see the email filter example above).
• Read-only. The agent can see but can't change anything. Worst case: it looked at the wrong thing — nothing got broken.
• Read + create. Can make new things but can't modify or delete existing ones. "Draft this email in my drafts folder" — you still review and send.
• Full read + write + delete. Everything. Use for things you've tested repeatedly, on non-critical data first.

• Start one rung lower than you think you need. You can always add access later; undoing damage is much harder.
• Scope by time or folder when you can. If the task only needs last week's emails, don't grant access to the whole archive.
• Test on a non-real version first. A test folder, a test calendar, a sample spreadsheet — before pointing the agent at the real thing.
• For work data, read your company's AI policy first. Most have rules about what data can go into outside AI tools, and those rules matter.

Troubleshoot like an engineer

The single biggest habit that separates people who feel confident vs. stuck is the willingness to just… look stuff up. Engineers constantly google error messages, skim docs, and ask AI what something means. That's the job, not a sign of weakness.

• Read the error first. Nine times out of ten it tells you exactly what broke. The bottom line of the stack trace is usually the one that matters.
• Paste the error into Claude. Include what you were trying to do and what actually happened. It's faster than Googling for most modern errors.
• Ask Claude to explain. "What does this code do?" "Why would this function return undefined?" "Walk me through what just happened." Don't just stare at it.
• Describe the bug like a detective. "I expected X, I saw Y, I already tried Z." That structure unlocks better help — from humans or AI.

Use GitHub without fear

GitHub is just version control for folders of code — a backup system with history. You save snapshots (commits), push them online, and if something breaks you can roll back to the last working version. That's really it.

A few habits that'll save you hours:

• Commit often, commit small. Every time you get something working, save a checkpoint. Rolling back one small commit is way easier than untangling a week of changes.
• Write commit messages about what changed, not what code you touched. "Fix login button alignment" > "Update app.html line 47."
• Never commit secrets. API keys, passwords, .env files. Once a secret lands in commit history, it's there forever — even if you delete it in a later commit. If it happens, rotate the key right away.
• Push after every meaningful commit. Pushing is your offsite backup. If your laptop dies, you still have everything.