Anyone actually using NotebookLM in production for a 10-eng team?

Good question. We've been running a NotebookLM pilot for a three-team platform group (12 engineers) for about four months, grounded in AWS design docs and Terraform module READMEs. The short answer is it's useful for high-level orientation but has critical gaps for production troubleshooting.

On your specific points: Access control is its biggest weakness. It's effectively a flat document repository per 'notebook'. We had to create separate notebooks for 'team-private' vs 'shared' content, which fragments the knowledge base. For a 10-person team, you'll likely manage this manually, which doesn't scale.

The reliability of grounded answers is highly dependent on source structure. It works well for declarative 'what is this module for' questions. For procedural troubleshooting, like a runbook, it often hallucinates step ordering or specifics. We found you must format sources with extreme clarity. A simple example that worked for us was a Terraform module doc structured as:

```
## Module: s3_log_bucket
### Purpose: Creates an encrypted S3 bucket for application logs with lifecycle policy.
### Inputs (variables.tf):
- bucket_prefix (string, required)
- retention_days (number, default: 90)
### Outputs (outputs.tf):
- bucket_arn
- bucket_name
### Common Errors:
- "Error: prefix must match regex" => ensure bucket_prefix uses hyphens not underscores.
```

Cost hasn't been a surprise at this scale; it's negligible. The real cost is the maintenance overhead to keep source documents clean and the risk of engineers trusting a plausible but incorrect synthesized answer for a critical issue. It reduces simple repeat questions but isn't a set-and-forget solution. You'll still need a human-in-the-loop verification step for any operational guidance it gives.

I agree with user1218's assessment on the core limitations, but I'd push back slightly on one point. For a 10-person, AWS/Terraform focused team, I don't think the access control issue is the primary blocker. It's inconvenient, but manageable with a single 'team-global' notebook. The larger problem is the tool's inability to interact with live systems.

You mentioned troubleshooting steps. That's where NotebookLM falls apart. A grounded answer can recite a runbook step, but it can't tell you if your specific VPC peering connection is stuck in `pending-acceptance` or if a Terraform state file is locked. That real-time context is everything.

Consider a hybrid approach. Use NotebookLM as a structured FAQ for your module documentation, but pair it with a CLI tool that can query your actual AWS environment. For a team your size, you might get more mileage from a simple, well-organized Confluence space with strict ownership until the agentic aspects of these tools mature. The graveyard you're worried about is filled with tools that promised more context than they could deliver.

The reliability issue for troubleshooting is key, and it stems from a fundamental architectural mismatch. NotebookLM treats documents as static sources of truth, but effective troubleshooting requires reconciling documented intent with live system state. Your runbook might say "check the VPC peering connection status," but the answer's value depends on querying the AWS API *right now*.

Regarding your request for a source document example, structure is everything. A poorly formatted runbook yields vague answers. For grounding Terraform modules, we found success by enforcing a strict template in the source markdown. This creates predictable, citation-friendly blocks.

```markdown
## Module: vpc_baseline
**Purpose:** Provisions a foundational VPC with three private subnets, NAT gateway, and flow logs.
**Input Variables:**
- `cidr_block` (string): The primary IPv4 CIDR block (e.g., 10.0.0.0/16)
- `enable_flow_logs` (bool): Defaults to true.
**Common Error:** State lock on `aws_vpc.this` often indicates a stalled `terraform apply` in another workspace.
```
This format gives NotebookLM clear, isolated statements to ground in, which improves answer precision for "what is" questions. It still can't tell you if a state lock exists *today*, but it will accurately cite the documented common error. The cost for 10 users is predictable, but the real expense is the engineering time to refactor all your docs into this machine-optimal format.

You've precisely identified the architectural mismatch, and your example template is a solid workaround. That structured formatting is essentially a form of pre-processing for the grounding model.

However, this approach demands a significant, sustained discipline from the entire team to maintain. My team attempted a similar schema for our Terraform modules, but it quickly degraded. The bottleneck wasn't the initial creation, but the consistent updating during PR reviews when engineers are focused on logic, not documentation polish. Without that consistency, the quality of grounded answers becomes a lottery.

This leads to a more critical point: the template optimizes for retrieval, not for validation. Even a perfect answer citing your "Common Error" about a state lock is just a static fact. It can't verify if a lock currently exists, which is the only question that matters during an incident. That's the core limitation no template can fix.

Exactly. The template discipline problem isn't a NotebookLM problem, it's a *documentation* problem. If your team can't keep a basic markdown template updated, no tool on earth will give you reliable answers.

The validation gap is the real kicker though. You're just dressing up a library catalog. It can't tell you if the book you need is checked out or on fire. For troubleshooting, that's useless.

You're spot on about source structure being the critical lever. The formatting trick you used for your Terraform module is basically manual feature engineering for the embedding.

I found a similar need for extreme clarity, but it creates a brittle dependency. Any deviation in future documents, like a contributor adding a "Notes" section after "Inputs," can confuse the retrieval. We started versioning our source documents alongside the code, treating the markdown structure as part of the API contract.

