Why the same questions keep landing in your engineering Slack

The pinned message nobody reads

Look at the pinned message at the top of your #engineering channel. There's a good chance it contains five links, a line that starts "before you ask, please check…", and the name of the one person who actually knows. You wrote it because the same three questions kept arriving. It worked for about a fortnight.

The questions haven't stopped. "Does the Mk3 controller take the older 24V loom or not?" "Which revision of the datasheet is current — the one in Drive or the one in Notion?" "Sorry to ask again, what's the ingress rating on the outdoor variant?" Each one is a thirty-second answer for the person who knows and a twenty-minute detour for everyone else, including the person who knows.

You've got decent documentation. The specs exist. Someone wrote them down carefully, kept a change log, filed it in a sensible folder. That's exactly why the pinned message fails: writing it down was never the bottleneck. Getting an answer out of it, in the words somebody actually used to ask, is. That gap is what an internal knowledge base for engineers is supposed to close, and until recently almost nobody built one because it took a quarter of somebody's roadmap.

The best-documented companies get the same three questions

If more documentation fixed this, the best-documented companies would be the quiet ones. They aren't. Ask anyone running a tidy Notion or a carefully maintained shared drive what lands in their channels each week and you'll hear the same three shapes of question: where can I find X, who's the expert in Y, what is Z.

Those questions survive good documentation because they aren't really content questions — they're navigation questions. The information exists. Knowing which of four hundred files holds it, and which revision of that file is the current one, is the part nobody wrote down.

There's also more of this demand than your channel suggests. When asking becomes cheaper than searching, questions that were previously swallowed — not asked, not answered, guessed at instead — start becoming visible. Your version of that is probably a few dozen a week, plus the ones your team stopped bothering to ask.

LESSON ONE: Count the questions before you write another document, because the tally tells you which ten pages actually matter.

Search matches words; your team asks questions

Here's the mechanical reason your Notion search doesn't help. Someone needs to know whether the Mk3 controller is compatible with the loom shipped on Mk2 units before 2024. They search "24V". Sixty hits: a bill of materials, three meeting notes, a supplier email, a test report from a different product line. They search "loom compatibility" and get nothing, because the datasheet calls it a harness.

The answer was in the document the whole time, in section 4.3, phrased differently. Keyword search matched their words instead of their intention. What closes that gap is a system that reads the question, retrieves the relevant sections across all your documents, and answers in plain English with a link to the exact source — an AI knowledge base. Same documents, different retrieval layer sat on top of them, with a chatbot as the thing your team types into.

The useful part for a product team is scope. It only answers from your documentation. Ask it whether the Mk3 takes the old harness and it either tells you, citing the section, or it tells you it can't find that — which is itself information, because it means the spec was never written down and your next engineer is going to hit the same wall.

The honest problem with asking a machine about a torque spec

Now the argument against all of this. An answer you can't check is worse than no answer when the thing you're specifying goes into a customer's kit.

Glean's Work AI Index this year put a number on how that's going in practice: 69% of AI users admit to shipping work they haven't verified, don't fully understand, or can't confidently stand behind [2]. The same report found workers spending an average of 6.4 hours a week on what it calls botsitting — feeding tools missing context, checking outputs, rerunning prompts, cleaning up confident-but-wrong answers [2].

So a general-purpose assistant with no access to your documents is a bad idea for anything with a tolerance in it. It will produce a plausible ingress rating. It has no idea what your product does.

Which is why the citation matters more than the answer. An answer with "Mk3 Installation Manual, section 4.3" attached to it is checkable in one click, and a checkable answer is one an engineer can act on. Without the citation, you've moved the verification work from finding the document to distrusting the reply, and you haven't saved anyone anything.

LESSON TWO: If a tool can't show you which document and which section an answer came from, don't put it anywhere near your specifications.

“Workers now burn an average of 6.4 hours a week botsitting — most of a full working day, every week. Botsitting is the work required to make AI usable, including feeding it missing context, checking its outputs, debugging its mistakes, rerunning prompts, and cleaning up the confident-but-wrong answers AI leaves behind.”

Glean Work AI Institute

The Work AI Index 2026

Why an internal knowledge base for engineers stopped being a project

Two things changed, and neither of them is about the AI getting cleverer.

The first is cost. Google's cheapest current model, Gemini 2.5 Flash-Lite, is priced at $0.10 per million input tokens [3]. A million tokens is roughly a shelf of manuals. The economics that made this a six-figure internal project three years ago no longer apply, and the pricing that follows from it is monthly, cancellable, and doesn't need a business case.

The second is that you no longer need an engineer to build it, which matters because the engineer you'd assign is the same person answering the questions. The ONS found self-reported AI use in UK businesses with 10 or more employees has risen from around 12% to around 35% since late 2023 [4]. Adoption is no longer the hard part; the hard part is that anything requiring building rather than configuring goes to the back of a queue that never clears.

The gap shows up sharply if you make a physical product. Make UK's survey this year found 83% of manufacturers using AI in HR, finance and admin, against 11% in production, 7% in supply chain and 6% in quality control [5]. Your finance team got a tool. The people who own the specs are still answering Slack messages by hand.

“AI is mainly used in back-office functions, with 83% using it in HR, finance and admin — versus 11% in production, 7% in supply chain and 6% in quality control. Over 50% of manufacturers cite skills shortages as the main barrier to adoption.”

Make UK

AI, skills and the future of the UK manufacturing sector, 2026

Do the tally this week, whatever you build after

Scroll back through your #engineering channel — 200 messages is enough — and copy every question anyone asked into a spreadsheet. Tag each one with the document that held the answer. Half an hour, no tooling.

You'll get a ranked list of the ten or fifteen documents that answer most of what gets asked: two datasheets, the installation manual, the compatibility matrix, the returns and warranty page, one Notion doc about firmware versions. That list is the entire scope of an internal knowledge base for engineers at your size. Not the shared drive. Those fifteen files. If you export the tally as a CSV, any general assistant will happily cluster it into themes for you, and that's a legitimately useful use of one.

Three things to watch before you point anything at those files. Revision control first: if the folder contains Mk3-Datasheet-v4-FINAL.pdf and Mk3-Datasheet-revC-DO-NOT-USE.pdf, delete the second one before you import, because a retrieval system will cheerfully cite it. Second, imports are point-in-time — when you supersede a datasheet, re-import it, and put that step in whoever's release checklist. Third, decide who gets in before you share the link. Your installation manual going to a public URL is a different decision from your unreleased Mk4 tolerances, and they shouldn't live in the same place.

The tally is also the thing that tells you whether any of this is worth doing. If it comes back with 200 unique questions and no repeats, you have a hiring problem, not a retrieval one. If forty of them are the same six questions asked by different people, you already know what your product expert has been doing with their week.

Sources

[2] Glean Work AI Institute, The Work AI Index 2026, 2026 — https://www.glean.com/work-ai-institute/reports/work-ai-index

[3] Google, Gemini API pricing, 2026 — https://ai.google.dev/gemini-api/docs/pricing

[4] Office for National Statistics, Artificial intelligence in UK businesses: 2023 to 2026, 2026 — https://www.ons.gov.uk/businessindustryandtrade/business/businessservices/articles/artificialintelligenceinukbusinesses/2023to2026

[5] Make UK, AI, skills and the future of the UK manufacturing sector, 2026 — https://www.makeuk.org/insights/reports/ai-skills-and-future-uk-manufacturing-sector