I’ve been doing AI-assisted development for a while now. Here’s a list of things that are going well. And anti-patterns to avoid. From my conversations with other devs, many are seeing the same things.

There’s a lot of noise out there. The hype merchants promise AI will replace every developer by Tuesday. The skeptics insist nothing has changed. Both are wrong.

What’s actually happening is more interesting. Some things are easier now. Some are the same as they’ve always been. And new failure modes have emerged that need more attention.

TL;DR

  • AI meaningfully reduces the cost of context switching (good news for anyone who attends too many meetings)
  • Your weaknesses become average. Your strengths get amplified
  • You can stay productive later in the day
  • Documentation and in-depth PR descriptions are basically free
  • Shipping code you don’t understand will catch up with you
  • Skill atrophy is real. Keep your skills sharp
  • If nobody deeply understands the codebase, you have a serious problem

AI-assisted wins

Here are some things that are reliably providing value in organizations.

Reduced cost of context switches

The maker vs. manager schedule problem is real. Was real before AI. Still is. But the drag has lessened. I used to dread coming back from a two-hour meeting block.

Sit down at the keyboard.

Stare at the code.

Spend 20 minutes trying to remember what my previous self was doing. By the time I was back in the flow, it was time for the next meeting.

Now I can ask Claude for a quick recap of what we were working on. “Hey, remind me what we were in the middle of.” Back in business in seconds instead of minutes.

Takeaway for TLMs and Engineering Managers: This is a bigger deal than it sounds. Context switching has always been the silent killer of manager productivity. You can now do meaningful development work between meetings.

Expertise less of a bottleneck

Weaknesses become average. I’ve shipped code with technologies I didn’t know well. Tech even a mid-level dev could out-perform me on.

Before AI, that was risky. With AI assistance I could lean on my engineering spidey-sense to evaluate whether an approach was sound while Claude handled the details. The judgment was mine. The solution was collaborative. The result was something I wouldn’t have been able to do otherwise.

Takeaways:

  • This is a productivity win specifically for senior+ engineers. You already know what good looks like. Now you can build it in languages and frameworks that aren’t your native tongue. Junior devs though? Double-edged sword. More on that below.
  • Teams don’t have to be as rigid about having every skill set on hand.

TLMs and Engineering Managers can ship code

Managers are expected to be hands-on now. The bar keeps rising. “Technically credible leadership” used to mean translating your team’s technical challenges to upper management speak. Now it means actually shipping code.

Carving out deep-work blocks has always been a challenge. Constant interruptions. Slack messages. The inevitable “quick question” that takes 45 minutes.

AI lowers the re-entry cost. Let a prompt run while you’re in a status meeting. Check the results after. Iterate. You’re not fully in the zone, but you’re making progress. For most managers, that’s a win.

Enhanced productivity time

I used to be fried by 4 PM. Not every day. But the ones where I actually got into deep flow and knocked out something real. By late afternoon I had nothing left. Starting a new task? Nah.

Now I can hand something off to Claude and keep making progress. Low cognitive lift. Sometimes I catch a second wind and keep rolling. Sometimes I just review the output and call it a day. Either way, I’m still productive at 4:30.

The mental overhead of starting a task has dropped dramatically. That’s not nothing. That’s an extra productive hour or two on days that previously would’ve ended with a blank stare at the screen.

Documentation is easier

Summarization might be LLM’s single most valuable capability.

PR descriptions and wiki pages can be done in seconds. Most of it is good enough to ship as-is. The rest needs a quick pass to remove the slop and hallucinations.

Takeaways:

  • PR descriptions now actually describe what changed. Revolutionary, I know.
  • Wikis that used to never get written are getting written.
  • Review it. Delete the slop. Ship the rest.

AI makes some things easier. It also introduces new ways to fail.

Anti-Patterns

Here are some things that are harming your team.

Shipping code you don’t understand

The AI maximalists will tell you this is fine. Just wait for the next model to come out. We’re one more agent away from total enlightenment!

At some point everything falls apart. When it does, you need to understand the system well enough to fix it. If your codebase was built by an LLM you were barely watching, good luck with that.

Think you can tell when you’re past the point of no return? That’s not how it works. You don’t know you’re over your skis until it’s far too late. And you’ve been dumping in more slop since that point.

A lot of engineering leaders have made their mark by introducing technical debt and “failing up” before the bill is due. Before AI, you might have had a couple years leeway. Now it could be weeks.

Takeaways: The time to system failure is faster. Engineering rigor still matters. Weak leaders will be exposed earlier.

Skill atrophy

When I was a Director I was deeply involved with the technical decisions. And I still shipped code. But my hands-on skills drifted.

AI is now causing this with ICs who are shipping code daily. If Claude is doing most of the thinking, you’re not using the mental models that make you a strong engineer. You’re a reviewer. Reviewers don’t develop the same depth as builders.

Takeaway: your team is getting worse every day.

Superficial knowledge

When you review Claude’s code, you have the same relationship to that code as any reviewer has to code they didn’t write. You understand the surface. You might catch obvious issues. But you don’t have the deep understanding of someone who built it from scratch.

At scale, this is scary.

On the other hand, if no one understands the codebase: you’ve technically removed the bus/lottery problem. There’s no one important enough to worry about leaving. Still, not a solid plan.

Takeaways:

  • Junior developers aren’t getting the same reps that built senior developers. That gap is being created right now.
  • Senior+ devs: make sure you actually understand your systems. Not just the architecture diagram. The code.

Success patterns

Here are ways we can fight the anti-patterns being introduced.

Create time to review your own code

Schedule self-review time. Block it out on your calendar for times when you have the mental bandwidth to dig deep. If you can’t explain what a piece of code does, you’re not done with it.

AI writes code faster than you can review it.

That’s a recipe for disaster.

Schedule dedicated time to actually read the code you’re shipping. Before creating a PR and passing that mess on to your teammates.

This is the boring advice nobody wants to hear in the middle of a hype cycle. The engineers who skip this step are the ones who will be untangling mysteries six months from now wondering why nothing works. Even in the near-term, your team will thank you.

Keep your skills sharp

Fight skill atrophy. Be intentional about keeping your skills sharp.

Spend a morning writing code without AI. Work through a hard problem yourself. It’s like going to the gym. Skip it for a week, no big deal. Skip it for six months and everyone will notice.

This is career self-preservation too. Hiring loops still require the same hands-on code challenges. And they’ve ramped up the difficulty. Don’t expect the same muscle-memory to be there if layoffs hit and you’re back in an interview loop.

Conclusion

The teams that succeed won’t be the ones who prompt the fastest. They’ll be the ones who still understand what they ship.

We’ll see how this plays out over the next couple years.