I've spent the past year migrating my entire engineering practice to AI-first development. Not just "using Copilot for autocomplete" — I mean fundamentally changing how I approach every piece of work. Starting with the agent, not the file. Thinking in plans, not code. Directing, not typing.
Along the way I've made plenty of mistakes, watched my team make theirs, and gradually arrived at a set of habits that work. This isn't theory — it's pattern recognition from the trenches.
Below are the practices I've found genuinely valuable, and the ones that look smart on paper but hurt you in practice. Some of these will be uncomfortable. That's the point.
This is a powerful discipline. If you open the file first, your brain locks into local optimisation. You anchor on the current implementation. You think in terms of patching.
When you start with the agent, you're forced to articulate: What problem are we solving? What constraints matter? What trade-offs exist? What does "done" look like? That reframing alone often improves solution quality — regardless of who or what writes the code.
There's also a compounding skill component here. Prompting well is a real capability. It gets better with practice. If you default to manual code whenever something feels easy, you never train that muscle. Six months from now, the engineers who trained it will operate at a fundamentally different speed than those who didn't.
AI agents perform dramatically better when the problem is decomposed, constraints are explicit, architecture is discussed before code, and success criteria are defined upfront.
You're effectively enforcing a "design first" discipline. That's good engineering regardless of AI. It also mirrors how senior engineers already operate: clarify first, implement second.
The practical difference is enormous. A well-planned prompt produces code that's architecturally sound on the first pass. An under-specified prompt produces code that works but is built on the wrong assumptions — and you spend more time fixing the foundation than you saved by skipping the plan.
Every time you think "I can do this faster myself" and override the agent, you skip learning how to delegate precisely, how to review AI output efficiently, when the agent is reliable versus hallucinating, and what prompt granularity works best for which problems.
There is a real trajectory effect here. Early discomfort compounds into later leverage. The engineers who pushed through the awkwardness in the first few weeks are now the ones running five agents in parallel without breaking a sweat.
This is especially true during a learning phase. Bias heavily toward AI use to build the muscle. The speed comes after the skill — not before.
When AI output disappoints, 90% of the time the problem isn't the model — it's the input. You didn't spend enough tokens on context, user stories, constraints, or domain knowledge. You treated AI like a vending machine instead of a capable colleague who needs a proper briefing.
Share your loose thoughts, your half-baked ideas, your "what if" scenarios. Describe not just what you want, but why. Tell it what worries you. Tell it what you've already considered and rejected. AI doesn't get confused by too much context — it gets confused by ambiguity.
The engineers who produce the best AI output are the ones who've learned to narrate their thinking. They talk to the agent like they're briefing a skilled colleague who's going to do the actual work. Because that's exactly what's happening.
AI-generated code is generally excellent at the implementation level. Naming, structure, comments, edge case handling — it's consistently good. Where it can fail is at the architectural level: choosing the wrong pattern, missing a cross-cutting concern, optimising for the wrong dimension.
This means the important conversations need to move upstream. Instead of reviewing code in pull requests line by line, review plans before implementation. Discuss the context, the proposed approach, the trade-offs. If the plan was right and the model capable, the resulting code is virtually guaranteed to be solid.
Human attention creates the most value at the design level, not the syntax level. Let AI review AI-generated code — it's better at it than we are.
To be clear: we're not removing the review. We're removing the human from the review. At AutoUncle, we removed branch protection rules that required human approval before merging. That sounds reckless until you see what replaced it: automated AI code review, linters, validators, test suites, and enforcement layers that run on every pull request without exception. The review is more thorough than it ever was — it just doesn't require a human to sit and read every diff. (For a deeper look at how those enforcement layers work, see Don't Just Tell It. Enforce It.)
When AI makes the same mistake twice, that's not an AI problem — it's a documentation problem. Every repeated error is a signal that something needs to be written down: in a skill, an agent configuration file, a project-level instruction, or a team standard.
This is where AI has a structural advantage over human teams. A human colleague might forget a correction and drift back to old habits. A documented instruction persists forever and is followed every single time. The compound effect of this is enormous — after a few weeks of encoding corrections, the agent becomes remarkably attuned to your project's specific conventions and preferences.
Think of it as training a very capable, very obedient colleague who never forgets what you told them.
This is where the real productivity unlock happens. You are no longer serialised by your own typing speed or cognitive bandwidth. Kick off a task, detach, start a second one, review the first when it finishes, start a third. Boris Cherny, head of Claude Code, ships 10 to 30 pull requests a day this way.
The skill here isn't multitasking in the traditional sense — it's context-switching between ongoing streams of work, each of which is being executed by an agent. Your job becomes a mix of director and quality controller: set direction, check output, redirect, repeat.
It takes practice. But once it clicks, going back to single-threaded work feels like going back to dial-up.
When AI handles all layers of the stack equally well, the human who understands the full product has an enormous advantage over the one who only knows one layer deeply. "I'm a backend engineer" was a function of cognitive bandwidth limitations. AI doesn't have that limitation.
The most effective engineers I see are hybrids: product engineers with design sense, infrastructure engineers who understand the business, data scientists who can ship a feature end to end. They cross disciplines because AI lets them — and because the problems worth solving require it.
Don't narrow. Widen. Understand the user, the business, the architecture, and the domain. That broad judgment, combined with AI's speed, is an extraordinarily powerful combination.
Planning mode is powerful, but it has a shadow side. Over-planning with AI can create long theoretical architectures that diverge from reality, analysis paralysis, and over-generalised designs that aren't needed.
Some changes are genuinely tactical. A bug fix in a well-understood module. A config change. A copy update. The overhead of structured planning can exceed the cost of just doing the thing.
A good heuristic: if the task affects architecture, contracts, or multiple components — plan. If it's local, well-understood, and low-risk — prompt directly with constraints. Don't turn a five-minute fix into a twenty-minute planning session.
This is the hardest habit to break. We spent years training ourselves to read code carefully, catch subtle bugs in review, hold mental models of implementation details. That skill was valuable when humans wrote the code and the implementation level was where mistakes hid.
It's not where mistakes hide anymore. AI-generated code at the line level is consistently good — often better than what most humans produce. The mistakes happen at a higher level: wrong architecture, missing requirements, incorrect assumptions about the domain.
Line-by-line code review of AI-generated output is a poor use of your time and expertise. Review the plan. Review the architecture. Review the test coverage. Let AI review the code itself. Your brain is needed elsewhere.
And here's the uncomfortable corollary: it's not the number of lines of code that makes a pull request risky. A large PR is hard for a human to review — but an AI agent with a 200,000-token context window can comfortably read a 20,000-line diff. It actually prefers full context over micro-increments, because it can reason about the whole change at once instead of guessing what's missing. So the old instinct to break everything into small, reviewable PRs isn't about risk management anymore — it was about human cognitive limits.
What actually determines risk has nothing to do with line count. A massive new feature that no user has onboarded to yet? Extremely low risk — even if it's thousands of lines. Nobody is affected if something is off on day zero. But a few hundred lines that change a core data model, trigger a database migration, or alter business logic that thousands of users depend on? That's high risk regardless of size. That's where you break things down — not because of the diff, but because of rollout risk, data integrity, and availability. And that's where production monitoring becomes your safety net: the ability to see what's happening the moment those changes hit real traffic.
Programming languages were designed for the human brain. Python's readability, Ruby's expressiveness, Go's simplicity — all of these are artifacts of human preference. They exist because we needed a way to express logic that was comfortable for our cognition. A computer doesn't care. An LLM doesn't care.
When AI writes all the code, the language becomes an implementation detail. Like which brand of shovel the excavator replaced. The "tabs vs spaces" era is over. The "which framework is more elegant" debate is over. What matters is runtime performance, ecosystem maturity, and deployment constraints — not human ergonomics.
Boris Cherny — who literally wrote the book on TypeScript — put it plainly: an engineer on his team built an entire production service in Go over the course of a month. When asked how it felt, they said: "I still don't really know Go." And it didn't matter. The service works. It's correct. It's efficient. The language was irrelevant.
Spend your energy understanding systems, domains, and trade-offs. Not syntax.
Knowing which npm module to use, which Ruby gem handles edge cases best, which Python library is actively maintained — this used to be genuine tribal knowledge that took years to build. Engineers who carried this knowledge were valuable precisely because it saved the team from bad dependency decisions.
AI has completely absorbed this. It knows every popular package, their trade-offs, maintenance status, bundle sizes, and security histories. It evaluates alternatives faster and more thoroughly than any human can.
What remains valuable is the judgment layer above: whether to add a dependency at all. The cost of external dependencies, the risk of unmaintained packages, the strategic case for building in-house. That's architectural thinking, not library trivia. If your competitive edge was knowing which packages to reach for, that edge is gone.
"Always use AI" sounds disciplined, but as a permanent rule it's counterproductive. Your job — especially as a senior engineer or engineering leader — isn't to maximise AI practice reps. It's to maximise impact.
Sometimes you already know the exact three-line change. The cognitive overhead of prompting exceeds the cost of typing. The feedback loop needs to be ultra-fast, and adding an AI round-trip slows you down.
The right framing is phase-dependent. Early phase: bias heavily toward AI use, even when it's slower, to build the muscle. Later phase: choose the fastest path to outcome — which often includes AI, but not always. Don't turn a discipline into a religion.
"I'm a backend engineer" or "I'm a frontend developer" was always a function of cognitive bandwidth. No single human could master React, Node, PostgreSQL, Kubernetes, and CSS animations deeply enough to be productive across all of them. So we specialised.
AI doesn't have that limitation. It's equally competent across the full stack, simultaneously. Which means the human's role shifts from deep expertise in one layer to broad understanding of the entire product: how the user interacts with it, how data flows through it, what the business needs.
The engineers who will thrive are the ones who always wanted to understand the full picture but were constrained by the time it took to master each layer. That constraint is gone.
There's a natural instinct to watch the agent work. To read every line as it's generated. To hover over the terminal. It feels responsible. It feels like quality control.
It's actually the opposite. Watching the agent work is like standing behind the excavator and checking every scoop of dirt. You're not adding value — you're burning attention that could be directed toward the next piece of work, the next plan, the next decision.
The right rhythm is: set direction, let the agent execute, review the output, redirect if needed. Not: set direction, watch every keystroke, intervene constantly, wonder why you're not faster. Trust the process. Check the result. Move on.
This might be the most important don't of all. Capabilities that didn't exist three months ago are now standard. Models that were cutting-edge in October feel dated by February. If you tried something six months ago and it didn't work — try it again. It probably works now.
Any assessment of "what AI can and can't do" has a shelf life of about three months. The engineers and teams who update their mental models frequently have a compounding advantage over those who formed an opinion once and stopped re-evaluating.
Stay curious. Keep experimenting. The worst thing you can do right now is conclude that you've figured AI out.
For the emotional side of this shift — the guilt, the identity crisis, and why the old rules weren't wrong — read It Wasn't Wrong. For a deeper playbook with principles and daily tactics, there's the AI Cookbook. The 75 Questions covers the full FAQ. And if you want to go beyond rules into truly deterministic quality enforcement, Don't Just Tell It. Enforce It. is the natural next step from the "encode every repeated mistake" principle above. For how those same principles extend to production operations — monitoring, infrastructure as code, and giving AI access to your entire ops stack — read Still True. For podcasts that keep you sharp, I've curated a shortlist of the best AI shows. And if you haven't already, listen to Lenny's interview with Boris Cherny — it's the clearest picture of where this is all heading.