On joining a small, AI-native team, and the dilemma of slowing down versus shipping like everyone else.

Day five

It’s day five. You’ve cloned the repo. You’ve sketched a half-mental-model of how the auth flow probably works. You’ve started piecing together what the three different folders, all named some variant of “service”, actually do.

Then your Slack lights up.

A teammate just shipped a feature you didn’t even know was in the backlog. A PR opens. Three reviews land in nine minutes. It merges. Another one drops before lunch. By the end of the day, the team has shipped roughly a sprint’s worth of work, and you have written maybe forty lines of code, half of which you’re not sure about.

Welcome to the modern small team. AI in the loop, everyone moving fast, and you, the new hire, feeling like the slowest creature in a room of velociraptors.

And then the question that won’t leave you alone: do I slow down and learn this system properly, or do I lean fully on AI, ship at their pace, and trust the tests, my reviewers, and a bit of luck to keep me out of trouble?

It feels like a binary choice. It isn’t. But to see why, you have to be honest about what each path actually costs.

The turtle path

The first path is the one every senior engineer has historically advised: slow down. Read the code. Trace a request from the edge through the system. Understand the data model before you touch it. Earn the right to write a one-line change by knowing exactly which one line it should be.

This advice is right in spirit and brutal in practice on a fast team. Because while you’re reading, your peers are shipping. Their context grows; yours grows too, but theirs grows on top of new features they just built, while yours grows on a snapshot of the code that is already drifting out of date.

You start to feel a quiet shame around standups. You hedge. You ask questions in DMs instead of channels because you’re afraid they reveal too much. The “I’m just ramping up” line works for a week. After three weeks, it starts to sound like an excuse — to them, but mostly to yourself.

The bigger problem: the codebase you’re trying to learn is changing under you. The README is half a year stale. Half the abstractions are LLM-generated, which means they look like they should fit a pattern but sometimes don’t. By the time you’ve “understood” the system, you’ve understood a system that no longer exists.

This is the part the old advice doesn’t account for: in an AI-native team, the half-life of codebase knowledge has collapsed. Deep, slow learning still works — but the depreciation curve is steeper than it used to be.

The velociraptor path

The other path is to embrace the speed. Use AI the way your peers do. Have it explain the function you’re editing. Have it generate the change. Have it write the tests. Trust CI. Ship it. You’re not pretending to know the system; you’re outsourcing the knowing to the model and the test suite, and you’re betting that the bets your team has already made (good tests, good reviewers, good observability) will catch you when you’re wrong.

For some tasks, this is fine. For some tasks, it’s the only reasonable choice. A small bug fix on a well-tested endpoint, a copy change, a third migration of a pattern that already exists three times, there is no reason for you to spend three days mapping the codebase before doing it.

But here’s the part nobody on the team will say out loud: the model is fluent and confidently wrong, and your reviewers are moving fast too. A pull request can pass with a green check and two thumbs-up and still introduce a subtle issue that only shows up under specific load, or that quietly breaks a contract that wasn’t covered by a test because nobody thought it needed one. AI accelerates everyone, including the people reviewing your code, and acceleration without proportional rigor means errors slip through faster, not less.

There is a version of this path where it works. There’s another version where you wake up one morning to a production incident, look at the diff, and realize: you wrote the code, your reviewer skimmed it, the AI generated the part that broke, and none of the three of you actually understood what it was doing.

Why there’s no universal answer

So which is it? Slow down or speed up?

I don’t think there’s a single answer, and I’ve come to distrust anyone who says there is. It depends on at least five things:

