6 habits of an AI-native operator.

01I record everything I can

An agent is only as good as the context you can hand it. So I treat context the way a business treats capital. The habit has 2 parts, and both are cheap enough to start today.

Part 1 is capture. Voice Memos on my iPhone or Mac was enough to begin. Purpose-built apps go further. Wispr Flow turns speech into clean text anywhere you can type. Granola takes notes in your meetings without joining the call as a bot. The main principle here is to get transcripts for all the conversations you have. Conversations with clients, conversations with yourself (diary)... capture it all.

Part 2 is transcription. Audio starts paying off the moment it becomes text, and an agent can run this step for you. Hand it the recording. It sends the audio to a speech-to-text API such as Whisper and writes the transcript into a markdown file. A folder of transcripts is a context store every future prompt can draw on, and it grows more useful with every engagement.

The strongest example of this I have to share: a client needed his platform live before his book published. There was no specification and no time to write one. So I recorded the conversation instead. The transcript became the specification, the specification became the build, and the first working version ran 3 days later. I literally recorded our meeting in person, fed it into a transcription service, and stored the transcript in the same repository as the platform code. Agents writing the code drew from the meeting notes to formulate a plan, which turned into requirements, which turned into specifications.

“You have literally moved my business forward by at least 3 months, maybe more, in 3 days.”

Matt Bagwell, coach and author of Unstuck

02I only pay for or use tools agents can drive

Before adopting any tool, ask one question: can an agent operate this without me? Prefer a tool with MCP, then one with a CLI, then one with an API. A tool with none of the three will slow you down and stop you being AI-native.

The clearest example in our stack is Paper, a design tool the agents drive over MCP. The agent reads the canvas, draws new frames onto it and exports the result into the codebase. I can literally ask an agent to design a new page for augmented.engineering because it can read our design guidelines and create pages via paper.design MCP.

• All context accessible to any agent via MCP, CLI or API
• If a tool can't do the job, code is cheap now, so we can just create one and talk to it over MCP.
• AgentMail over a human inbox... this is another great example of being AI-native: your agents read emails before you do.

TLDR: Rip out the tools agents cannot talk to, however comfortable they are.

03Everyone should learn the terminal

The terminal stopped being an engineers-only tool the day agents moved in. The strongest agents live there: Claude Code, Codex and Gemini CLI are all terminal programs. Driving one is typing English into a text window. If you can write a brief, you can run an agent.

Learn a terminal that splits into panes: iTerm2 on a Mac, or tmux anywhere. The panes are the point, because they let the sessions multiply. One agent builds the feature while a second drafts the proposal and a third works through the inbox. Work you kick off before a meeting is finished when you come back. You stop being a maker who occasionally delegates and become a director who occasionally makes. The work in front of you is reviewing diffs, and your judgement sets the pace.

I've set up Coworktocode.com to help anyone learn the basics of the CLI in a day. The speed and capability boost of switching to the terminal allows everyone in the company to use the codebases (products) as context. For example, I don't think a company can consider itself AI-native if the CEO doesn't have agents open in the terminal.

04Package repetition into assets

The rule is simple: the second time you do something, turn it into an asset. A repeated task becomes a packaged skill. A repeated project setup becomes a template. A repeated correction becomes a standing instruction the agents read on every run.

Raising an invoice used to be a task here. I would open a document editor and change all the details by hand. It is now a skill: numbering, the company lookup, the PDF, all of it runs from one line; or even better, an agent will make one because it can and it knows it should. The faster invoice is the small win. The bigger one is that every engagement leaves an asset behind, and the next engagement starts further ahead because of it.

You do not have to write every skill yourself. Public libraries exist, and the best known is Matt Pocock’s skills repository: around 40 workflow skills covering planning, test-driven development and code quality. One warning. A skill is a set of instructions your agent will follow with your credentials, so an unvetted skill is a prompt injection risk. Read a skill before you install it, the way you would read a script before running it.

The second time you do something,
turn it into an asset.

05Write the spec, not the code

When execution gets cheap, the brief becomes the work. The practice has a name now: spec-driven development. Plan before building. Write the specification or PRD the agents execute against, and put your care into the sentences rather than the syntax. An ambiguous spec turns into wrong software at machine speed. The whole loop, conversation to spec to running build, can happen inside a day.

The spec is half the job. Checking what comes back is the other half. Agents iterate by changing code and running the checks. Where checks are missing, the loop has no feedback and the agent is guessing, however confident the output looks. We gate coverage and complexity in CI with SlopGuard, a tool we built for exactly this. And we have agents test the running product with Playwright, driving a real browser the way a user would.

Generated code is abundant now. Verification, guardrails and monitoring are what separate a team shipping software from a team shipping slop.

06Treat software as disposable

Now that code can be generated many times faster than humans could ever write it, the old rules flip. Build the one-off migration script, the internal dashboard, the tool that only one engagement will ever use. Throw it away without guilt when it has done its job. This is JIT (just-in-time) software. The instinct that custom software is precious came from custom software being expensive, and that has stopped being true. We can now be selective in what 3rd-party tools we use.

The change reaches further than tooling. A business that rents 12 SaaS products can now own the 3 it actually needs, built to fit. And if you sell your time, price the outcome rather than the days. On a day rate, being fast is a pay cut.

07What AI-native is not

To me, it is not strict adherence to maximal automation and token burning. Knowing which decisions stay human is most of the skill. When you understand how neural networks and LLMs actually work, you see why everything online is starting to look the same. Using AI alone will not help you stand out: taste, judgement and fine-tuning are how to stand out whilst being AI-native.

It is also not unbounded access. An agent with your credentials can do everything you can do. Scoped permissions and sandboxes are part of the craft, not an afterthought. Prompt injection, compromised dependencies and cyber risks are all very real now. It's not all speed and productivity-boosting goodness; there are real risks we are still learning to avoid.

None of this needs a bigger model. It needs the working day rebuilt around what agents are good at, with the judgement kept human. Start with recording, the easiest of the 6, and let every engagement leave the next one faster. And if you would rather have this running inside your business than described to you, that is what we do. So get in touch for a deeper dive into your situation.