The AI-Native Engineering Playbook: Crawl, Walk, Run, Fly
A framework for engineering teams ready to go all the way with AI
A friend called me recently. He works at a consulting company and they'd been asked to explore what "AI maximalist" engineering practices look like. His team already uses Claude Code — they're past the basics. But he wanted to know: what does it look like when you really go all the way?
I've been helping teams do exactly this for the past couple of years. Going all the way means more than faster coding — it means replacing Jira, scrapping two-week sprints, redefining what engineers actually do all day. Here's the framework I use, in four stages you can't skip.
Crawl: A Traditional Competent Software Engineering Team
Your team needs to be able to ship software before AI can make them faster at it. Working CI/CD, understood testing environments, confident deploys and rollbacks. If you don't have this floor, fix it first — AI won't save you from broken fundamentals.
From where we're headed, traditional software engineering velocity looks ridiculously slow — essentially crawling. Spending two days refactoring a few files, or shipping one bug fix per week, is still considered normal.
Surprisingly many teams are not even allowed to use LLMs at work, or only unofficially. You could also call this the ChatGPT stage: at best, people are using ChatGPT or similar to discuss some of their work-related stuff.
Walk: Let Everyone Have Their "Claude Code" Moment
Give everyone an agentic coding tool — Claude Code, Codex, Cursor — and let them explore. No mandates, no process changes yet. Just access and encouragement.
The critical thing that happens at this stage: people discover that letting an agent change your files locally is fundamentally different from copy-pasting ChatGPT snippets into your editor. The agent modifies your project, runs the server, opens the browser, tests the result. That capability jump changes what you think is possible.
Most people need to experience it firsthand. What works: demos and show-and-tells. Low-risk side projects. Friendly competitions. And patience — this takes weeks to months, not days. If your team hasn't had the "holy shit" moment, nothing that follows will stick.
One warning you'll hit early: coding agents have a bias toward declaring victory. Claude will create 15 files and some unit tests and announce everything is production-ready. Nothing has been tested manually. Nothing has been deployed. No edge cases explored. Recognizing this — and pushing past it so as to be able to ship AI-assisted code to production — is a skill your team needs to develop before moving on.
This is also where most companies stop. They shouldn't.
Run: Everything as Markdown In The Repo
Once your team is productive with agentic coding tools, it's time to rethink the processes around the code. Most of the overhead that slows teams down isn't technical — it's organizational. And there's a new constraint: AI agents are extremely capable and know every programming language, but they're completely unfamiliar with your specific context.
Your job is now context engineering — maintaining a rich docs/ folder that documents the whole service and business you're delivering. Not just technical architecture, but product context, customer needs, success metrics, policies, and constraints. Claude Code can write any code. It doesn't know what your service should do or what growth looks like for your business. Your job is to close that gap.
But you can't provide proper context if everything is spread out over a ton of repos, wikis, issue trackers and documents. You need to bring the context home, to where the agent operates, in the (mono)repo. Everything as markdown files.
Four big changes:
1. Kill Your Jira
Why does your company use Jira? The honest answer is usually the illusion of control. Someone at the C-level wants OKRs broken into epics broken into tickets, all marked done at quarter's end.
The problem: one month in, the plan changes. Nobody restructures the Jira epics because it's impossibly tedious — even with AI. So teams execute a plan they know is wrong for three months. That's not project management. That's theater.
Replace it with two markdown files in your repo:
`NEXT-STEPS.md` — The team's goals, each person's focus areas, and the Friday demo target. Short bullet points. One page.
`ROADMAP.md` — Your longer term plan, divided by 6-8 week phases. Dependencies, constraints, delivery targets. Updated in a dedicated workshop every 6-8 weeks (~8 cycles per year instead of 4 quarters).
No epics. No story points. No sprint ceremonies.
The weekly cadence is one Friday meeting, one hour:
Show-and-tell — demo what you built (visual or not — the point is pride in the work)
Review — what got done vs. plan, what didn't and why
Plan — focus areas and demo target for next week
Record it. Transcribe it. Feed the transcript to Claude Code: "Update NEXT-STEPS.md for next week and archive completed items to DELIVERED.md." Create a PR. Team reviews, catches mistakes, approves. Ask Claude to create a skill to handle this weekly routine.
Two-week sprints existed because half your time went to agile overhead. Remove the overhead and one week is plenty.
Monday morning, every engineer opens Claude Code and asks "what's next?" It reads the plan, knows their focus areas, and they're off. No Jira board. No standup. A better answer than any ticket ever gave.
2. Make Every Meeting Worth Its Transcript
Reframe your meetings: you're no longer talking just for the humans in the room. You're talking for the transcript.
A successful meeting is one where every participant can paste the transcript into Claude Code and immediately get better work done. The transcript is context that you use to update your repo's Markdown files.
This has a non-obvious implication: transcription quality matters more than automation. Microsoft Teams' built-in transcription is convenient but low quality. Feed it to Claude Code and you get vague, hallucinated outputs — the AI is working with garbled input. Run the same recording through Whisper locally and the results are night and day.
Yes, it's extra manual work. A bad transcript that arrives automatically is worse than a great transcript that takes 5 minutes to produce.
3. Let Claude Code Own the Git Workflow
If you use GitHub, the gh CLI gives Claude Code access to branches, PRs, CI status, and issues across your whole organization. Use it.
Claude Code can create PRs, resolve merge conflicts, fix failing CI checks, and address PR review comments — all without you touching the GitHub UI. You describe the change you want, Claude writes the code, pushes a branch, opens a PR, and iterates on reviewer feedback until it's approved.
The engineer's job shifts from writing code and managing git to reviewing PRs and steering direction. You're the tech lead; Claude is the one pushing commits.
4. Kill Most Cross-Team Sync Meetings
Recognize this? A dependency exists such that Team A needs to integrate with the service of Team B. So they set up weekly syncs to check what works and what doesn't. After three months, an initial integration is barely running in staging.
Alternative: have Claude Code check out Team B's repo, read their source code, run their service locally, and work on the integration directly. Use occasional meetings only for higher-level decisions that need coordination. The integration is working within a week, and after a month it's in production.
80% of cross-team sync meetings become unnecessary when your AI can access and run the other team's code directly.
Fly: Turning a Four-Person Team into a Twenty-Four-Person Team
Every engineer on an AI-maximalist team is now potentially a team lead. Instead of picking up one task at a time and guiding Claude through it, each engineer opens 4-6 terminal tabs and runs a Claude Code session for each of their weekly objectives. They manage them in parallel — provide context, review their work, course-correct when they drift. Git worktrees keep sessions from stepping on each other. Everyone always has 3-4 PRs cooking.
Note: Increasing the amount of parallel sessions is no easy feat. It takes skill, practice and intuition from working a lot with agentic coding. This is one of the main new areas of professional development engineers can excel at over time.
When this is second nature — parallel sessions by instinct, context management as a competency, transcripts as a core artifact — you're flying. Teams at this stage ship faster, with fewer meetings, and with more clarity about what they're building than they ever managed with Jira, two-week sprints and an outdated view of what software engineering teams do.
Redefining The Role of the Team
You've rethought your planning, your meetings, your cross-team integration, and your workflows. Now rethink the engineer. With AI handling enough of the mechanical work, you're no longer just a software engineering team. You're a value delivery team that thinks about product outcomes, growth, and KPIs.
The team's focus shifts from software engineering to service delivery — and eventually, to just growth. Along the way, you'll find yourself rethinking processes and workflows from first principles. SaaS licenses you assumed were necessary turn out to be replaceable. Agencies you relied on become redundant. Master data management, reporting, integrations — all fair game for reinvention. More on that in future posts.
If your team is somewhere between walking and flying, I’d love to hear what’s working and what’s not — reply to this post or find me on LinkedIn.
This post grew out of a conversation with Jesse McCrosky, who asked me what an AI-maximalist consulting engagement looks like. Of course we made sure to transcribe our chat to be able to create this blog post. For this reason, he is listed as a co-author of the post. Thanks for the great chat, Jesse!