• The blast radius of the system you’re touching. A payments service is not a marketing site. The cost of a wrong AI-generated change on critical-path code is orders of magnitude higher than something you can revert in a click.
• The maturity of the safety net. Strong test coverage, clear ownership, good observability — these mean you can ship fast and learn from production. Without them, “ship fast” is just “break things and hope.”
• Your background. A senior engineer joining a new codebase has stronger pattern-matching priors. They can read a diff and feel when it smells wrong, even without understanding the specifics. A junior doesn’t have that radar yet.
• The team’s actual norms. Some teams say “move fast” and mean it. Others say it and quietly resent the person who breaks production. Watch what actually happens after an incident, not what the README says about culture.
• The task itself. Wiring a new component to an existing pattern is different from designing a new abstraction. The former tolerates speed. The latter punishes it.

The honest move is to treat the slow-vs-fast question as case-by-case , and to be deliberate about which mode you’re in.

A few things that actually help

After watching myself fumble through this, and after talking to other people who’ve gone through it, here is what I’d suggest. Not as rules. As experiments.

Try both modes, on purpose. Pick one task this week to do the turtle way. Read everything around it. Trace it end-to-end. Write the change yourself. Let AI critique it afterwards. Pick another task and do it the velociraptor way — let AI drive, ship as fast as you can responsibly, see what happens in review. Then compare. You’re not choosing a tribe. You’re calibrating your instinct for which mode fits which task.

Use AI as a teacher on the slow path, not just a worker on the fast path. When you’re reading the codebase, asking a model to explain a function, sketch the call graph, or contrast two abstractions is dramatically faster than doing it alone. The turtle path got slower than it needed to be because most of us learned to use AI to compress the writing, not the learning.

Pick a sub-system to actually own. You cannot understand the whole codebase fast. You can pick a corner — a service, a flow, a domain — and become the person who knows it cold within a couple of weeks. That earned ground gives you the confidence to ship fast everywhere else, because you know what real knowledge feels like and you can recognize when you don’t have it.

Watch your taste returning. The signal you’re learning, even on the fast path, is when AI-generated code starts to feel wrong before you can articulate why. Until that feeling kicks in for a given area, you should review every AI suggestion with a slight squint. Once it does, you can move faster there with more trust.

Question the path, not just the line. AI is fluent at the level of code — but it can confidently walk you down the wrong path. You’ll find yourself two hours into an implementation, look up, and realize: this could have been a five-line fix instead of a 200-line abstraction. Or that the model has been “improving” something that didn’t need improving in the first place. The subtle nuances — is this the right problem, at the right level, with the right blast radius? does this even need to exist? — are exactly the parts AI cannot reliably deliver. They require sitting back, ignoring what’s on the screen, and asking whether the direction is honest.

And the inverse is also true. Sometimes the model spots an edge case you never would have considered. It names a failure mode you’d have missed. It points at a library function that does the thing you were about to hand-roll. The posture that works isn’t trust or distrust — it’s a working partnership where the model brings breadth and recall, and you bring the willingness to say no, simpler or no, that’s not the right shape at all. If you give up that role, nobody on the team is playing it.

Pre-commit to a “stop and read” trigger. Decide in advance what kind of change makes you pause: anything touching auth, anything touching money, anything in a file you’ve never opened, anything where the test you’d need doesn’t exist yet. Without a trigger, the speed of your peers will pull you into shipping things you shouldn’t.

Track your own incidents — silently. Keep a private note of every bug you ship in the first three months. What was the cause? Did you understand the code? Did the AI generate the broken part? Did you skip a test you should have written? After ten entries, your pattern is in front of you. It will tell you, more honestly than any retro, where you can safely run fast and where you need to slow down.

What the discomfort actually means

The one I’ve had to keep telling myself: the discomfort of feeling slow is not a signal you’re doing it wrong. It’s the price of caring about the system in a culture that has, sometimes, stopped caring quite as much as it used to. That care is what keeps the team from one day waking up inside a house nobody actually understands.

The right answer probably isn’t turtle. It probably isn’t velociraptor either.

It’s the engineer who knows which one they’re in at any given hour and why.

If you’ve joined an AI-native team recently, I’d love to hear how you handled the first three months. The honest version, not the LinkedIn version.