How I went AI-native in my terminal workflow

Every developer has a workflow they've spent years refining.

Mine lives almost entirely in the terminal. I'm SSH'd into a development machine. I organize my sessions with tmux, edit code in Vim, and use git worktrees to juggle multiple tasks in parallel.

When people talk about AI-native development, the conversation sometimes assumes developers will converge on the same new workflow. A new IDE, a new interface, a new way of building software.

In my experience, that's not how developers work.

Developers rarely abandon workflows they've spent years building unless the benefits are overwhelming. The adoption barrier is real. So as part of my own journey to becoming “AI-native,” instead of trying to replace my workflow with something new, I've been experimenting with evolving it to incorporate agents.

And once I started, a pattern emerged quickly: most development tasks follow the same sequence of steps, so I built a small set of commands and sub-agents that automate these steps all from inside the terminal workflow I was already using.

For me, becoming "AI-native" didn't mean switching tools or adopting a completely new environment. It meant teaching agents how to work inside the workflow I already had.

My baseline workflow

Before agents entered the picture, my workflow already had a structure that worked well for me. It’s terminal-first and optimized for working on multiple things at once. I typically:

• SSH into a remote development machine
• Use tmux to maintain persistent sessions and layouts
• Edit code in Vim
• Create a separate git branch for every task
• Use git worktrees to work on multiple features in parallel

This setup makes it easy to keep tasks isolated and organized. Each feature has its own branch and workspace, and tmux lets me keep everything running without losing context when I disconnect.

It’s a workflow built around parallelism and persistence, and after years of using it, it’s deeply ingrained.

Introducing agents into my workflow

When I first started experimenting with agents, the interaction was mostly manual. I would write prompts describing the problem, ask the agent to investigate, iterate on solutions, and gradually guide it toward an implementation.

After doing this for a while, something became obvious: most development tasks follow a repeatable sequence. The exact details vary, but the overall loop is remarkably consistent:

1. Investigate the problem domain
2. Explore possible solution approaches
3. Plan implementation and testing
4. Generate and iterate on code
5. Fix build issues, linters, and unit tests
6. Run verification steps and validation tests
7. Publish a PR and address review feedback

Initially, I was manually prompting agents through each of these steps. Eventually I realized: this isn’t just prompting. It’s a workflow.

And workflows can be automated.

Going fully AI-native: my workflow became a plugin

I built a custom plugin for Auggie, the CLI tool I use for agentic development that captures the steps I typically run through when working with agents and packages them into reusable building blocks: skills, commands, and sub-agents.

Instead of writing prompts from scratch every time, I can trigger predefined workflows that guide the agent through the process. For example, instead of manually prompting an investigation, I can run a command that launches a structured investigation workflow.

/research-task
Investigate the codebase and produce a research report with all the context needed for design and implementation.

Reads: task.md (required)
Writes: research.md — synthesized findings including relevant files, key abstractions, patterns, constraints, and open questions.

The same goes for planning, implementation, verification, and other common tasks. I’ve made my plugin repository public on Github. Check it out.

Over time this has become something like a prompt library, but encoded as tooling rather than a collection of text snippets.

The result is that I spend far less time writing prompts and more time reviewing, guiding, and refining what the agent produces. And that’s AI-native.

Organizing the artifacts agents generate

One thing you notice quickly when working with agents is that they generate a lot of artifacts: investigation reports, design documents, implementation specs, verification plans, etc. The same principles that made my baseline workflow effective — isolation and persistence — turned out to apply here too. Just as git worktrees give each feature its own workspace, my plugin gives each task its own directory:

~/tasks/
>   feature-login-refactor/
>   search-index-performance/
>   billing-webhook-fix/

Inside each folder are the artifacts produced during development, and these task directories map directly to the git branches and worktrees associated with the work. Code lives in the worktree, context lives in the task folder, and the branch ties them together. Each feature has a clear home for everything related to it.

It's the same idea behind my original workflow — keep things parallel, keep things isolated, make it easy to pick up where you left off — just extended to include the artifacts agents produce.

AI-native won’t look the same for everyone

From the outside, AI-native development sometimes sounds like a dramatic shift with new tools, new environments, and new ways of working.

In practice, for me going AI-native has been more incremental. I didn’t abandon my workflow. I evolved it.

Agents now participate in parts of the development loop that used to be entirely manual, but they do it within the structure of a workflow I already know well.

Getting here required some experimentation and a fair amount of DIY work. I had to assemble building blocks, automate pieces of the process, and gradually refine the system until it felt natural. And that process might look different for you.

Every developer’s workflow is different. Some live in IDEs. Others live in the terminal. Some prefer highly integrated environments, while others assemble their tooling piece by piece.

As agents become a bigger part of the development process, I don’t think those differences will disappear. If anything, they’ll become more pronounced.

AI-native development won’t converge on a single interface or workflow. The most effective setups will be the ones developers shape themselves, combining agents, tools, and automation in ways that fit how they already work.

For me, that means tmux sessions, git worktrees, Vim, and a growing collection of agent workflows running inside the terminal. The tools have changed. But the workflow is still mine.

How are you evolving your workflow?