LLMs as a Team Multiplier: Driving Innovation Without Losing the Human
Six months ago, one of my engineers used an LLM to generate the skeleton of an Ansible role for a service he'd never automated before. He'd been putting it off for weeks because the learning curve felt steep and his ticket backlog was relentless. With a generated starting point, he had a working first draft in an afternoon, spent two days refining it into something QA -> production-worthy, and now maintains it with confidence. The LLM didn't do the hard work. It removed the blank-page paralysis that was preventing the hard work from starting.
The Activation Energy Problem
Every engineer on my team has a list of things they know they should learn, build, or improve, but haven't gotten to. Not because they lack capability, but because the startup cost feels prohibitive when measured against their current workload. Learning a new tool from scratch, writing documentation for a system only they understand, building a monitoring dashboard from nothing. These tasks sit in the "important but not urgent" quadrant until they become urgent, at which point they get done poorly under pressure.
I find that LLMs compress the startup cost. They don't eliminate the expertise required to finish the work well, but they dramatically reduce the time between "I should do this" and "I have something I can iterate on." For a team already stretched thin, that compression is the difference between innovation happening and innovation staying on the backlog indefinitely.
How We're Using It
I want to be specific about the use cases that have actually produced value for us, rather than speaking in generalities.
| Use Case | What the LLM Does | What the Engineer Still Does |
|---|---|---|
| Ansible role scaffolding | Generates task structure, variable templates, handler patterns | Reviews for idempotency, tests in QA, adapts to our environment |
| Documentation first drafts | Produces structured docs from engineer's bullet-point brain dump | Validates accuracy, adds tribal knowledge, reviews for completeness |
| Troubleshooting brainstorm | Generates a list of potential root causes given symptoms | Applies environment-specific knowledge to narrow the list, actually investigates |
| Code review prep | Summarizes a large PR's changes in plain language | Makes architectural judgments, identifies edge cases the summary missed |
| Cross-training materials | Drafts docs for a system based on existing repos | Fills in the "why" behind decisions, adds war stories and gotchas |
The common thread is that the LLM handles the structural/mechanical work while the engineer provides the judgment, context, and institutional knowledge that no model has access to.
The Skill-Sharing Multiplier
The use case I'm most excited about is cross-training. In infrastructure, knowledge silos are a constant risk. When only one person understands a system deeply, their absence (vacation, sick leave, departure) creates a fragility that everyone can feel but nobody addresses until it becomes a crisis.
LLMs have lowered the barrier to creating cross-training materials. The engineer who owns a system can now spend 30 minutes doing a brain dump into a prompt, get a structured first-draft document back, spend another 30-60 minutes refining it, and produce something that would have previously taken half a day to write from scratch. The output isn't perfect, but it's a starting point that other team members can engage with, ask questions about, and build on.
We've produced more internal documentation in the last six months than in the two years prior. Not because people suddenly started caring about documentation (they always cared), but because the activation energy dropped below the threshold where it was realistic to fit into a normal workweek.
Where I Draw Lines
There are places where I've explicitly told the team not to lean on LLMs, and I think the boundaries matter for maintaining engineering quality.
Architecture decisions can't be outsourced to a model. The LLM doesn't know our environment, our constraints, our history of what's been tried and failed, or our team's operational capacity. It can generate options, but the selection among those options requires human judgment informed by context the model doesn't have.
Incident response can't be slowed by prompt engineering. When a production system is down, I need engineers troubleshooting with their own mental models, not waiting for a chatbot to generate suggestions. The time pressure of an active incident doesn't accommodate the iteration cycle that LLM usage requires. Want to ask it questions or feed in error messages in parallel, while you're triaging the issue? That works for me, but I only trust human hands in production.
Performance reviews and feedback are human-only exercises. I will never use a model to draft feedback about a person's career growth. That work requires the relationship context and specificity that only comes from having worked alongside someone and observed them over time.
The Cultural Shift
The hardest part wasn't getting the team to use LLMs. It was getting them to talk about it openly, and find somewhere to share their growing knowlege. There's a stigma (slowly fading, but real) around admitting you used AI assistance. We addressed this directly in a team on site, that using tools effectively is a skill, not a shortcut. The engineer who generated a scaffold and then spent two days refining it into production-quality code exercised more judgment, not less, than the one who wrote it from scratch without questioning any of their assumptions.
The cultural permission to say "I used an LLM for the first draft" without it being read as a competence admission has been one of the more impactful things we've done this year. Innovation follows permission, and permission follows psychological safety.
What's Next
We're experimenting with a monthly "AI show and tell" where team members share a prompt pattern or skill that saved them time. Not mandatory, not evaluated, just a venue for cross-pollination. Engineers are learning from each other's usage patterns, and the overall sophistication of how the team uses these tools is climbing steadily.