The hallucination on step ordering is a subtle but real risk. It seems to handle lists well, but if a troubleshooting step implicitly depends on the state from a prior step, NotebookLM doesn't model that dependency graph. It'll just serve up steps as independent facts.

That library catalog analogy is perfect. It really highlights the core issue.

So it's like a smart search for a manual that might be wrong or outdated. For basic module docs, that's fine. But if I'm asking "why is my deployment failing", I need to know if the library is on fire *right now*.

Makes me wonder if the real value is just forcing us to have that structured, versioned documentation in the first place. Maybe the AI part is almost secondary?

Yeah, the library catalog analogy from earlier really nails it.

That's what stopped us from adopting it too. The fear of it becoming another graveyard is real, because it only works if your documentation is already perfect and static. For us, that meant the tool just moved the problem - instead of a wiki nobody updates, you have an AI nobody trusts.

It kinda forces that documentation discipline, which might be a good thing? But is polishing static docs the best use of a 10-person team's time when things are on fire?

You've put your finger on the precise operational failure mode: "the bottleneck wasn't the initial creation, but the consistent updating during PR reviews."

We hit the same wall. A template is a schema, and any schema decays without enforcement. We attempted to automate validation with a pre-commit hook that linted the markdown structure, but it created so much friction it was scrapped after two sprints. Engineers, under deadline pressure, would just bypass it with a `--no-verify` flag.

This reinforces that the tool's value is inverse to the rate of change of your source material. For static, archival knowledge, it's passable. For anything tied to active development, the maintenance overhead to keep the grounding reliable likely outweighs the marginal benefit over a simple, searchable wiki.

Your story about the pre-commit hook being scrapped is the entire cautionary tale in a nutshell. The enforcement mechanism becomes the first thing to go when velocity is threatened. We tried the same with a CI check that failed the build if doc structure was invalid. It lasted three weeks before the team revolted and we added an override label.

The decay is inevitable because you're asking for metadata perfection for a system that can't validate the actual content. Even with perfect structure, the document could be fundamentally wrong about a Terraform resource, and NotebookLM will confidently ground its answer in that wrongness. The tool doesn't care about truth, only about citation.

So you're right, it's only for static knowledge. But I'd push back slightly on the "searchable wiki" comparison. A wiki you can at least skim and sense the staleness. NotebookLM gives a single, authoritative-sounding answer that obscures the decay underneath. That's a different, and potentially more dangerous, kind of debt.

Run a small team on a tight AWS/Terraform stack? Forget NotebookLM for now. The cost surprises aren't in the subscription, they're in the hours you'll burn forcing doc format compliance only to get a polished library catalog nobody trusts for real firefights.

You asked about access control and grounded reliability. The access part is trivial. The reliability part is a trap. It gives you high-confidence citations from documents that are almost certainly outdated the moment you push a module update. For runbooks, that's dangerous.

You're better off investing in a dead-simple, searchable wiki and a culture that updates it. The AI part is a shiny distraction from the actual problem, which is documentation discipline. The tool becoming a graveyard is the *best* case scenario. The worse one is it becoming a source of confident, outdated answers that break things.

>It only works if your documentation is already perfect and static.

That's the entire crux of it. The tool is a forcing function for documentation hygiene, but that's also its fatal flaw for a team our size. Polishing static docs while things are on fire is a luxury we don't have on night shift.

We saw the same graveyard pattern. The wiki was outdated, so we spent cycles cleaning it up for NotebookLM. Then a critical terraform provider version changed, the doc fell out of sync again within a week, and the AI started serving confidently wrong answers. Now we had *two* graveyards to maintain.

The discipline it forces is valuable, but the cost of that discipline has to be lower than the value of the answers. For a 10-person team in active development, that balance never tipped for us.

So you're basically versioning your docs like code? That's clever, but sounds like a lot of overhead.

The step ordering risk is scary. If it can't understand dependencies between steps, that makes it useless for actual troubleshooting, right? You'd just get a random list of actions.

Is there any tool that *can* model that dependency graph, or are we all just stuck with wikis?

The nervousness about posting is completely understandable, but you've actually pinpointed the exact tension that makes this tool so tricky to evaluate. You're hoping it will cut down on repeat questions, which assumes the answers are static and reliable. The reality, as the thread has explored, is that your documentation is almost certainly not static.

You asked for a simple example of how to structure a source document. Many have tried imposing strict templates, like separating "Inputs" and "Outputs" with clear headers. The problem is that this structure becomes a source of truth itself, and any deviation or addition by a team member breaks the tool's ability to parse it correctly. The moment you have a PR that adds a "Known Issues" section after "Inputs," your grounded answers become less reliable.

The real cost surprise isn't the subscription fee; it's the institutional effort required to maintain that document structure as a formal API. For a team of ten in active development, that's often a heavier lift than just improving your wiki and search habits. The graveyard risk is high because when the doc drifts, trust in the tool evaporates faster than trust in a stale wiki page, since the AI presents outdated information with such confidence.