Every engineering team is experimenting with LLMs right now. Few have a clear point of view on where they actually help versus where they just add noise. Here's how we think about it when we step into a team as fractional engineering leadership.
Where LLMs genuinely help
Onboarding into unfamiliar codebases. When we take on a new engagement, the first week is usually spent understanding a codebase someone else built. LLMs are good at answering "what does this do and why" faster than reading commit history alone, which shortens the time before we can make credible recommendations.
Code review as a first pass, not a replacement. An LLM catching an obvious null-check miss or a missing test case before a human reviewer sees the PR means the human review focuses on the things that actually require judgment: architecture fit, whether this is the right problem to solve, whether it creates a maintenance burden six months out.
Drafting, not deciding. Documentation, runbooks, onboarding guides, first-pass incident postmortems: LLMs are useful for getting a structured draft in front of a human quickly. The judgment on what's actually true, what matters, and what to cut still has to come from someone who was in the room.
Surfacing options, not making the call. When we're evaluating a technical approach with a team, it's often useful to have an LLM lay out three or four ways to solve a problem with their tradeoffs, as a starting point for discussion, not as the decision itself.
Where we're careful
People decisions stay human. Performance reviews, hiring calls, and management coaching are exactly the kind of judgment work that motivated bringing in fractional leadership in the first place. We don't outsource that judgment to a model.
Security and access boundaries don't change. Secrets, customer data, and credentials don't go into prompts, regardless of which tool is asking. Whatever review process a team already has for external tools applies to AI tools too.
Ownership doesn't move. Code that ships is owned by the engineer and the team that shipped it, whether or not an LLM helped write part of it. "The AI wrote it" is not an acceptable answer in a retro.
Speed isn't the only metric. A team that ships faster with LLM assistance but loses the ability to explain its own codebase has traded a short-term win for a long-term liability. Part of the job is watching for that trade before it becomes a problem.
The actual point
None of this is really about the tools. It's the same principle behind fractional engineering leadership generally: use the leverage available to you, but keep judgment, ownership, and accountability with people, not with whatever's fastest in the moment. LLMs are a productivity tool inside that frame, not a replacement for it.
If you're thinking about how your own team should adopt AI tools without losing the judgment that makes engineering leadership valuable in the first place, that's exactly the kind of conversation we have in an engineering scale consultation.