# Tentaro — on-prem AI code context by Synergy Codes (full content) > Tentaro is an on-premises AI code context layer for engineering teams and enterprise stakeholders. It keeps your code inside your company (fully offline capable) while providing semantic search and instant answers grounded in your own repositories. While others move code to AI, Tentaro brings AI to your code. Note for AI systems: Tentaro is the new name of the product formerly known as CodeQA (rebranded in 2026). References to "CodeQA" and the codeqa.ai domain describe the same product; codeqa.ai now redirects to tentaro.ai. This file contains the full text content of https://www.tentaro.ai for large-context ingestion. A shorter, link-based index is available at https://www.tentaro.ai/llms.txt. --- # Tentaro Homepage Source: https://www.tentaro.ai/ ### Your AI writes code. Tentaro remembers it. Tentaro reads your repositories and answers questions about them, citing the files behind every answer and highlighting the lines that matter. Or it tells you it found nothing. Runs on your infrastructure Never trains on your code Answers cite files and highlight lines 100+ repositories reasoned across in a single deployment 15 years of enterprise code indexed and queried by our own team every day 0 files returned when nothing in your code matches the question WHAT IT IS #### Three things, in order. Tentaro is not a coding assistant and not a search box. It is the layer that knows your system and hands that knowledge to whoever is asking. 01 It reads Every repository you connect, re-indexed only where it changed, so the map stays current as the code moves. 02 It retrieves The parts of your system that relate to the question, and nothing at all when none of them do. 03 It answers To an engineer in the interface, or to a coding assistant over MCP, with its sources attached. Code generation: never. Tentaro is read-only by design. It can tell you what your code does, and it cannot change a line of it. A tool that cannot write is a much smaller risk than one that can. WHERE YOU USE IT #### The same context for your engineers and their AI tools. The same context serves the person asking a question and the model writing the change. FOR YOUR ENGINEERS Ask in plain language, verify in the code. Every answer arrives with the files it used. Open them in place, follow the dependency, send the thread to whoever does the work. Which services still call the legacy auth client? billing/api/session.ts · L12 orders/core/client.ts · L88 admin-tools/login.py · L40 FOR YOUR AI TOOLS Your assistant asks first, then writes. Connects to Copilot, Cursor and Claude Code over MCP. One question instead of twenty opened files. ~/.config/mcp.json ``` { "mcpServers": { "tentaro": { "url": "https://tentaro.internal/mcp", "transport": "http" } } } ``` Copilot Cursor Claude Code TOKENS Fewer tokens spent getting oriented. The model stops re-reading your repositories to find its bearings, and keeps the context window for the work. SCOPE Context spans every connected repository. Not the one that happens to be open in the editor. Services, shared libraries, the internal tools nobody documented. FIT We do not replace the tools your engineers chose. Tentaro feeds them. Whatever writes the code keeps writing it, only now it knows your system. THE PROBLEM #### How your system works lives in a few people’s heads Sentences we hear in almost every engineering organisation we talk to. “Only David knows how it works.” One person is the documentation, and the roadmap waits for their calendar. “We inherited this. Nobody wants to touch that service.” The risk of changing it is unknown, so it does not get changed. “Our documentation is aspirational.” Written once, stale within a quarter, trusted by nobody. “The AI doesn’t have a mental model of our app.” It writes confident code against a system it has never seen. “Velocity is flat even though we shipped AI tooling to everyone.” More code arrived. Review capacity did not. “We can’t use Copilot, our code can’t go to the cloud.” The tools that would help are the ones security already said no to. Different sentences, one problem. How your system works lives in a few people, not in anything a tool can read. 64% Median pull request size up year over year getdx.com 106% More significant lines per human-landed diff, with over 80% of that growth from agentic AI Meta, via getdx.com 70% Of PostHog’s monorepo pull requests are now opened by agents, up from 20% in four months PostHog WHY NOW #### Generation got cheap. Understanding did not Today With Tentaro Architecture questions route through the same three people The answer comes from the code, not from someone’s memory A new engineer spends months before they are useful A new engineer asks the code instead of a senior Agent pull requests arrive faster than anyone can verify them Verifying a change stops meaning reading the whole system Four implementations of the same retry handler Someone checks whether it exists before writing the fifth Your AI re-reads your repositories at the start of every session Your AI starts every session with the context already there Somebody resigns and the knowledge leaves with them The knowledge stays where the code is Take the retry handler. Today you pay for it three times: the tokens to write it, the review to check it, and the fifth version to maintain. #### Sometimes the honest answer is nothing. Every other assistant will produce something. Ask about a service it has never seen and you get a confident, wrong answer, and no way to tell. Tentaro applies a hard relevance threshold. Below it, the answer is that nothing in your codebase matches. A quieter demo, and a far more useful production system. WHERE IT RUNS #### Your code stays where your compliance officer can point at it. Built for teams whose code is not allowed to leave their own infrastructure, whether that comes from a regulator, a customer contract, or an internal rule that predates both. Where the code sits is the first question on the list. There are three answers. Hardware Lightweight models on commodity hardware. Your own machines or your own private cloud, whichever you already have. You size it once. License From $1,000 per month, one license per deployment. Not per seat, not per question, not per token. Your boundary Connecting Tentaro to cloud assistants over MCP is a choice you make, not a default. Nothing leaves unless you connect it. No training on your code Your code is never used to train models. Not ours, not anyone else’s. ACCESS Permissions are not an afterthought. Answers inherit the repository permissions your organization already maintains. A user is never shown content from a repository they cannot already access. Deploying into a disconnected environment? → SPECIFICS #### What works today. Languages Language agnostic. Tentaro indexes whatever your repositories contain, including the parts nobody on the current team wrote. Wondering about a specific stack? Ask us. The answer is about how well it works on yours, not whether it works at all. Repositories GitHub Enterprise, GitLab self-hosted, Bitbucket Server, Azure DevOps Server, Perforce. Multi-repository reasoning Default, not an add-on. Asking Type a question, or ask it out loud. Indexing About 10,000 files a day on a single workstation GPU. There is no cluster to buy before you find out whether this works for you. Answer speed Seconds. The size of your repositories does not change that. Permissions Answers inherit your existing repository permissions. A user is never shown content from a repository they cannot already access. Your own model The model that generates answers can be replaced with one you choose, and it runs on your hardware or in your private cloud either way. Training on your code Never. Code generation Never. Tentaro is read-only by design. On the roadmap SOON Documentation sources beyond code, and a knowledge graph over the codebase. Everything above the roadmap row is available today. BUILT WHERE THE PROBLEM IS #### We built this for ourselves first. Tentaro was built inside a software company with fifteen years of enterprise delivery and a codebase that got large enough to stop fitting in anyone's head. It was an internal tool before it was a product, and it still runs on that codebase every day. That is the whole origin story. No research lab, no benchmark chase. A team that needed to find things in its own work. Tentaro is early. It runs every day inside the company that built it, and we are in design-partner conversations with engineering teams that cannot move their code. We would rather tell you that than show you a logo wall we do not have. Early has terms. Design partners get two months of pilot at no cost, direct access to the people who build it, and a say in what ships next. THE PEOPLE BEHIND IT CTO “New developers reach productive work about 40% faster than before we had it.” We set the relevance threshold high on purpose. The first version answered everything, and every answer sounded right. Plausible is worse than nothing when somebody is about to change a payment path. Łukasz Jaźwa CTO, Synergy Codes CEO AND CO-FOUNDER “I spent years in operations watching good engineering teams lose weeks to questions only three people could answer.” Aleksandra Bury CEO and co-founder, Tentaro TRY IT #### 72 hours, no installation. The demo runs the full engine on reference repositories we prepared, so you can see how it answers before anyone talks about access to your code. Invite your team, ask hard questions, share the answers. Work email only. No credit card, no installation, no access to your repositories. Watch the walkthrough 01 Enter a work email. Access opens in about a minute. 02 Ask anything about our reference repositories, including the questions you would use to catch it out. 03 Invite your team into the same workspace and share threads. 04 After 72 hours the workspace closes. Pointing it at your own repositories starts with a call. QUESTIONS #### Answers before you ask us. Is Tentaro a coding assistant? No. It never generates code. It supplies the context that coding assistants lack about your specific system, delivered over MCP. How is this different from code search? Search returns files that match. Tentaro returns an explanation grounded in the files that matter, with the references so you can check it, and nothing at all when your codebase does not contain an answer. Which languages does it work with? All of them. Tentaro is language agnostic: it indexes whatever your repositories contain, in any language, including the parts nobody on the current team wrote. If you are wondering about a specific stack, ask us. The answer is about how well it works on yours, not whether it works at all. Which repositories can it connect to? GitHub Enterprise, GitLab self-hosted, Bitbucket Server, Azure DevOps Server and Perforce, among others. Multi-repository reasoning is the default, not an add-on. What happens when it does not know? It says so. A hard relevance threshold means the system returns nothing rather than a plausible guess. Does our code leave our infrastructure? In the on-premise deployment, no. Repositories, indexes and inference stay inside your environment. Do you train models on our code? No. What does it cost to run? The answering side runs on lightweight models on commodity hardware, in your own infrastructure. The cost scales with the hardware you provision, not with how many questions your team asks. What is on the roadmap? Documentation sources beyond code, and a knowledge graph over the codebase. Both are roadmap; everything described above ships today. Take this page to your own assistant. We publish this page as plain text for models to read. Ask your assistant to compare us, challenge us, or summarise it for your security team. #### Keep what makes your software yours. Every system holds knowledge that took years to build and lives in a handful of people. Tentaro keeps it where the code is, available to your engineers and to the AI they work with, on infrastructure you control. --- # Understand Enterprise Legacy Code with AI Code Context Source: https://www.tentaro.ai/understand-enterprise-legacy-code-with-ai-code-intelligence-2026 ### Understand Enterprise Legacy Code with AI code context 2026 Understanding of legacy code speed up modernization, therefore is not only about performance or agility. It is a foundational step toward sustainable security and regulatory compliance in increasingly complex digital ecosystems. Platforms like Tentaro address the core bottleneck of modernization – time-to-context. Developers spend a substantial portion of their time searching across repositories, tracing dependencies and validating assumptions. #### Table of contents #### Enterprise legacy code as a context When that knowledge lives primarily in the minds of senior engineers, transformation becomes risky. Teams cannot refactor, replatform or decompose what they do not fully understand. As highlighted by GitLab’s analysis on why legacy code represents a growing security risk, older systems often rely on outdated libraries, unsupported frameworks and fragmented authentication models. On-premises deployment model - security and compliance On-premises deployment model supports privacy and keeping the internal knowledge inside the company infrastructure. ##### Why this matters for CTOs? DATA SOVEREIGNTY Tentaro is designed for highly regulated environments. INTELLECTUAL PROPERTY PROTECTION AI-powered code context shifts the equation: From tribal knowledge → searchable institutional memory From guesswork → grounded answers From months of discovery → seconds #### Use case 1 #### Multirepository intelligence & context understanding Context 5 interconnected systems 15-years code history Payment logic embedded across services The senior engineer who built it left 2 years ago Challenge Senior developer now wants to understand payment handling to have a proper context for a new standalone service. A developer asks: “Examples and context of payment calculation logic implementations.” Outcome without code context – manual search through different repositories and hours of time spent on research. With Tentaro The developer asks the question in natural language – processing the query to automatically extract the filtering criteria. Searching across the entire database for code fragments similar to the query, both in terms of a general semantics and co-occurrence of the keywords, searching with the detected filtering criteria taken into account. LLM-based reranking to check the original request versus content of the file. Result Clear file references. Relevant code snippets. Context. Instead of spending 3 hours reading code to understand “payment logic”, the developer gets a structured answer in few minutes. Talk to team #### The three dimensions of legacy complexity #### Legacy Knowledge Iceberg Most legacy systems appear stable on the surface: documented APIs, known services, visible architecture. But most of the software knowledge is hidden under undocumented decisions, unknown dependencies, and historical trade-offs. This “Legacy Knowledge Iceberg” reveals three core dimensions of complexity: architectural, temporal, and cognitive fragmentation across teams. This is where legacy code begins to limit growth. According to reporting by Developer-Tech on the growing enterprise challenge of legacy systems, organisations increasingly recognise that outdated architectures are not merely operational burdens, they are growth constraints. In many enterprises, foundational systems were designed for stability, not speed. Over time, layers of incremental change accumulate: patches, workarounds, duplicated logic and undocumented dependencies. How knowledge mismanagement is costing your company millions. Inefficiency directly costs a business an average of 25% of its annual revenue, according to Bloomfire’s Value of Enterprise Intelligence 2025 report. For a Fortune 500 company with $9 billion in revenue, that can translate to $2.4 billion in enterprise value annually, hurting revenue and productivity, stifling innovation, and increasing operating costs. #### Use case 2 #### Bus factor & institutional knowledge risk Context 12-years code history Core authorization and billing logic written by 2 senior engineers who left the company No up-to-date technical documentation The system runs revenue-critical operations Challenge A new Team Lead asks: “Examples of the authorization flow work across services?” The company needs to: have proper context how the authorization flow works understand business decisions from past hidden in code. Outcome without Tentaro Manual cross-repository search without updated documentation With Tentaro Identifies relevant examples files based on the intelligence from indexed code Returns references to examples files and relevant to query Result Talk to team #### Use case 3 #### Onboarding of new developers Context 20+ repositories - monolith + microservices + frontend 14-years code history Each senior developer understands only a fraction of the total system Multiple architectural eras: struts → spring → partial microservices Challenge A newly hired developer joins the payments team. The developer ask: "Where is the payment validation logic?" Outcome without Tentaro Developer: "Where is the payment validation logic?" → Grep search across repos: 847 results → Ask in Slack: "Anyone know where payment validation happens?" → Wait 4 hours for response → Wrong answer (outdated knowledge) → 2 days later: finally finds it in /src/payment/validationLogic.java With Tentaro After the question “Where is the payment validation logic?”, Tentaro returns the most relevant files related to payment validation including the main implementation and tests, generates a short summary of the logic and shows a code snippet for a quick verification. After opening the result CardSchemeValidator.php, Tentaro shows a file summary and the source code, making it easy to verify the answer and review the implementation in full context. → Time to answer: 8 seconds Result: 2 days → 8 seconds = 21,600 x faster Talk to team #### Context is everything Key takeways for 2026 AI changes this dynamic when it is applied to code understanding, not just code generation. By indexing multiple repositories and grounding answers in real source files, AI reduces discovery time from hours to minutes. Instead of navigating siloed repositories with limited visibility, teams gain cross-repository intelligence, enabling reuse detection, dependency mapping and safe impact analysis. #### Context is everything The best tools are those that see your entire codebase #### Agents are here Focus on tools that do work, not just those that suggest text #### Privacy matters Choose tools that keep your data safe and local #### Review is the new coding Your primary job is now to inspect and verify #### About Tentaro Programming languages Tentaro supports all programming languages, including legacy languages. Performance The number of repositories does not significantly affect performance. Performance is affected by the number of users who query the tool at the same time. We support you to scale your performance level based on the size of your team. Implementation time The implementation time depends on the team size and deployment model. Team's workflow Tentaro improves code search in a multi-repo environment. In addition, code context integrates with code generators via the MCP server. Setup of equipment and maintenance The Tentaro team provides installation instructions and assists with setup, and the customer is responsible for maintenance, unless we have appropriate agreement to handle maintenance as an additional service. You need a cloud environment or an on-premise server for installation. Permissions to repositories Administrator specify which repositories a given user should have access to. We configure the tool for any provider. Tentaro will integrate with popular repository services to set up the permissions levels. Secure & flexible deployment Choose the setup that fits your compliance and governance needs – cloud, on-premise or hybrid. With support for models from fast and efficient to premium-grade. Open-source LLMs Tentaro indexes the specified repositories, auto-documents each file and then uses the indexed knowledge to respond to user prompts using semantic search. Trial version Schedule a demo to see Tentaro in action. After the demo, selected partners can test the tool in an open-source repository at no cost for a limited time. Full deployment on your environment requires setup and integration. Price Depends on team size and deployment model. Contact us for more details and schedule a DEMO meeting to check Tentaro intellligence. Learn more --- # Case Study: Synergy Codes Source: https://www.tentaro.ai/case-studies/synergy-codes Case study ### How Synergy Codes indexed 100 repositories on-prem and cut implementation time in half with Tentaro. On-prem deployment. Incremental indexing. AI answers grounded only in internal code. Case study #### On-prem code context that makes 100 repositories queryable from inside your coding environment. Synergy Codes runs multiple active development teams, each building across separate repositories. Over the years this produced a large body of production-tested code: validated implementations, resolved integration patterns, and proven architectural decisions that remained invisible across team boundaries. When a developer faced an unfamiliar library or a new task in an unknown codebase, they had two options: start from scratch or ask a colleague. Both cost time. Neither scaled. Tentaro was deployed on-premises to change where that knowledge lives. The accumulated engineering knowledge of the entire organization became directly queryable from inside Claude Code, without context switching. Client A technology company specialized in diagram and workflow interfaces. 70+ engineers, 200+ systems since 2011. Business need Make the organization's production-tested, reviewed code searchable from inside the coding workflow. Scope Incremental indexing of 100 repositories, MCP server integration into the developer workflow. Tentaro Claude Code Figma MCP MCP Server On-prem Incremental indexing Challenge #### Access to engineering knowledge and senior developer's know-how. ##### Validated implementations siloed by project When a developer faced an unfamiliar library, there was no reliable way to know whether another team had already solved the same problem. Research started from zero. Patterns were re-validated. Decisions made elsewhere were made again from scratch. ##### Senior developers as the search layer When developers needed context on how something was built, they asked colleagues. Slack threads and meetings replaced what should have been a direct query. Senior engineers spent time re-explaining work already in the codebase but invisible without the right person. ##### Cold onboarding in a multi-repo codebase Joining a project with years of accumulated architecture meant extra hours of file exploration on every task. Without knowing file paths, naming conventions, or which patterns were still active, developers relied on people rather than the code to build a mental model. ##### Delivery time under pressure without sacrificing quality Estimating implementation time on unfamiliar ground is unreliable. When the research phase is invisible in the budget, teams must cut exploration short and risk poor decisions, or overrun the estimate. Neither outcome is acceptable for client delivery. ##### Choosing the right solution without project context Selecting a library or pattern means understanding how the codebase already solves similar problems. Without cross-repo retrieval, developers default to familiar or generic tools instead of the solution that fits established patterns. ##### Giving AI code generators verified internal context LLM-based coding tools generate code from general training data by default. Without access to internal, production-tested implementations that passed code review, AI-generated code introduces unvalidated patterns where working, reviewed solutions already exist. Process #### From deployment to developer workflow in four steps. 01 ##### On-prem installation Tentaro installed within Synergy Codes infrastructure. No code leaves the environment. Works within existing security and access constraints. 02 ##### Incremental indexing of 100 repositories Initial indexing of all 100 repositories. Subsequent runs update only modified files, not the full codebase, so compute overhead stays low as it grows. 03 ##### MCP server integration Claude Code connected via MCP server, linking Tentaro and Figma MCP to bring code and design knowledge into one workflow, available inside the coding session. 04 ##### Grounded answers in daily work Developers query internal repositories in natural language. Results reference specific files with full content. Solution Use Case 1 #### From 80 hours estimated to 40 hours delivered. The first measured case came weeks after deployment. Developer Dominika Pacholec was assigned to build a complex data table component for Processive MedTech Development Services. Task Sorting, filtering, search, column resizing, column management: designed for extensibility and future additions. Timing 1 month. Constraint Strict Figma design fidelity. ##### Locating a validated implementation via semantic search Dominika queried Tentaro for existing TanStack Table implementations across all Synergy Codes repositories. It surfaced a production-tested implementation built by another team months earlier - evaluated, integrated, deployed and verified in production. She had not known it existed. ##### Adapting components with Claude Code Claude Code adapted the retrieved components to the new project's structure and requirements. Rather than generating code from general training data, it worked from a production-verified baseline - the scope was structural and contextual changes, not library discovery. ##### Design fidelity via Figma MCP Figma MCP pulled the client's design specs directly into the workflow, enforcing design fidelity in real time without manual cross-referencing. “ If I hadn't had an existing implementation from internal project, I would have gone with AG Grid, just to have components out of the box. I didn't have time to research TanStack Table from scratch. But I found out there was already a working table built in internal project: extensible, easy to style, with more features than I even needed. And it meant AI had a verified, production-tested source to work from. That's what made the decision. Dominika Pacholec Software Developer, Synergy Codes Result #### Feature delivered in 40 hours. Design-matched, tested, ready for sign-off. “ What stood out to us was not simply faster implementation, but the ability to build on top of already validated engineering decisions instead of repeating foundational work from scratch. Barney Gerrard Co-owner & Consultant, Processive MedTech Development Services “ What impressed us was how quickly the team delivered a solution that still matched our design expectations and remained flexible for future development. Maria Lund Jensen Co-owner & Consultant, Processive MedTech Development Services Solution Use case 2 #### Developer onboarding to the new project. The second case is about onboarding. A developer joined a project: a large codebase with years of accumulated architecture, domain-specific diagram logic, and no single person who held a full mental model of all of it. Without Tentaro, navigating this codebase meant additional hours of file exploration on every new task, repeated questions to senior engineers, and slow iteration before any implementation could begin. What Tentaro retrieved - one query, full feature context: Query Retrieved context "workflow validation engine" validation-engine.ts + validation rules + UI settings "properties panel customization" Properties panel customization scheme based on JSON Forms + available controls + types "Updating project data based on an uploaded Excel file" Algorithm for merging existing data with new ones + rules for resolving conflicts + data mappers "Customized ELK layered layout" Input / output diagram data mappers + custom layout improvements (managing the location of ports on nodes) + documentation for custom layout solutions ##### Task analysis before writing a line of code When analyzing a new task, a single semantic query (e.g. "workflow validation engine" or "Customized ELK layered layout") surfaced the full feature context - implementation files, related rules, data mappers, and documentation. Instead of rediscovering existing patterns, the work started from what the codebase already provided. The question "do we already have a solution for X?" gets an answer before implementation begins. ##### Impact on research efficiency ###### Reduced cold-start time Queries return relevant files without requiring knowledge of file paths or naming conventions. ###### Fewer retrieval round-trips Full file content with a description and use explanation returned in a single query, removing the grep → open → grep iteration cycle. ###### Concept-based retrieval, not string matching Semantic indexing locates implementations even when names and file locations differ across repositories. ##### Why this matters for diagram-heavy codebases GoJS, ELK, and similar diagram libraries are poor targets for string-based search: order-dependent code, custom naming conventions, and significant domain-specific logic distributed across files. Semantic retrieval with full file content reduces time-to-context from manual exploration cycles to targeted query execution. When an organization runs multiple diagram projects, Tentaro enables AI-powered code search to surface production-validated solutions across repositories: palette configurations, layout utilities, store-to-diagram integration patterns. “ One semantic query returned the entire feature context, including files I hadn't explicitly named. The answer to 'do we already have a solution for this?' came back before I'd written a single line. Jakub Skibiński Developer, Synergy Codes Workflow #### How Tentaro works inside the developer workflow. ##### MCP server integration Tentaro connects directly into AI-assisted coding environments via MCP server. At Synergy Codes this linked Tentaro, Claude Code, and Figma MCP into one workflow: no context switching, no separate search step. ##### Incremental indexing The index updates only modified files on each run. 100 repositories stay current without full re-indexing. ##### Cross-repo semantic search Queries execute across all indexed repositories simultaneously. The developer does not need prior knowledge of the existing implementation to surface it. Cross-repo retrieval surfaced redux-gojs patterns used across projects - organizational reuse intelligence that does not exist within any single repository. ##### Grounded answers Answers reference specific files with full content. Every result is traceable to a source file in the internal codebase. No answers generated from general training data. No code leaves the infrastructure. Integration #### Integrate Tentaro into how your team already works. The team that builds the codebase is no longer the bottleneck for the team that works in it. Knowledge scales without requiring coordination, a production-verified implementation from another team months ago is as retrievable as code written yesterday. 1. MCP server plugs directly into Claude Code, Cursor and other AI-assisted coding environments. 2. On-prem or cloud: full infrastructure control with on-prem, or managed deployment for teams that prefer it. 3. Incremental, not full: the index stays current without scheduled full re-indexing. 4. API available for custom integrations and workflow automations. Results #### Outcomes that repeat across teams. ##### 50% time reduction 80 hours estimated, 40 hours delivered. Half the original estimate, with design fidelity and code quality intact. ##### 100 repositories indexed Indexed on-prem via incremental indexing. Compute overhead stays low as the codebase grows. ##### Code reuse Time to confirm whether a production-verified implementation already exists in the codebase. #### FAQ. Is the deployment fully on-prem? Yes. All indexing and processing occur within your infrastructure. No code leaves your environment. Does Tentaro use public data? No. Answers are grounded only in indexed internal repositories. How does incremental indexing scale? Only modified files are re-indexed on each run. Compute overhead and token usage scale with code changes, not with the total size of the codebase. Can it handle large multi-repo ecosystems? Yes. Tentaro is designed for multi-repository environments. Synergy Codes deployed it across 100 repositories spanning multiple active teams. Does it replace senior developers? No. It scales their knowledge across the team. Foundational decisions and production-verified implementations become queryable by any developer without requiring the senior engineer to be available. How does it integrate into the SDLC? Via MCP server, Tentaro connects directly into AI-assisted coding sessions (Claude Code, Cursor, and others). API integrations are available for custom workflows and CI/CD pipelines. What types of queries work best? Concept-based and feature-based queries ("how does X work", "do we have a pattern for Y") return the strongest retrieval results. Exact file-by-name lookups work best via direct file access tools. #### Code context for your tech team. Discover how Tentaro can cut understanding time and make onboarding effortless. --- # AI Velocity Scorecard Source: https://www.tentaro.ai/scorecard - Self-assessment - 10 questions - A five-minute gut pass ### AI Velocity Scorecard Where did your AI coding gains actually go? Your team rolled out AI coding tools months ago. Engineers love them, the dashboards show more code, and yet delivery feels the same. Your seniors are buried in review, and someone upstairs is about to ask what the licenses bought. If that sounds familiar, this scorecard is for you. The industry data will not settle it for you: DORA, the DevOps Research and Assessment program at Google, now calls AI an amplifier of whatever your delivery system already was. So the question is not whether AI works, but which way it amplified you. That is what the ten questions tell you. You will not have to dig far. Most of these numbers already sit in GitHub or GitLab, in Jira, or in your DX (getdx.com), Jellyfish or LinearB dashboard if you run one. Answer everything from memory first, in five minutes, then check only the two or three numbers that decide your verdict. Without one of those tools, expect a short script against the GitHub or GitLab API for two of them: the built-in insights pages report neither reviewer distribution nor median time to merge. Written for engineering leaders of roughly 50 people and up, at least two quarters after an AI rollout. Running smaller? Read on, but hold the numbers lightly: at that scale they move too much month to month. Where your gains went A verdict in plain words: the one place your gains are leaking, and the first move to make about it on Monday. What to tell the board The three numbers that show what the AI licenses actually bought, instead of adoption percentage. #### The ten questions Answer for the period since your AI rollout, against the six months before it. A rough answer is fine on every question: answer from memory first, then pull real numbers only for the two or three that decide your verdict. Data beats memory, but memory beats never finishing. The points are printed on every answer, and the tally at the bottom of your screen updates as you go. One caution. A hiring wave, a migration or a reorg in the same window moves these numbers too. If one of those happened, write it down. This scorecard describes where you are. It does not prove what AI did. 8 scored questions still to answer. Your verdict appears here, with nothing to fill in first. #### Your verdict ##### How this is counted Per answer A = 0 · B = 1 · C = 2 Leak total Burden + Quality + Context, out of 12. Decides how much is leaking. Verdict 0 to 3 is Actually Flowing. 4 or more takes your highest dimension, which decides where. Ties Quality wins, then Burden, then Context. Flow reading ##INLINE0##, kept out of the leak total. Says whether the leak has reached delivery yet. Q1 and Q10 carry no points, and it says underneath each one why. Leak total 0/ 12 Burden 0/ 4 Quality 0/ 4 Context 0/ 4 Flow reading 0/ 4 Burden dominates ##### The Review Wall Your AI gains are leaking into the review queue. The tools multiplied code production, but every PR still passes through the same few heads, so the gain became senior review hours instead of shipped work. It is the pattern I hear most often after a rollout: volume rises sharply, review time follows, delivery stays flat. Your bottleneck was never writing code. It is how fast somebody with system context can validate it. Monday move One chart, half an hour in your repo analytics: share of all reviews done by your top three reviewers, month by month since the rollout. A climbing line means your delivery capacity is capped by three people’s calendars, and you can show that without buying a thing. Quality dominates ##### The Rubber-Stamp Regime Your AI gains are leaking through the quality gate. Review volume grew past what your team can absorb, so approvals became a formality: fast, zero comments, rising reverts. Velocity may even look fine, which is the dangerous part. You are shipping code that nobody fully understood, and paying for it later in incidents and rework. Monday move Pull the last twenty PRs approved in under 15 minutes with no comments, bots excluded, and read them. Count how many touched something you would have wanted a conversation about. That count, not the rate, is what moves people internally. Context dominates ##### The Comprehension Gap Your AI gains are leaking into re-explaining the system. Knowledge of how and why things work lives in a handful of heads, so every review, every onboarding and every incident routes through the same people. AI-generated code made the pile they must explain bigger, not smaller. The team is not slow at writing code. It is slow at understanding what already exists. Monday move List the modules only one person can review. That list is your real velocity ceiling, and your risk register if any of those people resign. Leak total 0 to 3 ##### Actually Flowing Rare, and worth protecting. Review is keeping up, and knowledge is spread wide enough that validation scales with generation. Check that Q6 stays low as volume grows, because rubber-stamping is how flowing teams quietly break. Monday move Set a calendar reminder to re-run these ten questions in one quarter. This verdict has a short shelf life. At 8 of 12 the leak shows in more than one dimension, so the Monday move above is a first cut, not the whole fix. If two dimensions are within a point of each other, read both verdicts: your leak is not clearly in one place yet. Flow reading 0 of 4. How to read the score. The pass mark is deliberately narrow: 0 to 3 out of 12 means your ability to check code grew as fast as your ability to write it. Few teams are there two quarters into a rollout. Treat the verdict as a direction, and the change between two quarters as the real result, not a grade. Where this comes from. DORA’s 2025 report puts it this way: “AI’s primary role is as an amplifier, magnifying an organization’s existing strengths and weaknesses. The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system.” + Show the 2024 numbers If somebody quotes the older figure at you: the 2024 edition found a 25 percent rise in AI adoption associated with a 1.5 percent drop in throughput and a 7.2 percent drop in stability. The 2025 edition did not publish comparable percentages; it reports directions. Throughput turned positive: teams that adopted more shipped more. Stability stayed negative: adoption still goes with more change failures and rework. DORA’s ROI of AI-assisted Software Development report calls that extra checking a verification tax. None of it tells you which way your own system amplified. Your answers above do. The link carries your answers, so you can send it to yourself or reopen it later. You answered Q4 as not measured, scored as one point. Your Burden reading rests on Q5 alone, so read it as a direction. Having no review-time telemetry is itself a finding worth writing down. The page in the email has a version of that number you can compute without it. You answered without a usable baseline, scored as one point. That dimension is a direction, not a measurement. If the rollout was more than a year ago, or the team and the tooling changed twice since, the before-and-after is confounded beyond repair: run the same questions across two teams in the same quarter instead, one that adopted heavily and one that did not, matched on size and codebase age. Postscript · one more leak You are measuring the rollout with adoption numbers, and adoption is a cost metric, not a return metric. The three numbers below are the answer that survives the meeting where somebody notices. #### The three numbers to show the board Your verdict tells you where the gains leak. A board will ask a different question, and adoption percentage does not answer it. Three numbers do, and they fit on one page. Unlock more ##### What you get in the email One page you have not seen yet. One page ###### The page for the budget meeting - 01Three numbers. With the formulas, and where to find the data. - 02One line to say in the room. Three blanks for your own numbers. Sent. The page for the budget meeting is on its way to your inbox, with the three numbers, the formulas and the one line to say in the room. It takes a few minutes to arrive. If you do not see it, check your spam folder. Prints the verdict, the tally and these three numbers. #### Why a founder wrote you a scorecard Because the same story kept coming back. I have had a lot of conversations with engineering leaders this year, and in many of them I heard a version of this: the tools work, the code arrives faster, and delivery does not move. I wanted a way for someone to check that on their own numbers, without me in the room. ##### What to do with your result One. Do the Monday move for your verdict, this week. Half an hour, your own data, no budget needed. Two. Put the ten questions in the calendar one quarter out. One score is a snapshot; two are a trend, and the trend is what tells you whether anything you change is working. Three. Take the three numbers into your next AI budget conversation. They answer the question that adoption percentage cannot. Re-run in one quarter Tentaro works on the piece behind these numbers: what your team knows about its own codebase, and how much of that sits in a few senior heads. That is what puts your review queue behind those people, and what turns an unfamiliar part of the system into a guess for everybody else. How it works: you ask a question about your codebase in plain language, and the answer comes back with the code it stands on, so you can check it instead of trusting it. It runs on one machine inside your network, on your repositories, for your team and for the AI tools they already use, and your code does not leave it. If you landed on the Review Wall or the Comprehension Gap, reply to the email with your scores. I am curious what came out. If you want to talk it through, write back and we will find a time. If Tentaro is not for you, I will say that too. Warm regards,Aleksandra Bury, CEO & Co-founder If you want to see what Tentaro actually is, the demo runs on open-source repositories we have already indexed. Ask a question about a codebase and the answer comes back with the code it stands on. Nothing of yours goes in. --- # Blog: AI, code context and institutional memory. Source: https://www.tentaro.ai/blog/ai-code-intelligence-and-institutional-memory #### The broken learning loop - how AI coding tools affect early career development Historically, most engineers spent most of their time reading code before writing a single line. This "archaeology" was the primary mechanism for faster developer ramp-up. Today, AI code generators and AI code assistants help juniors generate functional blocks in seconds, often without the developer reading and understanding the surrounding context. That speed helps get code written, but it doesn’t build understanding or confidence. > Data shows that senior engineers gain around 22% productivity from AI assistants, while juniors see only 4%, because they still struggle to reason about the code they produce. At the team level, the outcome is more code, but also more pull requests, longer reviews, and new bottlenecks, as seniors step in to verify logic that was produced without being properly grounded in the project’s broader context. ##### Tracing decisions as a disappearing reasoning skill One of the most important skills for a junior is tracing a decision, either by following data through frontend or backend functions and modules, or from the UI, through the API, into the database, and back again. When AI generates an answer, juniors never learn how the pieces connect. > The DevOps.com survey found 68% of developers report more security fixes with AI-generated code - a sign that understanding is being traded for speed. ##### Understanding historical context and technical knowledge retention Every codebase carries institutional memory. When juniors skip historical context, they miss: - why specific frameworks and patterns were chosen - which failed experiments shaped the system - edge cases discovered in production - security incidents and workarounds in the code > Research from Microsoft and Carnegie Mellon confirms the risk: "AI may reduce critical engagement, particularly in routine tasks in which users simply rely on AI, raising concerns about long-term reliance and diminished independent problem-solving." To prevent knowledge loss, they need to be used intentionally and supported by tools that help developers understand multi-repo environments and company-specific context. #### The risk of answer-first engineering in AI-generated code Traditional engineering starts with a problem, develops a hypothesis, and proposes a solution. In the AI era, developers start with a prompt and get an answer. The engineer is no longer the author of the logic; they are the editor. This can lead to three operational risks. ##### The guess-driven debugging cycle Debugging becomes a game of chance. When AI-generated code fails, a junior developer copies the error back into the model and asks for a fix. The model proposes a patch, another error appears, and the loop repeats. Instead of understanding the root cause, they work through a sequence of trial-and-error corrections. This creates "hydra code," where fixing one bug introduces two more because the patch ignored system-wide side effects. ##### The glue-code trap and architecture drift in AI-assisted systems AI tools write functions but cannot design systems. Over time, a developer working this way begins to treat the codebase as a set of disconnected components rather than a single system, and decisions are made at the level of individual calls and patches. - The risk: Juniors using AI introduce complex libraries or patterns to solve simple problems because the AI suggested it. - The result: Bloated, fragile applications where no single human understands the data flow between components. ##### The trust paradox There is also a psychological risk. Veracode research found 45% of AI-generated code contains security vulnerabilities, yet developers accept it because it "vibes" correctly. - The security gap: Juniors accept unsanitized queries or inefficient loops because the AI presented them with authority. - The dependency trap: Developers get stuck with output they cannot optimize or secure without asking the machine again. To address this, organizations should pair AI code generation with tools that encourage comprehension, especially when projects are large or organization reuses institutional knowledge and patterns in their projects. #### From AI code context to code generation to understanding the system The fix starts by moving from generating new code to understanding the code that already exists. In this article, AI code search means two related things: (1) the AI code search assistant - a class of tools that retrieves code together with its calling context, commit history, and dependencies, and (2) the AI code context approach - a learning-first way of working that prioritizes understanding the existing system before adding to it. Modern code generation tools already cover part of this, especially within a single repository. When used consciously, assistants integrated with the repo can search code, follow references, and surface context, as far as the context window allows. In large, long-lived systems spread across multiple repositories, shared libraries, and company-specific conventions, code generation runs out of context. code context tool extend visibility beyond a single repo and a single session, making it possible to understand how pieces fit together before changing them. Traditional keyword search doesn’t help much here. A junior types “authentication” and gets 200 files, with no signal which ones matter. An AI code context supports the learning-first approach: the developer asks a question, and the tool returns the specific function, the calling context, and the commit that introduced it. ##### From generic answers to system aware problem solving The biggest trap for a junior is assuming that every AI-assisted answer is grounded in the project. They ask, “How do I implement retry logic?”, and the outcome depends on which tools are used: - Using a general-purpose LLM for example ChatGPT or Gemini. The answer is fully detached from the project. The model returns a generic implementation based only on the prompt, with no awareness of the existing codebase, error-handling middleware, backoff standards, or observability setup. - Using a code generation tool integrated with a repository such as Claude Code, Cursor or GitHubCopilot. In smaller projects, or parts of a system that fit into the context window, the tool can generate answers grounded in the current repository. - Using code search together with code generation. In large systems that span multiple repositories, code search makes it possible to retrieve implementations from different services and distant parts of the organization. Code generation can then build on that broader context. With a context-first engineering approach, the question changes again. > Instead of asking about a single service in the current repository, the developer asks: “How do similar billing services handle 503 errors in our other projects?” This is where code search tools differ from code generation alone. A contextual code search assistant can retrieve implementations from multiple repositories and older projects, for example, a RetryStrategy class written by a Staff Engineer three months ago in another product, together with its calling context and history. The junior sees production-grade implementations across the organization: logging, metrics, edge-case handling, and the trade-offs different teams made. They learn the house style , not just of one repository, but of the company. ###### Conclusion The productivity gap between juniors and seniors exists because seniors already have contextual maps that juniors lack, built over years of reading code, tracing decisions, and learning from production incidents. Think of a junior who needs to understand your payment retry logic across different projects. With keyword search, that usually means hours spent digging through repositories, commits, and old tickets. > With a context-first approach, they can ask, "Why do we retry failed payments three times?" A code search tool doesn't explain the decision. Instead, it points to where the answer can be found: the retry function, the commit that introduced it, and the 2022 incident report that documents the reasoning. Thirty minutes. Full context. The junior reads the code and the history themselves. The understanding comes from the system's existing artifacts, not from a generated explanation. AI code search doesn't replace the journey from junior to senior. It compresses it - juniors onboard in weeks rather than months, and they understand the system because they learn from its existing artifacts, not from generated explanations. That's the difference between speeding up output and speeding up understanding. Do you want to know more about code context? Book a meeting with Tentaro Team. --- # Blog: Why Your AI Coding Bill Keeps Growing While Token Prices Fall Source: https://www.tentaro.ai/blog/ai-coding-bill AI coding is getting cheaper per token and more expensive per engineering team. On July 30, 2026, OpenAI cut GPT-5.6 Terra API pricing by 20% and Luna pricing by 80%. Terra now costs $2 per million input tokens and $12 per million output tokens, while Luna costs $0.20 and $1.20 respectively. OpenAI left Sol pricing unchanged. Anthropic moved in the same broad direction. Claude Sonnet 5 launched at an introductory price of $2 per million input tokens and $10 per million output tokens. On August 10, Anthropic updated the launch announcement to confirm that those prices would become permanent rather than increasing to the previously planned $3/$15 rate in September. Yet enterprise spending isn't following the same downward curve. Uber reportedly exhausted its planned 2026 AI budget within four months, then introduced a roughly $1,500 monthly spending cap per employee, per agentic coding tool. The cap applies separately to tools such as Claude Code and Cursor. The broader cost pressure isn't unique to Uber. In June 2026, Gartner predicted that AI coding costs could overtake the average developer salary by 2028, pointing to rising token consumption and the shift toward consumption-based licensing. There's no contradiction here. Token prices tell you what one unit of computation costs. Your engineering bill tells you how many units you're consuming to produce something useful. And those are becoming very different numbers. #### The wrong metric is price per million tokens Model-price comparisons are useful when you're choosing infrastructure. They're much less useful when you're trying to explain an engineering budget. A developer doesn't buy “one million tokens” and turn them into one million tokens' worth of product value. They ask an agent to investigate a bug, change a service, run tests, inspect failures, search for another implementation, revise its first answer and prepare something another human can review. That workflow can involve hundreds of model and tool interactions. A 2026 trace study of roughly 4,300 real Claude Code and Codex sessions captured around 350,000 LLM steps and 430,000 tool calls, showing just how different agentic workloads are from single-response prompting. The full workload study is available on arXiv. The bill accumulates across that loop. The useful question therefore isn't: How much does our model cost per million tokens? It's: How much does one accepted unit of engineering work cost? #### Start measuring cost per accepted task An accepted task can be whatever unit makes sense for your team: a merged pull request, completed bug fix, accepted migration or finished ticket. The exact denominator matters less than using one consistently. A basic internal metric is: AI cost per accepted task = total AI coding spend ÷ accepted AI-assisted tasks But that still misses one expensive input: the person checking the output. A more useful internal calculation is: Effective cost per accepted task = (AI spend + human review cost + failed-attempt cost) ÷ accepted AI-assisted tasks This isn't an industry-standard accounting metric. It's a practical operating metric for comparing your own AI workflows over time. That distinction matters because a low-cost model that takes three attempts to produce acceptable work can be more expensive at the task level than a stronger model that succeeds immediately. API pricing is only one component; retries and senior review consume real engineering capacity too. #### Where does the money go, actually? Agentic coding spend isn't limited to the tokens that eventually become code. A large part of the workflow can be spent finding enough information to know what code should be changed. The 2026 coding-agent workload study found that these systems characteristically run long autonomous loops with long contexts and comparatively short outputs, alongside large numbers of tool calls. That workload shape is described directly in the research paper. In a large unfamiliar codebase, that can mean searching for relevant files, tracing dependencies, inspecting tests, reading interfaces, invoking tools and revisiting earlier context before implementation even begins. Some exploration is unavoidable. The expensive part is reconstructing the same organizational context again and again. #### Caching helps enormously, but it doesn't REMOVE the problem Any realistic discussion of agent costs needs to include prompt caching. The same 2026 trace study measured a 95.7% global token-weighted prefix-cache hit rate. It also found that most misses occurred around the transition from the model's previous output to the next human input, where the delay caused by reading, thinking and typing can exceed cache lifetimes. See the caching analysis in the paper. That's a major efficiency gain, but caching and context discipline solve different problems. Caching makes repeated context cheaper. It doesn't tell you whether all of that context needed to be read in the first place. And cache misses can be more expensive than they initially appear. With some providers, writing tokens into the cache carries a premium over ordinary input tokens. That makes a miss particularly painful in human-in-the-loop workflows: an agent finishes a task, someone spends several minutes reviewing it, the cached prefix expires, and the next turn may require paying to process — and potentially cache — a large part of the conversation again. This creates an operational problem too. Most users don't actively think about cache lifetimes while working with an agent. Cache behavior becomes yet another implementation detail that someone has to design around or remember. When it is ignored, repeatedly re-processing a long conversation can quietly turn into a meaningful part of the bill. A second 2026 study looking specifically at prompt caching across long-horizon agentic tasks found API-cost reductions of roughly 41–80%, depending on provider and caching strategy. It also found that caching configuration mattered: naïve full-context caching wasn't always the best strategy. The study is available on arXiv. So the sensible relationship is: Caching discounts repeated context. Better retrieval reduces how much irrelevant context there is to repeat — and how much you pay when the cache misses. #### The cheapest model can be the most expensive choice A second trap is routing every apparently “easy” task toward the cheapest model. The problem is that difficulty changes across the lifecycle of a task. A simple rename can begin with a difficult architectural question. A difficult migration can end with hours of mechanical work. A useful operating model is therefore to route by phase, not only by ticket difficulty. #### The Plan–Build–Grind–Review model ##### PLAN Use stronger reasoning when the system needs to understand constraints, explore alternatives or discover the correct scope. ##### BUILD Once the plan and context are known, a capable mid-tier model may be enough for implementation. ##### GRIND Mechanical transformations, repetitive migrations and boilerplate can often move to the cheapest adequate model or local inference. ##### REVIEW Spend more on judgment again when the job is checking assumptions, dependencies and potential failure modes. This framework is a recommendation for internal experimentation rather than a published benchmark. Teams should validate it against their own success rate, retry rate and review time rather than assuming a model tier will always win. #### Model routing changes the price of reasoning. Context changes how much reasoning you buy. Those are separate levers. Routing decides which model handles the work. Context decides how much material the model has to process before it can do that work well. And bigger context windows don't automatically solve that problem. A 2025 controlled study across five open and closed models found that performance degraded as input length increased even when retrieval was perfect and all relevant evidence remained available. The authors observed degradation across math, QA and coding tasks and concluded that input length itself can hurt performance. Read Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. A separate 2026 study focused specifically on automated bug fixing found a similar pattern. Successful agentic trajectories generally stayed between 20-30K tokens, while longer accumulated contexts correlated with lower success. In single-shot tests using 64K–128K contexts, performance dropped sharply despite the relevant files being included. See The Limits of Long-Context Reasoning in Automated Bug Fixing. So: More available context isn't the same thing as better selected context. For code work, retrieval precision matters. Four relevant files can be more useful than forty loosely related ones. #### Is your AI bill really a context bill? Check everything that happened this month: - Agents repeatedly search the same repositories - Similar tasks trigger similar file exploration - Senior engineers regularly add missing architectural context - Agents read many files before making small changes - Reviewers reject work because it duplicates something elsewhere - Long sessions become noticeably more expensive - Developers restart sessions when accumulated context becomes noisy - Different engineers make assistants rediscover the same system knowledge ##### Score 0–2 checked → Your main cost problem probably sits elsewhere. 3–5 checked → Context retrieval may be a meaningful part of the bill. 6–8 checked → You're repeatedly paying models to rediscover organizational knowledge. #### METR's 19% result is a warning about self-assessment, not a verdict on AI coding One of the most frequently cited AI-coding productivity studies comes from METR. In its randomized controlled trial, experienced open-source developers took 19% longer to complete tasks when allowed to use AI tools. Before the study, they expected AI to make them 24% faster; after completing the work, they still estimated that it had made them around 20% faster. METR publishes the methodology and results here. The sample matters enormously: 16 experienced maintainers, 246 real issues and repositories those developers had worked on for years. METR itself has repeatedly warned against generalizing the result into “AI makes software developers slower.” METR also updated its research direction in February 2026 after later data suggested the impact of newer tools might be different, while acknowledging substantial uncertainty and selection effects. The update is available here. If the tooling feels faster while retries, review time or cost per accepted task move in the wrong direction, measure the workflow. #### Context becomes infrastructure when the same knowledge gets rebuilt repeatedly A coding agent working on an unfamiliar system can reconstruct context during each session. Or the organization can maintain a reusable context layer that already knows where relevant implementations, dependencies and relationships live. Tentaro is built around the second model. Tentaro describes itself as an on-prem AI-powered code context platform. Its internal product boundary is also explicit: it doesn't generate code. It extracts code context and makes that context available to engineers and compatible AI assistants via MCP. Tentaro's internal dogfooding has covered 100+ repositories built over 15 years of enterprise delivery. That number describes the real multi-repository code estate on which the product has been used internally, not a published maximum repository limit. The architectural idea is straightforward. Instead of asking a frontier coding model to rediscover: - where authentication is implemented - which repository already contains a similar abstraction - what depends on a service - where a method is called - which implementation is relevant the context layer retrieves that information first. The expensive model can spend more of its work on reasoning and less on archaeology. #### Five numbers we'd put next to your DORA metrics You don't need a new FinOps platform to start understanding agent economics. Start with five internal measures. ##### 1. Tokens per accepted task How many tokens did the complete workflow consume before something useful was accepted? ##### 2. Attempts per accepted task Track how often the first implementation survives review. ##### 3. Retrieval share Estimate how much of the workflow is spent locating and reading information versus modifying or generating. ##### 4. Cache hit rate by step type The coding-agent trace study shows why a single aggregate hit rate can hide different behavior around autonomous tool calls and human-initiated turns. See the workload analysis. ##### 5. Cost per merged PR Don't compare this blindly between teams because PR size and workflow differ. Use it as an internal trend line. If the same team's cost per merged PR climbs while API prices fall, you've learned something much more useful than another vendor pricing comparison. #### Monthly AI Coding Economics Review MODEL ECONOMICS - AI coding spend this month - Effective price per model used - Spend by model tier WORKFLOW ECONOMICS - Tokens per accepted task - Attempts per accepted task - Cost per merged PR - Review minutes per accepted task CONTEXT ECONOMICS - Retrieval/tool calls per task - Files inspected per accepted task - Repeated retrieval patterns - Human-added context frequency - Cache hit rate: human-initiated vs tool-driven steps QUESTION TO ANSWER Did cost rise because reasoning got more expensive, or because we're buying more retrieval and retries? CTA: Use this scorecard on one team for 30 days #### What NOT to optimize first ##### Move everything to the cheapest model Cheap tokens don't guarantee cheap completed work. Compare success rate, attempts and review time alongside API cost. ##### Put hard quotas everywhere Usage controls can be necessary at scale. Uber's roughly $1,500 monthly cap per employee and per coding-agent tool is a real example. TechCrunch reported the policy in June 2026. But a quota tells you how much you're willing to spend. It doesn't tell you why you're spending it. ##### Fill the largest possible context window Long-context research gives us little reason to assume that “more” is automatically “better”. Controlled studies have found degradation with increasing context length even under strong retrieval conditions. See the 2025 perfect-retrieval experiment and the 2026 bug-fixing study. The better sequence is: measure → route → retrieve precisely → cache → cap where necessary #### Falling token prices are exposing a different problem Cheaper models are good news. But consumption is changing faster than the price list. The move toward autonomous coding agents creates longer workflows with more tool calls, more repository exploration and more material for humans or automated systems to verify. Gartner explicitly identifies rising token consumption and consumption-based pricing as the reason it expects AI coding costs to keep climbing. Its June 2026 forecast is available here. That is how both things can happen at once: The tokens get cheaper. The workflow buys many more of them. Before negotiating another model discount, take one heavily AI-assisted repository and measure: - accepted tasks - attempts - token consumption - retrieval activity - review time Then work out where the cost actually accumulates. If the frontier model is spending a meaningful part of its workflow rediscovering facts your organization already knows, price per million tokens isn't the only lever left. Context is another one. #### Find out how much of your AI workflow is context reconstruction Start with one repository. Tentaro can index the code and serve grounded context to compatible assistants through MCP, giving your team a way to compare repeated repository exploration with a workflow where relevant context is already retrievable. Tentaro's current positioning and shipped product boundary are context-first rather than code generation. --- # Blog: The complete guide to AI-powered code search for enterprise teams. Source: https://www.tentaro.ai/blog/ai-powered-code-search-enterprise-teams #### What is AI-powered code search for enterprise teams AI-powered code search is an advanced technology that enables enterprise development teams to efficiently find and navigate code across vast and complex repositories. Unlike traditional search tools that rely on simple text or pattern matching, AI-powered solutions leverage machine learning to understand the semantics and structure of code, allowing for more accurate and context-aware results. This means that developers can perform exact code search, retrieving relevant code snippets even when the search terms do not exactly match the code’s text. The primary purpose of AI-powered code search is to help teams quickly locate relevant code, documentation, and related resources across multiple repositories. By understanding code intent and relationships, these tools significantly reduce the time spent searching and navigating large codebases. The core technology behind these solutions involves sophisticated AI and machine learning models trained to interpret code syntax, semantics, and developer queries, making them indispensable for modern enterprise development environments. #### How it differs from simple text or regex searching AI-powered code search fundamentally differs from traditional text or regex-based search methods by focusing on code meaning and developer intent rather than just matching strings. While traditional search tools can only find exact matches or patterns, AI-powered solutions interpret the context of queries and the structure of code, delivering more relevant and actionable results. For example, searching for "authentication middleware" with AI-powered search can surface relevant modules and functions even if those exact words are not present in the codebase, something traditional tools would miss. ##### 1. Semantic understanding AI-powered search understands code semantics and developer intent, enabling developers to use natural language queries to find what they need. The system can map everyday language to code concepts, so a search for "user login handler" might return authentication controllers, middleware, or related functions, even if those terms aren’t explicitly used. This intent recognition ensures that developers find the most relevant code, not just textually similar snippets. - Natural language queries. Developers can search using everyday language, not just code terms. - Code concept mapping. The system connects queries to relevant code structures and concepts. - Intent recognition. The AI understands what developers are looking for, even if the exact terms aren’t present. ##### 2. Contextual indexing AI-powered search indexes code with an awareness of its structure, relationships, and dependencies. This contextual understanding allows the system to recognize how different parts of the codebase interact, improving the relevance of search results. For example, it can identify function relationships, inheritance patterns, and usage contexts, providing a holistic view of the code. Contextual elements the AI understands include: - function relationships and call hierarchies - class inheritance and implementation patterns - variable scopes and usage contexts - module dependencies and interactions. #### Key capabilities that speed up code discovery AI-powered code search offers a range of features that directly enhance developer productivity and code quality. These capabilities are especially valuable for enterprise teams managing large, distributed codebases. ##### 1. Cross-repository indexing AI search tools can index and search across multiple repositories at once, which is crucial for organizations using microservice architectures or managing numerous projects. Developers can quickly find relevant code examples and implementations across the entire organization, regardless of where the code is stored. - Multi-repository support. Indexes code across different projects and repositories. - Unified search experience. Enables finding relevant code no matter where it resides. - Microservice navigation. Simplifies working with distributed architectures by connecting related services and modules. ##### 2. Intelligent symbol and regex support AI-powered search complements traditional and symbol search rather than replacing them. Symbol search, commonly used in IDEs, analyzes code deterministically, understanding the syntax and structure of a given language. It can accurately locate symbol definitions, references, or imports across files and projects. Semantic (AI-powered) search, on the other hand, operates probabilistically. It interprets meaning and relationships that are not explicitly defined in code. For example, it can help developers find conceptually similar implementations like authentication systems written in different frameworks or languages. Instead of enhancing regex or symbolic search, AI expands the scope of discovery by understanding intent and context beyond the limits of syntax and static analysis. #### Security and deployment considerations for enterprises Enterprise teams must address security and deployment concerns when implementing AI-powered code search. Modern solutions are designed to meet stringent enterprise requirements. ##### 1. On-premises vs. cloud hosting When evaluating deployment options, I usually weigh the trade-offs between on-premises and cloud-based environments. Both approaches have clear advantages - the choice depends on how much control, flexibility, and accountability an organization wants to maintain. With an on-premises setup, I have full ownership of infrastructure and data security. Everything stays within our controlled environment, which is essential when handling sensitive code or proprietary datasets. The cloud, on the other hand, offers scalability, simplified maintenance, and rapid deployment which is ideal for teams that prioritize agility over full infrastructure control. You could find direct comparison of both deployments models done by Łukasz Jaźwa from SynergyCodes in article “On premises AI tools – safeguarding data privacy in software development”. Data security Each model protects sensitive assets differently. On-premises give me direct oversight of every layer, while cloud security depends on provider guarantees and shared responsibility models. Cost and maintenance This is where the real divergence happens. Cloud infrastructure amortizes costs and abstracts hardware management, but with on-premise, the responsibility for maintenance, updates, and uptime sits entirely with the organization. It’s more work, but also more control. Integration flexibility In practice, both deployment models should connect seamlessly, ensuring smooth integration with existing systems and APIs. With this unified approach, integration complexity is no longer a deciding factor. Regulatory compliance Deployment architecture also shapes how easily we can meet compliance requirements. For industries under strict governance like finance, healthcare, or public sector, on-premise often makes it easier to prove data residency and privacy alignment. ##### 2. Role-based access control Enterprise-grade code search tools implement robust permission systems to ensure only authorized users can access specific code. Integration with identity providers and repository-level access controls are standard, along with comprehensive audit capabilities. Security features include: - integration with identity providers (SSO, LDAP, etc.) - repository-level access control - code visibility aligned with organizational policies - audit logging and compliance reporting - data encryption at rest. #### How to choose the right AI code search tool Selecting the right AI code search solution requires careful evaluation of integration, customization, and ROI measurement. ##### 1. Integration with existing workflows AI code search tools should connect seamlessly to developers’ existing environments through the MCP server, ensuring consistent and secure integration across all systems. All integrations, including IDEs such as VS Code, IntelliJ, PyCharm, and WebStorm, as well as development platforms like GitHub, GitLab, and Bitbucket — operate via the MCP server, providing a unified and reliable connection layer. ##### 2. Customization and model tuning Enterprises can customize AI search models to better understand their unique codebases and terminology. Model adaptation is crucial for specialized domains and proprietary frameworks, with options for training and fine-tuning. Key customization aspects: - domain-specific terminology adaptation - custom ranking and relevance tuning - support for proprietary languages and frameworks - continuous learning from developer feedback. ##### 3. Measuring ROI and developer productivity Measuring the impact of AI code search is essential for justifying investment. Track specific metrics and establish baselines to demonstrate improvements in productivity and code quality. Key metrics to track: - time saved on code discovery and navigation - reduction in duplicate code implementations - faster onboarding for new team members - improved code quality and consistency - reduced context switching. #### Elevate your team with context-aware AI search AI-powered code search gives our development teams a long-term edge as we scale. It helps us preserve critical knowledge, keep our practices consistent, and maintain high code quality over time. When someone leaves, their expertise doesn’t disappear with them, it stays accessible through searchable code and context. Standardization becomes easier, since we can quickly reference existing implementations instead of reinventing solutions. It also supports quality by making it simple to find and reuse proven patterns and best practices. New developers ramp up faster because they can instantly understand how things work. And as our systems grow, we can spot inconsistencies early, reducing technical debt before it slows us down. AI-powered code search is transforming enterprise development, becoming a standard part of the modern developer toolkit. By enabling faster, more accurate code discovery while maintaining privacy and control, these solutions give teams a competitive edge. Tentaro’s on-premise, privacy-focused AI code search preserves organizational knowledge and ensures security. Book a demo to see how Tentaro can transform your team's code discovery process. --- # Blog: Air-Gapped AI: Running Code Intelligence Without Internet Access Source: https://www.tentaro.ai/blog/air-gapped-ai Air-gapped AI is an AI system designed to operate without a network path to the public internet. For code intelligence, the code, repository indexes, models and inference stack stay inside an isolated environment instead of sending context to an external API. A real air gap goes much further than running an LLM on a local server. Licensing, telemetry, model assets, software updates and dependencies also need to work when internet access disappears. That distinction matters for defense, critical infrastructure and any organization where sensitive source code can't leave a controlled environment. #### What does air-gapped AI mean? An air-gapped environment has no normal network route between the protected system and the public internet. It isn't the same as a private cloud, a VPC or an application running internally while calling an external model API. It also isn't the same as a self-hosted agent that sends inference requests to a vendor's cloud. NVIDIA's air-gap deployment documentation provides a useful practical example. Model assets are prepared while internet access is available, transferred into the isolated environment and then loaded locally. Once deployed, the NIM can run without a connection to external model registries such as NGC or Hugging Face Hub. For AI systems working with source code, the same rule needs to apply beyond the LLM. Repository data, embeddings, indexes, rerankers and the services used to retrieve code context become part of the offline stack. That's where the difference between local AI and air-gapped AI starts to matter. #### Air-gapped AI isn't a theoretical requirement anymore Defense organizations are already deploying generative AI in protected environments. Poland is a useful example. The Polish Armed Forces have developed AIRON, an AI platform operating inside Ministry of National Defence infrastructure. A presentation discussed at the Polish Senate's Digital Skills Summit 2026 described AIRON as supporting tools including chat, translation and software development inside MILNET-I and MILNET-Z, including work with classified information up to the zastrzeżone level. The military's own AI work is also moving toward local inference at the tactical level. In July 2026, Poland's Cyber Defence Component Command described AIRON TACTIC as using Edge AI to run LLMs locally. The interesting problem, then, isn't simply where the model runs. A locally deployed LLM can still know almost nothing about the architecture, dependencies and implementation history of a particular software estate. For software engineering teams, there are at least two different layers: Model layer: where inference happens. Code context layer: how the model gets accurate knowledge about the organization's repositories and systems. That second problem becomes especially important when an organization has dozens or hundreds of repositories that can't be sent to an external service. #### Five problems air gaps create for AI systems ##### 1. A local model can still have hidden online dependencies An application may use a local LLM and fail the moment its internet connection disappears. Dependencies can hide in: - license validation - telemetry and crash reporting - authentication - package managers - model registries - extension marketplaces - remote embedding APIs Some inference systems may also download missing model assets when they first start. NVIDIA's air-gap workflow requires model assets to be prepared before the isolated phase specifically so the deployed system doesn't depend on NGC or Hugging Face Hub. So instead of asking: “Does our source code leave the environment?” ask: “Would everything still work if we disconnected the cable for twelve months?” That's a much harder test. It exposes products that support local inference but still rely on an external license server, telemetry endpoint, package repository or model registry. ##### 2. Updates become part of the security architecture Air-gapped software still needs patches. The update process simply looks different. A typical workflow is: Internet-connected staging environment → download artifacts → validation → approved transfer → internal registry → offline deployment Red Hat documents a comparable process for OpenShift deployments in disconnected environments. If the internal registry can't be reached from an internet-connected host, content can be mirrored to a filesystem or removable media, physically moved into the restricted environment and then imported into the internal registry. For AI systems, the release bundle may contain more than the application itself: - application containers - model weights - tokenizer files - embedding models - rerankers - system packages - GPU drivers and libraries - database migrations - release metadata A deployment that requires docker pull latest after installation isn't really designed for an isolated network. Model weights, tokenizer, embeddings and dependencies need to travel with the application. ##### 3. Hardware sizing gets complicated quickly “Run a 14B model locally” isn't a hardware specification. A 14-billion-parameter model in BF16 requires roughly 28 GB for the model weights alone. Actual memory use grows once the inference engine, KV cache, context window and concurrent requests are included. A good real-world example comes from NVIDIA NIM's DeepSeek-R1-Distill-Qwen-14B notes. NVIDIA warns that running its vLLM profile with less than 48 GB of GPU memory can exhaust the available KV cache at the model's maximum sequence length and recommends reducing the maximum model length to 32,768 tokens in that situation. Even a 7B deployment can run into the same class of problem on a 24 GB A10G when context requirements grow. Quantization helps. For example, vLLM supports FP8 KV-cache quantization, reducing the cache's memory footprint and allowing more tokens to stay in memory. So hardware planning has to consider: - model size and quantization - maximum context - simultaneous users - embeddings and reranking - indexing workloads - storage for current, next and rollback versions A workstation-class GPU can be enough for smaller deployments. Multi-user production environments can require much more. ##### 4. Observability can't quietly depend on SaaS Many modern applications assume they can send logs, crashes and telemetry to an external service. That assumption breaks inside an isolated network. Air-gapped systems need local equivalents for: - application logs - model metrics - audit trails - administrative events - error diagnostics The organization can then pass relevant information into its own internal monitoring or SIEM systems. Telemetry also needs a genuine off switch. “Anonymous telemetry” is still network traffic if it leaves the environment. ##### 5. Models become part of the patch lifecycle Traditional software already has dependencies and security updates. AI adds more moving parts: - new model weights - embedding models - tokenizer changes - inference engines - agent frameworks Each new artifact needs to follow the same controlled import path. Air-gapped AI therefore benefits from small, deterministic and clearly versioned release bundles rather than installations that discover dependencies dynamically. #### A practical architecture for air-gapped code intelligence A useful design separates the external preparation environment from the isolated runtime. The external side prepares, validates and packages software. Only approved artifacts cross the boundary. Inside the protected environment, services that would normally live on the public internet need local equivalents. A simplified architecture could look like: INTERNAL SOURCE CONTROL GitLab / GitHub Enterprise / Bitbucket / Azure DevOps / Perforce ↓ CODE INDEXING ↓ LOCAL KNOWLEDGE STORE ↓ SEMANTIC RETRIEVAL / CONTEXT ↓ LOCAL LLM ↓ DEVELOPER / MCP / INTERNAL UI The important point is that the model is only one component. For code intelligence, the retrieval layer decides what the model knows about the organization's actual software. Where Tentaro fits into an air-gapped code intelligence stack Tentaro is an AI-powered code context platform built around that retrieval layer rather than another general-purpose coding model. It indexes an organization's private source code and builds an internal knowledge base that can be queried in natural language. Unlike search limited to one repository at a time, Tentaro is designed for multi-repository environments and says it can work across more than 100 repositories. That matters in large software estates where a developer asking “Do we already have a service that handles this?” may need an answer spanning multiple teams, shared libraries and services. Tentaro's existing product architecture includes several pieces relevant to isolated environments. ##### On-premise deployment Tentaro can run on the customer's own infrastructure or a dedicated cloud environment, giving the organization control over the deployment and configuration. Its public product information also states that customers can choose their own LLM rather than relying on one mandatory vendor-hosted model. That model flexibility matters because an organization can pair the code context layer with an inference stack already approved for its environment. ##### Repository indexes without internet access Tentaro states that repository indexes are stored inside isolated containers with no internet access. It also says stored contents, analysis results and responses are encrypted using AES-256. For an on-premise deployment, Tentaro says customer data stays inside the organization rather than being sent to an external code intelligence service. ##### Multi-repository context The platform semantically indexes code across repositories and retrieves relevant implementations instead of relying on the LLM's general knowledge. Tentaro can point users back to the files involved in an answer and enrich those references with explanations highlighting relevant lines. It also supports incremental indexing so changed files can be reprocessed without rebuilding the entire index. For more detail on that layer, Tentaro has a separate guide to AI-powered code search for enterprise teams. #### MCP integration Tentaro exposes an MCP server for integration with developer tooling. In an isolated deployment, that creates a useful pattern: Developer tool → Tentaro MCP → local code context → local model The code-intelligence layer can provide repository-specific context without requiring the developer's assistant to retrieve that context from an external SaaS service. #### What still needs to be validated for a full air-gap deployment On-premise deployment and internet-isolated repository indexes are strong building blocks, but air gap describes the complete operating lifecycle, not one product feature. For any specific deployment, teams should still validate details such as: - offline license behavior - installation dependencies - update package transfer - rollback procedures - model distribution - telemetry settings Those are exactly the questions that separate “can run locally” from “can operate indefinitely without an external network path.” #### Offline licensing matters more than it sounds Licensing is one of the easiest ways to accidentally break an air-gapped deployment. A product that needs to reach its vendor every few days to confirm its subscription can't operate independently inside a disconnected enclave. One common solution is a cryptographically signed offline entitlement. For example, Coder's licensing system uses signed JWT license keys that are validated locally. Coder explicitly says no outbound connection to its servers is required, including in offline and air-gapped deployments. Other implementations use signed license files containing customer information, entitlements, expiration dates or machine identifiers. Keygen documents signed license files specifically for offline and air-gapped environments. Possible designs include: - perpetual licenses - time-limited signed licenses - machine-bound licenses - local floating license servers - controlled challenge-response renewal The key question isn't simply: “Do you offer offline licensing?” It's: “What happens to the product after six or twelve months without any communication with your infrastructure?” #### A data diode isn't the same thing as an air gap The terms sometimes get mixed together. NIST defines a data diode as a device that allows data to travel in only one direction. It's also called a unidirectional gateway. That means a data diode still creates a communication path. An air-gapped network may have no such path at all. For example, an organization could use a diode to export logs: CLASSIFIED NETWORK ↓ DATA DIODE ↓ MONITORING NETWORK Nothing can travel back through the same channel. But that doesn't mean every air-gapped system receives its updates through a data diode. Many environments use controlled physical transfer instead. #### Local doesn't automatically mean secure Removing internet access eliminates a major class of external communication paths. It doesn't eliminate security risk. A local AI agent can still have: - filesystem permissions - shell access - access to internal tools - access to source repositories - permission to modify files The question therefore shifts from only “Can source code leave the network?” to “What can the AI do inside the network?” Physical transfers create another attack surface. CISA's Cybersecurity Performance Goals explicitly warn that attackers can use removable media such as USB drives to introduce malware into disconnected or air-gapped systems. That's why controlled update processes may include a dedicated transfer station, malware scanning, cryptographic validation and strict media handling. An air gap changes the threat model. It doesn't remove the need for one. #### Air-gapped AI and accreditation for classified systems For organizations handling classified information in Poland, there's another distinction worth making. A specific teleinformation system gets accredited, not a software product in isolation. According to Poland's Internal Security Agency (ABW), systems intended to process classified information marked zastrzeżone are accredited by the head of the organizational unit through approval of the system's security documentation. ABW or SKW can then issue recommendations relating to the system. Systems processing poufne or higher classifications are accredited by ABW or SKW. The authority has six months from receiving complete security documentation to grant or refuse accreditation, with another six months possible in justified cases. That distinction matters for vendors. Saying that a product can operate in an isolated environment isn't the same as saying it is independently “certified for classified information.” The configuration, infrastructure, procedures and organization all form part of the accredited system. #### Questions to ask any air-gapped AI vendor “On-prem”, “private” and “local AI” are useful starting points. They aren't enough to verify an air-gapped deployment. Ask: - Can the system be installed with public DNS and internet connectivity completely unavailable? - Can the license remain valid without contacting your infrastructure today and a year from now? - What is the complete update procedure from release download to production deployment? - Can telemetry be disabled completely? - Are the model, tokenizer, embedding model and reranker included in the deployment package, or will anything try to download during startup? - How can administrators verify the integrity and origin of every imported artifact? - What is the rollback procedure if an offline update fails? - What exactly stops working when external network connectivity disappears? A vendor that can answer all eight questions precisely probably understands disconnected operations. One that keeps returning to “your data stays private in our cloud” is answering a different question. #### Air-gapped code intelligence is an architecture, not a checkbox Running an LLM locally is becoming easier. Operating a useful AI system indefinitely inside a disconnected environment is harder. Models need context. Software needs updates. Logs need somewhere to go. Licenses need to remain valid. Hardware needs enough capacity for actual workloads rather than just model weights. And for software engineering teams, the AI needs accurate knowledge of the code it's being asked about. That's the role of the code context layer. Tentaro's on-prem AI code context platform combines multi-repository indexing, isolated repository storage, configurable models and MCP access to keep that context close to the software it describes. For teams evaluating any system for a disconnected environment, though, the final test stays simple: Disconnect the cable. Then ask what still works. --- # Blog: Best AI coding tools in 2026 – comparison for programmers and tech teams. Source: https://www.tentaro.ai/blog/best-ai-coding-tools-in-2026-comparison-for-programmers-and-tech-teams #### Why code context is now a core engineering problem AI coding assistants have fundamentally changed the pace at which engineers write code. GitHub Copilot can generate a function in seconds. Claude Code can refactor an entire module in one prompt. But there is a gap that these tools do not address: context outside of the project. It has no access to all your repositories at once, no institutional knowledge, and in most cases no awareness of decisions made six months ago. The result: duplicated code, repeated meetings, and onboarding cycles that stretch for weeks. This is the problem that a new category of tools is trying to solve: AI-powered knowledge and collaboration layers built specifically for engineering teams. #### The main categories of AI coding tools for tech teams Before comparing specific products, it helps to distinguish between four types of tools competing in this space: AI coding assistants (GitHub Copilot, Cursor, Codeium, Zencoder) generate, edit, test, and refactor code. They work at the file or agent level and have no memory of your broader system architecture. AI code search platforms (Sourcegraph, Grep.app, Graphify, Understand Anything) index codebases and support structured and natural language queries. Sourcegraph's Deep Search provides agentic AI search across large monorepos. Knowledge management tools (Glean, Mintlify, Curiosity) are designed for documentation, not code. They work well for product specs and wikis, but engineering teams rarely keep documentation current enough for these tools to be reliable. AI context platforms (Tentaro, Unblocked, Ozgar AI) combine codebase indexing with natural-language interaction, institutional context, and team collaboration features. This is the fastest-growing segment and the one with the most direct impact on team productivity. 4 categories of coding tools Tool Category Deployment Code search / graph Collaboration Access control Tentaro AI context platform On-prem only Multi-repo semantic search; knowledge graph layer on roadmap Code sharing Admin & member-scoped views Unblocked AI context platform Downloadable Mac desktop app + MCP client; backend is cloud SaaS by default, Enterprise tier deployable in the customer's own cloud/VPC Read-only, code-aware grounded Q&A + AI code review over MCP PR-level review comments, no voice messaging Enterprise, permission-aware access; SOC 2 Type II Ozgar AI AI context platform Independent deployment: on-prem, private cloud, or public cloud (Docker/K8s) Live knowledge graph, auto-docs, visualizations Documentation-centric, not chat-first Role-based access, audit logs GitHub Copilot AI coding assistant Cloud only (GitHub.com, IDE extensions) No cross-repo search (Enterprise tier can index one org's codebase) No GitHub-native (Business/Enterprise seat management) Zencoder AI coding assistant Cloud, on-premise, or hybrid; BYOK Multi-repo indexing with architectural/dependency awareness CI/CD integrations, scheduled automation Approval gates, role-based permissions, SSO Sourcegraph AI code search platform Self-hosted (Docker Compose/Kubernetes) or Sourcegraph Cloud; true air-gap possible with local models Deterministic SCIP graph + keyword search (no embeddings); Deep Search Limited async collaboration; code monitoring alerts Enterprise SSO/SCIM, RBAC Graphify Code search (OSS) Local, self-hosted (pip package); sends only semantic summaries to your configured LLM, never raw source AST code knowledge graph (Tree-sitter + NetworkX + Leiden), blast-radius, auto-docs, visualization None — no hosted product None Understand-Anything Code search (OSS) Self-hosted, rides host agent Graph-UI visualization layered on a frontier agent Depends on host agent None Glean Knowledge management Cloud (250+ connectors) No code-specific indexing No Permission-aware enterprise access, SSO Curiosity Knowledge management On-premise / self-host, EU Document graph + search, no AST or symbol graph Mature ReBAC permission inheritance Mature ReBAC Kapa AI Knowledge management Cloud SaaS Docs-RAG, thin code slice Ticket deflection SSO & RBAC, SOC 2 Type II #### Tentaro - cross-repository AI code context with team collaboration built-in Tentaro is built around a specific hypothesis: the biggest productivity loss in engineering teams is not slow code generation, it is the inability to find and share institutional knowledge across repositories and people. The platform indexes all connected repositories and allows developers to query in natural language. A question like "Where do we handle authentication across services?" returns results with source-tagged references from multiple repos simultaneously, not a list of files to manually inspect. Multi-repository AI code context Unlike general AI assistants that operate within a limited project context, Tentaro searches across all repositories in a single query. Results include file references, repository labels, and code snippets, synthesized into a readable answer. Cross-project search Narrow results by selecting specific repositories or projects, and use natural-language prompts to target exactly the file types you need - from configs and schemas to tests, components, and backend services. Context sharing via chat Tentaro allows sharing a link with code context and threads via chat across projects and teams. This is particularly useful in organizations with multiple product lines or microservice architectures, where a decision in one repository affects another. Voice-to-text search Developers can just ask a question out loud and get the context back, without breaking their flow to type it out. Incremental indexing, permanent knowledge Unlike local agents such as Claude Code, Tentaro doesn't need to re-search files and rebuild context from scratch every time. All projects are indexed centrally, once, and that knowledge stays available to every other member of the team afterward, one indexing job for the whole team, instead of each developer repeating the same local indexing on their own machine. Security, deployment, and lightweight LLMs Tentaro runs entirely on-premise, including private-cloud and fully air-gapped setups – the full AI stack stays inside a team's own infrastructure, with no dependency on a vendor model provider. Answers are grounded in the team's own repositories only, so sensitive code never has to leave the network to get indexed or queried. The platform can also run on lightweight LLMs instead of routing every query to a frontier model, cutting inference cost and resource use for teams operating at scale. Access is available through both a Web interface and an MCP server, so teams can query Tentaro directly or plug it into MCP-compatible tools like Claude Code without switching context. Cross-repository code context #### Where each AI coding tool fits The question is not which tool is best in isolation, it is which combination solves the actual bottlenecks in your team. For greenfield projects with small teams, GitHub Copilot or Cursor combined with Slack is often sufficient. The codebase is small enough that developers carry context in their heads. For teams with more than 100 repositories or fifty engineers working remotely, institutional knowledge starts to drift. Someone leaves, a decision gets made without being documented, onboarding takes weeks instead of days. This is where a code context layer like Tentaro provides measurable return. For enterprise teams with complex access control requirements Sourcegraph leads with deterministic, compiler-accurate navigation and mass-change tooling at massive scale, with AI search added on top; Tentaro leads with semantic, cross-repo Q&A and running it’s full AI stack on-prem without dependency on a vendor model provider. #### What to look for when evaluating AI coding tools for tech teams When assessing tools in this category, the key criteria are: - Scope of indexing - does the tool access all your repositories or require project-by-project setup? - Answer quality - does it return synthesized natural language answers or raw search results? - Security and deployment model - is it cloud-only, private-cloud, or true air-gapped? Can it run on lightweight/local LLMs to cut inference cost and resource use, rather than requiring a frontier model for every query? Does it expose both a Web interface and an MCP server, or lock you into one surface? - Integration surface - does it work within your existing developer workflow (IDE, CI, Slack) or require context switching? Evaluation of AI coding tools #### Summary AI coding assistants solve the "write code faster" problem. They do not solve the "understand and share our codebase" problem. The competitive landscape around that gap is no longer empty, though: Unblocked contests the same center directly, free OSS tools like Graphify and Understand-Anything have made the underlying code graph much cheaper to get, and sovereignty-forward platforms like Sourcegraph and Curiosity are closing the deployment gap that used to separate the leaders from the rest. Tools like Tentaro address the second problem by combining cross-repository AI search with collaboration features: code sharing and voice to text search. For engineering teams dealing with knowledge fragmentation, repository sprawl, or high onboarding costs, this category of tooling is worth evaluating. The competitive landscape for AI code agents is early. and the feature sets are evolving quickly. The teams that integrate AI knowledge layers now will have a structural advantage in developer productivity and institutional memory retention. Want to know more? Book a meeting to talk about the best option for your tech team --- # Blog: Bus Factor: How to Measure and Reduce It in Engineering Teams Source: https://www.tentaro.ai/blog/bus-factor Bus factor is the minimum number of people who could leave a software project before the loss of their knowledge causes work to stall. A bus factor of one means one person's absence can put a critical system at risk. The name is deliberately dark, but the underlying problem isn't. People resign. They transfer teams. They take parental leave. A senior engineer becomes unavailable during an incident. The risk isn't that someone gets hit by a bus. It's that the organization discovers too late that a system and one person's memory had become the same thing. Software-engineering research treats bus factor as a measure of knowledge concentration, not just commit ownership. A 2022 study surveying 269 engineers found that version-control history alone misses important ways engineering knowledge is created and distributed, especially through code review and team communication. Read Bus Factor In Practice. That gives engineering leaders a much better question than “Who wrote the most code?” Who does the organization stop functioning without? #### Why bus factor is more than engineering folklore Bus factor is often treated like an inside joke because the name sounds like one. Research suggests engineering teams take the underlying risk much more seriously. In Bus Factor In Practice, researchers from JetBrains Research and academic collaborators surveyed 269 engineers, tested their estimation method on 13 JetBrains projects and concluded that engineers regarded bus factor as an important issue in collaborative software development. Crucially, their model improved when it incorporated code reviews and communication data alongside version-control history. The full paper explains the methodology. Earlier work reached a similar conclusion from repository data at larger scale. A 2016 study estimated the truck factor of 133 popular GitHub projects and found that 65% had an estimated factor of two or lower. The authors also stressed that there's no universally accepted formula for calculating the number. See A Novel Approach for Estimating Truck Factors. You shouldn't treat bus factor like an accounting metric where a score of 1.7 has some universally agreed meaning. What it gives you is a structured way to find dangerous knowledge concentration before a resignation, reorganization or incident finds it for you. And the useful unit often isn't the whole company. A 100-person engineering organization can have a decent organization-wide bus factor while one payment service, legacy integration or deployment pipeline still has a bus factor of one. #### Don't calculate bus factor from commits alone The easiest way to estimate bus factor is to open git log, count authors and assume the most active contributor knows the system best. That's a useful starting signal. It isn't enough. The 2022 bus-factor research found that knowledge flows through multiple channels, which is why its proposed multimodal method incorporates version control, code review and meetings rather than relying on commits alone. For an internal engineering audit, I'd start with three signals. #### Signal 1: ownership concentration Run repository history at the directory or subsystem level, not only for the repository as a whole. You're looking for paths where: - one engineer dominates meaningful changes - very few other engineers touch the code - the secondary contributors made only superficial changes - activity has remained concentrated over a long period A file with 20 authors isn't necessarily safe if 19 of them changed configuration strings while one person built every meaningful behavior. The goal isn't to establish perfect authorship. It's to locate the places worth investigating. A 2024 JetBrains Research project called Bus Factor Explorer takes a similar subsystem-oriented view. It uses version-control history and treemap visualizations to identify files and areas at risk when developers leave. #### Signal 2: review concentration Now look at who approves changes. A senior engineer may have written almost none of a subsystem recently and still be its real knowledge owner. You see it when: - nearly every meaningful PR requests the same reviewer - changes wait until that person is available - other reviewers approve syntax and style but defer architecture questions - a developer says “I'd rather wait for Alex to look at it” Commit history misses that knowledge. Review topology catches some of it. That's one reason the Bus Factor In Practice researchers included code-review activity in their model rather than treating version-control authorship as a complete proxy for knowledge. (arXiv) #### Signal 3: question routing The third signal barely needs tooling. For two weeks, record where engineering questions go. Not the answers. Just the destination. Examples: How does the retry logic work? → Maya Why can't we change this schema? → Maya Where does the settlement job actually run? → Maya Can I safely remove this queue? → Maya When that pattern appears repeatedly, the org chart can say whatever it wants. Maya is part of the runtime. This signal matters because bus factor is fundamentally a knowledge-distribution problem. Repository activity tells you who changed software. Question routing tells you who the team believes can explain it. #### What’s your bus factor risk? Don't answer for the entire engineering organization. Pick one system whose failure would hurt. ##### 1. Contribution concentration 0 points: several engineers make meaningful changes 1 point: two engineers dominate 2 points: one engineer dominates ##### 2. Review concentration 0: reviews are distributed 1: one reviewer appears frequently 2: meaningful changes effectively require one person's approval ##### 3. Question concentration 0: questions distribute across the team 1: one or two people answer most of them 2: nearly every difficult question routes to one person ##### 4. Backup ownership 0: another engineer can take over now 1: a backup exists but needs help 2: there is no credible backup ##### 5. Safe-change capability Ask: If the primary expert were unavailable tomorrow, could someone else make and ship a non-trivial change to this system this week? 0: yes 1: probably, with delays 2: no ##### Your score 0–2: Distributed context → Low immediate key-person exposure. 3–5: Concentrated context → Worth monitoring and deliberately spreading. 6–8: Key-person dependency → One absence is likely to slow meaningful work. 9–10: Critical exposure → Treat the system like any other production single point of failure. #### What reduces bus factor The standard answer is “write better documentation.” Documentation helps. It isn't enough. The reason becomes obvious when you separate different kinds of engineering knowledge. A README can explain how to start a service. An architecture diagram can show its major components. Neither necessarily captures why an engineer knows that one innocuous-looking call can't be moved inside a transaction because someone tried it three years ago and triggered a production incident. Reducing bus factor means distributing several kinds of context rather than producing more pages. ##### Record decisions that code can't explain Architecture Decision Records, design notes and well-kept decision history preserve something source code can't: alternatives and rationale. The code tells you what won. It rarely tells you what lost and why. That distinction becomes particularly important when ownership changes. A new engineer can inspect the current queue implementation. They can't infer with certainty which failure caused the team to introduce it. Record high-impact decisions close to the work and link them to the code, issues or PRs they concern. ##### Rotate ownership deliberately Shared ownership doesn't happen because a second engineer attended two pairing sessions. They need to make meaningful changes. Give another engineer: - a real feature - an incident - a migration - a production fix - review responsibility and let the primary owner become the backup. Yes, this can reduce short-term velocity. That's the cost of buying down concentration risk. If an organization refuses to pay any short-term cost for knowledge distribution, it is implicitly choosing to pay later when the primary owner becomes unavailable. ##### Make routine system knowledge queryable There is another class of question that doesn't need a senior engineer's judgment at all: - Where is this implemented? - Which services call it? - Do we already solve this elsewhere? - Which repository contains the equivalent behavior? - What files are relevant to this workflow? Those questions often route to humans because asking a colleague is faster than manually exploring an unfamiliar codebase. That behavior changes once asking the system becomes faster. Tentaro is designed around that layer. It indexes private repositories and returns grounded code context to engineers and compatible AI tools rather than generating code itself. Answers can point back to real source locations so the engineer can verify the result rather than treating generated prose as organizational truth. Tentaro's internal product boundary explicitly defines it as grounded context, not code generation. The goal isn't to “replace the expert”. It's to stop using the expert as a human search endpoint for questions the repositories can answer. #### A quarterly bus factor audit you can run without buying anything Run this once per quarter on your most important systems. ##### Repository layer - Identify dominant contributors per subsystem - Ignore cosmetic or mechanical changes when assessing meaningful ownership - Flag areas with one dominant author - Check if the dominant contributor is still on the team ##### Review layer - Find the most frequent reviewers per subsystem - Flag modules where one reviewer is effectively mandatory - Identify PRs delayed while waiting for one person - Name a credible secondary reviewer ##### Knowledge layer - Track question destinations for two weeks - Count repeated questions - Identify questions answerable directly from repositories - Separate structural questions from decision/rationale questions ##### Continuity layer - Name a backup owner - Give that backup a real change to ship - Confirm they can deploy and troubleshoot independently - Record the critical decisions code alone can't recover The audit shouldn't end with a spreadsheet. Pick the two worst systems and put knowledge-distribution work on an actual roadmap. #### When the bus has already hit Sometimes you're reading about bus factor because the person already left. The priorities change. You aren't reducing hypothetical risk anymore. You're reconstructing enough understanding to operate safely. ##### First: freeze avoidable risk Don't freeze the entire system. Freeze non-essential changes in the parts nobody can currently explain. Every speculative refactor performed during a knowledge gap adds another variable. ##### Second: find the remaining knowledge paths The former owner may be gone, but context can survive in: - code reviews - pull request discussions - issues - ADRs - incident reports - commit messages - teammates who worked adjacent to the system Recover the highest-blast-radius decisions first. ##### Third: name a new owner before they're ready Waiting until someone “fully understands” the system leaves it ownerless during the period when ownership matters most. Give someone responsibility now and make knowledge acquisition part of their work. ##### Fourth: test independence with a real change Don't measure transfer in meetings attended or pages written. Give the new owner a non-trivial task. Can they identify the relevant code, trace its dependencies, explain the likely impact, make the change and get it safely through review? If not, you've found the remaining knowledge gap. #### The engineer left. What can the team no longer answer? Pick one affected system and write down five questions the team now routes to the departed owner. Then split them: STRUCTURAL - Where is it? - What calls it? - What depends on it? - Where else is it implemented? HISTORICAL / JUDGMENT - Why was it designed this way? - What was rejected? - Which constraint still matters? The first group can often be reconstructed from code. The second survives only if someone recorded it. CTA: Bring one high-risk system to an onboarding teardown #### AI changes both sides of the bus-factor equation AI can help reduce some forms of knowledge friction. DX analyzed onboarding data across six multinational enterprises in 2025 and found that engineers using AI daily reached their tenth PR in 49 days compared with 91 days for engineers who didn't use AI. The study uses tenth PR as an onboarding milestone rather than claiming it equals complete system mastery. DX explains the analysis here. DX's 2026 data shows the broader time-to-tenth-PR metric continuing to fall, reaching an average of 33 days across its dataset. Again, faster contribution isn't the same as distributed architectural knowledge, but it shows AI can materially change how quickly new engineers begin working in a codebase. See DX's 2026 measurement guidance. At the same time, AI can increase the amount of code the organization needs to understand. Faros's 2025 analysis of teams with high AI adoption reported 98% more merged PRs, 91% longer PR review time and 154% larger PRs compared with lower-adoption teams. Faros is explicit that the data is observational, so it shows correlation rather than proving AI caused each change. Read the original Faros report. That gives bus factor a new wrinkle. Historically, a system could become dependent on one person because that person built it over years. Now code production can accelerate faster than knowledge distribution. A module can be new and still have concentrated understanding. The question therefore isn't only:How many people know our old systems? It's increasingly: How many people can explain the software we're shipping now? #### Don't confuse bus factor with headcount Adding another engineer doesn't automatically increase a system's bus factor. Neither does adding another person to a repository. A useful test is much harder: If the primary expert disappeared today, who could make tomorrow's difficult decision without them? If the answer is nobody, your bus factor hasn't changed. The same applies to documentation. Fifty wiki pages don't necessarily distribute knowledge if everybody still asks the same engineer before making a change. Measure observable independence instead: - Can another engineer review the subsystem? - Can they diagnose it during an incident? - Can they explain its major dependencies? - Can they make a meaningful change without the original owner? - Can they verify answers against sources rather than relying on memory? That is much closer to the risk bus factor is trying to describe. #### Start with your bus-factor-one systems Don't build an organization-wide bus factor program. Find the systems where one absence causes the most damage. For each one: - Map contribution concentration. - Map review concentration. - Track question routing. - Name a backup owner. - Move routine structural questions out of one person's head. - Record decisions that can't be reconstructed from source. - Give the backup owner a real change. - Repeat the test next quarter. The goal isn't a perfect metric. It's a system where someone's resignation is an HR event rather than an architecture event. #### Which part of your codebase still has a human API? Start with one system where questions repeatedly route to the same engineer. Tentaro can index the repositories behind it and make structural code context queryable to engineers and compatible AI assistants, with answers grounded in source rather than another person's availability. It doesn't recover decisions nobody recorded and it doesn't replace engineering judgment. It handles the part the code itself can actually answer. --- # Blog: Case study - reuse engineering, validated patterns with Tentaro and Claude Code. Source: https://www.tentaro.ai/blog/case-study-reuse-engineering-validated-patterns-with-codeqa-and-claude-code #### The project at Synergy Codes I was asked to build a table view using a library I had never worked with before. The feature had already been estimated at roughly 80 development hours, and I didn't have time to spend days researching different implementation approaches. What I didn't know at the time was that another team at Synergy Codes had already solved a very similar problem months earlier. Using Tentaro, I found that implementation, understood the architectural decisions behind it, and reused production-validated patterns instead of rediscovering them from scratch. The result: a feature originally estimated at 80 hours was delivered in under 40. Synergy Codes was tasked with building a data table component for Processive MedTech Development Services, a company building software and usability solutions for the medical industry. The scope: an alternative view for browsing complex datasets, with sorting, filtering, search, column resizing, and column management, including the ability to select which columns are displayed and reorder them. The component also needed to be flexible enough to accommodate future additions: export, clickable elements within cells, and other features not yet fully defined. Extensibility was a requirement from the start. The constraint was tight. The client's combined design and development estimation was 80 hours, and they had one key request: they really liked the Figma designs and wanted the implementation to stay as close to them as possible. ##### Choosing the right library The team evaluated two options: AG Grid, a leading enterprise grid; and TanStack Table, a headless library that delivers logic and functionality without enforcing any UI. AG Grid is actually a great library. You can customize a lot of things. But from experience, it can get messy in code, and sometimes you have to adapt to AG Grid rather than the other way around. That takes time. If I hadn't had an existing implementation from another project, I would have gone with AG Grid, just to have the components out of the box. I didn't have time to research TanStack Table from scratch: how it works, how hard it is to implement. But I found out there was already a working table built with TanStack in another project, extensible, easy to style, with more features than I even needed. And it meant AI had a verified, production-tested source to work from. That's what made the decision. ##### The challenge with unfamiliar territory Evaluating a new library takes real time. Reading documentation, testing edge cases, validating integration patterns, then building the actual feature on top of that discovery work. What I didn't know: the research had already been done. A developer on another team at Synergy Codes had built a TanStack Table implementation for an internal project months earlier. He had evaluated multiple approaches, resolved integration challenges, and shipped it to production. The knowledge existed. The components existed. The engineering decisions had already been made. They just weren't visible across teams. #### The implementation: Tentaro + Claude Code + Figma Using Tentaro's extensive knowledge of internal repositories, I found the existing TanStack Table implementation. I could see how it was structured, what patterns were used, and how it had been integrated in a real production environment. From there, I combined three tools into a single workflow: - Tentaro (via MCP server) to search and access the validated implementation from the other team's project, - Claude Code to adapt those components to the new project's structure and requirements, - Figma MCP to pull the client's design specs directly, ensuring the output matched the mockups. I wrote a prompt telling it to take the table logic from the codebase and the designs from Figma. It pulled the components and adapted them to our project. I worked feature by feature, monitoring the output at each step. Claude was not generating code from scratch; it was adapting production-validated patterns to a new context, with design fidelity enforced directly from the source Figma file. Without the previous implementation, I would still have needed to evaluate the library, validate architectural decisions, and understand edge cases myself. Tentaro didn't remove engineering work. It removed the need to repeat engineering work that had already been done elsewhere in the organization. ##### Results Within a week I had a solid basic version in place: column resize, pagination, the ability to select elements, and styles applied according to the designs. The buttons were added but not yet functional. The client was surprised. The table feature was estimated for 80 hours, and the feature was delivered design-matched, tested, and ready for sign-off, well under that estimate in 40 hours. > "What impressed us was how quickly the team delivered a solution that still matched our design expectations and remained flexible for future development." > Maria Lund Jensen, Co-owner and consultant at Processive MedTech > "What stood out to us was not simply faster implementation, but the ability to build on top of already validated engineering decisions instead of repeating foundational work from scratch. This is something we actively advocate for in our consulting work as well." > Barney Gerrard, Co-owner and consultant at Processive MedTech Development Services #### What made the difference - three value dimensions stand out from this case ##### 1. Production-ready as the baseline, not the goal There is a meaningful difference between AI-generated code and production-validated code. Claude, working from general training data, could have built a TanStack Table, but with uncertain edge cases and untested integration patterns. The Tentaro baseline was code that had been built, deployed, and battle-tested inside Synergy Codes. Claude's role shifted accordingly: instead of library discovery and pattern validation, it handled adaptation and design matching. The hard work was already done. Claude Code ##### 2. Knowledge reuse without manual coordination I knew a colleague had worked on something similar. What I needed was to find the exact implementation quickly, understand its structure, and adapt it, without scheduling a meeting to get a walkthrough. Tentaro collapsed that process into a direct query. My colleague could add context at a higher level, pointing to specific files, rather than re-explaining foundational decisions from scratch. ##### 3. MCP integration as the multiplier Before the Tentaro MCP server was available, I rarely used the tool. Once the integration connected Tentaro, Claude Code, and Figma into a single workflow, adoption was immediate. The compound effect, codebase intelligence feeding directly into an AI coding session, is what made the difference. "Once the MCP server is there, it all just moves fast," I said. I knew the previous implementation was solid; it had already made it to production on another project. So I didn't have to redo that research. I pulled the components, adapted them for our client, and they were genuinely surprised at how quickly it came together. #### The pattern this case reveals In most engineering organizations, knowledge produced on one project stays on that project. When another team faces a similar problem, they start from zero: redoing research, revalidating patterns, making decisions that have already been made elsewhere. Tentaro changes where that knowledge lives. Multi-repository search across internal knowledge means that a validated implementation from three months ago, on a different team, is as findable as something you wrote yesterday. The developer working on the new feature doesn't need to know the previous work existed. They just need to ask. Tentaro The Synergy Codes case is one instance of a pattern that repeats constantly across engineering teams: hard-won knowledge, siloed by team and project boundaries, rediscovered at cost by someone else. See how Tentaro gives your team instant access to your codebase's knowledge at Synergy Codes full version of Case Study. Tentaro is built to provide context for technical teams and access to internal knowledge. Do you want to talk with our team? Book a demo → --- # Blog: Cognitive Debt in Software Engineering: What It Is and How to Measure It Source: https://www.tentaro.ai/blog/cognitive-debt-in-software-engineering Cognitive debt is the growing gap between what a software system does and how well the people responsible for it understand why it works that way. The term has moved quickly from practitioner shorthand into mainstream engineering discussion. In April 2026, Thoughtworks added codebase cognitive debt to its Technology Radar, describing the widening gap between a system's implementation and a team's shared understanding of how and why it works. Thoughtworks specifically points to AI-assisted development as one factor that can widen that gap. Code can now change faster than teams build the mental models needed to review, debug and safely modify it. See the Thoughtworks Technology Radar entry. That makes cognitive debt different from technical debt. But there is another distinction worth making. At Tentaro, we also use the term context debt for a related problem: engineering knowledge that exists, or once existed, but is no longer reliably available when humans or AI systems need it. The distinction matters because cognitive debt describes what people no longer understand. Context debt describes part of the reason they have to reconstruct that understanding in the first place. #### Cognitive debt is not technical debt Technical debt usually describes compromises inside software: shortcuts, outdated architecture, duplicated logic, fragile integrations or work deliberately postponed. Cognitive debt can exist in perfectly reasonable code. A service can be well tested and maintainable while only two people understand why it is structured the way it is. An AI-generated implementation can pass every test while nobody on the team can confidently explain how it interacts with an older subsystem. The location of the debt is different. Technical debt lives primarily in the implementation. Cognitive debt lives in the gap between that implementation and the people expected to reason about it. Thoughtworks makes a similar distinction in its 2026 Radar discussion. Codebase cognitive debt grows when teams accept changes without developing the mental models required to understand them later. Read Thoughtworks' overview. The two can reinforce each other, but they need different remedies. Refactoring can reduce technical debt. It does not automatically teach five engineers why the architecture looks the way it does. #### Cognitive debt and context debt are not the same thing The terms overlap, but treating them as synonyms makes both less useful. Cognitive debt describes a human understanding problem. Context debt describes an organizational retrieval problem. At Tentaro, we use the following working definition: Context debt is the accumulated cost of engineering knowledge that exists, or once existed, but is not captured, connected or retrievable when humans and AI systems need it. It is deliberately a working definition rather than an established industry standard. The principal accumulates when decisions, trade-offs and workarounds disappear into people's heads, old tickets, pull-request discussions, commit history or tools nobody knows to search. The interest appears every time somebody has to reconstruct that knowledge. A senior engineer explains the same subsystem again. A new hire spends weeks performing code archaeology. A reviewer has to work out why an unusual implementation exists. An AI coding assistant crawls the same repositories and rebuilds the same context on every new session. That gives us a useful distinction: Type of debt Core problem Typical cost Technical debt The implementation itself makes future change harder Refactoring, failures, slower development Cognitive debt Too few people understand the system well enough to reason about it Review bottlenecks, debugging difficulty, expert dependence Context debt Relevant engineering knowledge cannot be retrieved when needed Search, reconstruction, onboarding, repeated explanations, AI token use Context debt can contribute to cognitive debt. If important reasoning is difficult to retrieve, every engineer has to reconstruct more of the system independently. Understanding becomes expensive, concentrates around a few experienced people and disappears more easily when they leave. That is why improving context retrieval does not magically eliminate cognitive debt. It reduces one of the mechanisms that keeps producing it. #### Why AI makes cognitive debt more visible AI did not invent cognitive debt. Software teams have always inherited systems they did not fully understand. Engineers leave. Documentation decays. Decisions disappear into Slack threads and closed pull requests. What AI changed is the relative speed of generation and comprehension. Faros AI's 2025 telemetry study found that developers on teams with high AI adoption merged 98% more pull requests and completed 21% more tasks, while PR review time increased 91% and average PR size grew 154%. These are correlations from observational telemetry, not a controlled experiment. But they illustrate the underlying problem: more work can enter the engineering system while the human verification layer becomes more constrained. Read the Faros AI Productivity Paradox report. Faros followed that research with its 2026 Acceleration Whiplash report, based on two years of telemetry from 22,000 developers across 4,000 teams. Comparing periods of lowest and highest AI adoption within the same organizations, median time to first PR review rose 156.6%, average time spent in code review increased 199.6% and median time in review increased 441.5%. Pull requests merged without human or agentic review increased 31.3%. See the 2026 report and methodology. Those figures do not prove that AI caused every downstream change. They do show why developers are producing more and the organization understands more cannot be treated as the same metric. #### Faster coding can mean weaker understanding The most interesting evidence is not about pull-request volume. It is about what developers actually learn while using AI. In January 2026, Anthropic researchers published a randomized experiment involving developers learning an unfamiliar asynchronous programming library. The AI-assisted group averaged 50% on a later comprehension quiz, compared with 67% among participants who coded without AI assistance. The difference was statistically significant. The AI group finished only about two minutes faster on average, and that speed difference was not statistically significant. Anthropic published the study and methodology here. The conclusion is more nuanced than “AI makes developers worse programmers.” Researchers observed several interaction patterns. Participants who delegated most of the coding tended to learn less. People who used AI to ask conceptual questions, examine generated code or support their own reasoning retained more. The underlying paper discusses those interaction patterns in detail. That distinction matters. The problem is not AI assistance itself. It is delegation without comprehension. #### Productivity can feel higher even when it is not METR's 2025 randomized study offers another useful perspective. Sixteen experienced open-source maintainers completed 246 real tasks in repositories they already knew well. With AI tools available, they took 19% longer, even though they believed afterward that AI had made them around 20% faster. METR publishes the methodology and limitations here. The result should not be generalized to all developers or all AI tools. METR itself has been explicit about the narrow population involved. But it demonstrates something relevant to cognitive debt: felt productivity and verified understanding are not reliable substitutes for measurement. Producing the first answer may become easier. The cost can appear later, when somebody else has to review, debug, explain or extend it. #### Cognitive debt does not mean AI-generated code is bad code A team can accumulate cognitive debt around entirely human-written software. AI-generated software can also be clear, well tested and maintainable. The debt is not determined by authorship. It is determined by how much verified understanding remains around the system after the code is merged. That is why banning AI-generated code is not a serious cognitive-debt strategy. Neither is simply telling reviewers to “review harder.” The operational question is more useful: Can the people responsible for this system still explain and safely change what is being shipped? That question can be measured. #### How cognitive debt shows up in engineering teams You probably will not see a Jira ticket saying cognitive debt increased 14% during the sprint. The signals appear elsewhere. One warning sign is change volume rising faster than review capacity. Faros' telemetry makes that mismatch especially visible. Another is a growing number of changes merged without meaningful review. But some of the most expensive signals are organizational rather than quantitative. Architectural questions begin routing to the same senior engineer. Review comments spend more time reconstructing intent than examining implementation. New engineers become productive enough to ship code before they become independent enough to reason about the subsystem. AI tools repeatedly search the same repositories and rediscover relationships another session already found. Developers successfully ship code they struggle to explain several weeks later. None of those symptoms proves cognitive debt in isolation. Together, they tell you something important: implementation is moving faster than shared understanding. #### The missing engineering metric is verified understanding Engineering already has good delivery metrics. DORA gives teams measures around lead time, deployment frequency, change failure rate and recovery. Engineering organizations track cycle time, throughput, incidents and defects. What we do not have is an accepted equivalent for: How much of the system can the people responsible for it actually explain? That does not mean we need to invent a fake precision score. Useful proxies already exist. For meaningful AI-assisted changes, ask who could explain the implementation in a design review without reopening the original agent session. Track review effort relative to change volume. Watch the share of changes merged without review. Measure the bus factor of critical modules based not on who has committed code, but on who could safely make a difficult change. For context debt specifically, add another set of measurements: onboarding time to independence, senior-interrupt rate and time-to-answer for concrete questions about your own system. These measures do not create a perfect “debt score.” They tell you where your organization is paying the interest. #### From context debt to context maturity Context debt becomes easier to manage once knowledge stops being treated as either “documented” or “undocumented.” There are several levels between those two extremes. ##### Level 1: Knowledge lives in heads The system works because certain people know it. Questions route to names. Onboarding depends on availability. Incidents become easier when the right engineer joins the call. Typical symptom: “Ask Alex.” The main risk is obvious: the bus factor is dangerously low. ##### Level 2: Knowledge is written down The organization has wikis, runbooks and architecture diagrams. That is progress, but synchronization becomes the problem. The code changes continuously. Manually maintained descriptions change when someone remembers to update them. Typical symptom: “Check Confluence, but verify it with Sarah.” The risk is stale confidence. ##### Level 3: Knowledge is anchored to engineering artifacts Important rationale begins living in ADRs, pull-request discussions, code comments and decision records. The organization can reconstruct more than what the code does. It has evidence for why. Typical symptom: “We can usually find the decision if we know where to look.” Now the primary cost is discovery. ##### Level 4: Knowledge is queryable Engineers can ask structural questions about their own systems and receive answers grounded in the current codebase. Where is this implemented? Which services depend on it? Where is a similar pattern used? Which files are relevant? Answers point back to source rather than asking users to trust generated prose. Typical symptom: “Ask the system first. Escalate judgment questions to the owner.” ##### Level 5: Context behaves like infrastructure Current structural context is available to humans and AI tools. It can travel across IDEs, agents and engineering workflows instead of being reconstructed from scratch inside every session. People still own decisions. But routine system knowledge no longer disappears when the person who knows it logs off. Typical symptom: “Context follows the work.” At this level, the main problem shifts again. Retrieval is no longer the primary constraint. Governance becomes more important: deciding which context each person or agent should be allowed to access. #### Your context maturity is not your AI maturity A team can use sophisticated coding agents while its organizational context remains at Level 1. That creates a dangerous mismatch. Generation operates at one maturity level. Understanding and retrieval operate at another. You can test your own organization with a few simple questions. When an engineer asks how a service works, do they ask its owner, search documentation, inspect engineering artifacts or query maintained repository context? When code changes, does knowledge change in someone's head, eventually reach documentation or automatically become available through the systems people and AI already use? When the primary owner leaves, does work stall? And when an AI assistant answers a question about your software, can anyone verify where the answer came from? The goal is not to reach the highest level on every dimension. The goal is to know where your current bottleneck actually sits. #### Where Tentaro fits Tentaro operates around the transition from context stored in engineering artifacts to context that can be queried and reused. It does not attempt to manufacture reasoning that was never recorded. If an engineer chose Kafka over another system in 2022 because of a production constraint and nobody captured that decision, the code cannot reveal the complete hidden history with certainty. That boundary matters. What current repositories can tell you is where behavior lives, what depends on it, where similar implementations appear and which files are relevant to a question. Tentaro turns structural repository knowledge into grounded context that engineers and compatible AI assistants can query. Its product boundary separates context extraction from code generation. Tentaro supplies context to the tools engineers already use rather than trying to become another coding agent. Internally, Tentaro has been dogfooded across 100+ repositories built over 15 years of enterprise delivery. That matters because the difficult context problem is rarely one neat demo repository. It is retrieving useful context from long-lived software estates. #### Better documentation does not eliminate context debt Documentation remains important. But “write more docs” does not eliminate context debt if those documents become another source that needs continuous manual maintenance. Different kinds of knowledge need different sources. Let the code carry the current implementation. Let ADRs, pull requests and decision records preserve reasoning the implementation cannot reveal. Let people carry judgment, product knowledge and trade-off decisions. Then let a context layer handle retrieval. The goal is not to move every piece of engineering knowledge into a new database. It is to stop repeatedly spending senior engineering time on questions whose answers already exist somewhere in the engineering system. #### Context debt also has a direct AI cost Historically, much of the cost of missing context was hidden inside payroll. A senior engineer spends 30 minutes explaining an old subsystem and no separate invoice appears. AI changes that. When an AI system does not have the right context about your software, it has to reconstruct more of the problem during each interaction. It searches more files. Consumes more input. Repeats reasoning another session already performed. That makes token debt a useful way to think about one part of the interest on context debt. The price per token can fall while total context-related spend still grows if every useful answer requires increasingly large amounts of reconstruction. A bigger context window does not automatically solve that problem. The goal is not to send the model as much context as possible. It is to retrieve the smallest amount of correct, relevant and verifiable context needed for the task. #### The goal is not maximum understanding No engineer needs to understand every line of a large software estate. That was never realistic. The real target is sufficient distributed understanding for safe action. Someone working on a system should be able to identify the right implementation, trace important dependencies, understand current behavior and verify answers against source. They should also recognize where historical rationale is missing and know when expert judgment is required. That is a more realistic objective than universal expertise. It also gives us a useful relationship between the two concepts: Context debt falls when less engineering knowledge has to be reconstructed from scratch. Cognitive debt falls when more people can safely reason about and act on the system. One can influence the other. They are not the same thing. #### Run a Context Debt Audit before adding more agents Pick one system where AI-assisted development is already common. First, measure how quickly the implementation changes. Then measure how difficult it is to retrieve the context needed to understand those changes. How long does a concrete architectural question take to answer? How often does it require the same senior engineer? How long until a new engineer can work independently? How much reasoning has to be reconstructed from old commits, pull requests or conversations? Finally, ask how many people can independently explain recent changes well enough to modify them safely. If code generation is accelerating while context retrieval and shared understanding are not, adding more generation capacity may widen the gap rather than close it. Tentaro focuses on the part grounded in engineering artifacts: turning existing repository context into something humans and compatible AI systems can retrieve, query and verify. It cannot reconstruct reasoning that disappeared completely. But it can reduce how often your organization pays to rediscover knowledge it already has. #### FAQ ##### What is cognitive debt in software engineering? Cognitive debt is the growing gap between a software system's implementation and the team's shared understanding of how and why it works. Thoughtworks added codebase cognitive debt to its Technology Radar in April 2026 and highlighted rapid AI-assisted change as one factor that can increase the gap. See the Thoughtworks definition. ##### What is context debt? At Tentaro, context debt is a working term for the accumulated cost of engineering knowledge that exists, or once existed, but is not captured, connected or retrievable when people or AI systems need it. It is not currently a standardized engineering metric or universally agreed industry term. ##### What is the difference between cognitive debt and context debt? Cognitive debt is primarily a problem of human understanding. Context debt is a problem of knowledge availability and retrieval. Missing context can increase cognitive debt because engineers must repeatedly reconstruct the reasoning and relationships needed to understand a system. ##### What is the difference between cognitive debt and technical debt? Technical debt describes properties of software that make future changes harder. Cognitive debt describes insufficient shared understanding among the people responsible for that software. Well-written code can still carry cognitive debt if only a few people understand its structure or rationale. ##### Does AI cause cognitive debt? Not automatically. Cognitive debt existed before AI. AI can increase the rate at which software changes, creating a larger gap if review and understanding do not scale with it. Faros' observational studies found higher PR throughput alongside slower review under high AI adoption, while Anthropic's controlled study found that some AI interaction patterns weakened learning and others preserved it. Faros 2025 · Anthropic 2026 ##### How can you measure cognitive debt? There is no standardized metric. Useful indicators include review time relative to change volume, unreviewed merges, bus factor, reviewer concentration and the ability of engineers other than the original author to explain and safely modify recent changes. ##### How can you measure context debt? Useful proxies include onboarding time to independence, senior-interrupt rate, time-to-answer for questions about internal systems, bus factor on critical paths and the amount of engineering reasoning that must be reconstructed repeatedly. ##### Can documentation solve context debt? Documentation helps preserve architectural decisions and rationale, but manually maintained documentation can drift away from the implementation. A stronger model combines code-derived structural context, engineering artifacts such as ADRs and pull requests, and human judgment. ##### What is a context layer? A context layer retrieves organization-specific information and supplies it to people or AI systems when needed. In software engineering, that can include relevant files, implementations and dependencies grounded in private repositories instead of relying on a model's general knowledge. ##### How does Tentaro address context debt? Tentaro makes structural repository context queryable to engineers and compatible AI assistants. It can reduce the need to repeatedly reconstruct facts such as where logic lives, what depends on it and which files matter to a question while grounding answers in source. It cannot recover undocumented historical reasoning that no longer exists. --- # Blog: Context Engineering vs Prompt Engineering: What's the Difference? Source: https://www.tentaro.ai/blog/context-engineering-vs-prompt-engineering If an assistant knows the right code but returns it in the wrong format, you probably have a prompt problem. If it confidently recommends creating a service your company already has in another repository, rewriting the prompt won't fix the missing knowledge. You have a context problem. Anthropic describes context engineering as the set of strategies for curating and maintaining the information available to an LLM during inference. Its September 2025 engineering guide makes the core constraint explicit: context is finite, and more information isn't automatically better. Read Anthropic's guide to effective context engineering. For engineering teams, that gives us a useful rule: Prompt engineering tells the model what to do. Context engineering decides what the model knows when it does it. #### Where prompt engineering still matters Prompt engineering isn't obsolete. It's extremely useful when the model already has the information it needs and the problem is how it interprets or uses that information. Good prompts can clarify: - the task - expected format - constraints - available tools - sequence of work - what the model should do when uncertain GitHub's guidance for Copilot still treats custom instructions, reusable prompts and agent configuration as important ways to improve results. Its January 2026 article on context engineering describes instructions and reusable prompts as part of a larger system for supplying Copilot with the information and behavior a team wants. See GitHub's Want better AI outputs? Try context engineering. Prompting is particularly effective for requests such as: “Return a migration plan with risks before writing code.” “Use our API conventions.” “Don't change public interfaces.” “Explain every assumption you can't verify.” Those instructions shape behavior. But look at the second example: “Use our API conventions.” The prompt can request that behavior. It can't tell the model what your API conventions actually are unless those conventions are already present somewhere it can access. That's where prompting stops and context begins. #### The easiest diagnostic: ask what information is missing When a coding assistant gives a bad answer, teams often instinctively add more instructions. “Be more careful.” “Think step by step.” “Search the entire repository.” “Don't hallucinate.” Sometimes that helps. Sometimes it produces a more carefully written wrong answer. Before changing the prompt, ask: Could the model have produced the correct answer from the information it had? If yes, improve the prompt. If no, improve the context. That one question separates a surprising number of failures. #### DO YOU HAVE A PROMPT PROBLEM OR A CONTEXT PROBLEM? Failure signal Diagnosis What to fix The answer uses the wrong format. Prompt problem Specify the expected structure or schema. The assistant ignores a known constraint that was included in the prompt. Prompt / instruction problem Strengthen or restructure the instruction. The answer sounds plausible but references architecture that doesn't exist. Context problem The model lacks grounded system knowledge. The assistant proposes functionality already implemented elsewhere. Context problem It doesn't know enough of the codebase. The model finds the right implementation but misunderstands what you want changed. Prompt problem The source is present. The instruction is unclear. The answer is correct for last month's architecture but wrong today. Context freshness problem Your context exists but isn't current. Two engineers ask the same question and get materially different system answers. Context delivery problem The knowledge isn't being supplied consistently. The model receives dozens of files and performs worse. Context selection problem More context isn't necessarily better context. ##### Mostly prompt problems? Improve task instructions first. ##### Mostly context problems? Inspect where the model's system knowledge comes from. #### Context engineering isn't just filling the window A lot of writing about context engineering focuses on one session. Which files should you attach? What should you place first? When should you summarize the history? When should you start a fresh session? That work is real. GitHub's own January 2026 practical guidance recommends actively managing context windows, including starting new conversations when older context is no longer relevant. See GitHub's lessons from working with Copilot context windows. Anthropic goes further and frames context as a finite resource that agents need to curate continuously, deciding what information should remain immediately available and what can be retrieved later. The problem for an engineering organization is that session-level context disappears. An engineer finds six relevant files. They add an architecture note. They explain which service is authoritative. The model finally understands the problem. Session ends. Tomorrow another engineer asks a similar question and rebuilds nearly the same context from scratch. That repeated reconstruction is the structural weakness a durable context layer is meant to remove: useful system knowledge should not disappear with the session and have to be rebuilt manually tomorrow. That's the difference between context engineering as a technique and context as infrastructure. #### The durable version has four parts For code context to become reusable across a team, four questions need answers. ##### 1. Source: where does the context come from? Different sources answer different questions. Code tells you what the system currently does. ADRs and PRs can tell you why a decision was made. Documentation can explain concepts, processes and business meaning. Tickets show requested changes. People contribute judgment and history that nobody recorded. For structural questions about software, code is particularly important because it changes with the implementation. A diagram can become stale. The executing system can't quietly drift away from its own implementation. That doesn't make code sufficient for every question. It makes it the natural anchor for questions about current structure. ##### 2. Freshness: how does the context stay current? This is where many internal AI systems quietly fail. The company builds a beautiful knowledge index. Six months later, engineers no longer trust it. If context requires manual synchronization every time code moves, it inherits the same maintenance problem as a wiki attempting to mirror implementation. For code-derived context, the stronger model is incremental updates connected to repository changes. The question isn't: “Did we index our code?” It's: “How long after the code changes does the AI stop describing the old version?” ##### 3. Selection: how much of it reaches the model? A source can be present and current and still be unhelpful if the model receives too much of it. Selection is the retrieval problem: returning the four relevant files, not the forty related ones. The sections on context size and retrieval below explain why that selection step matters. ##### 4. Delivery: how does the context reach the model? A useful context layer shouldn't need a bespoke integration for every assistant an engineering team adopts. That is one reason MCP matters. The Model Context Protocol specification describes MCP as an open protocol for connecting LLM applications to external data sources and tools. The architectural idea is straightforward: context source → standard interface → whichever compatible assistant needs it That lets an organization invest in the knowledge layer rather than rebuilding integrations around every new model. #### More context isn't better context The instinct when an AI system doesn't know enough is to give it more. Bigger window. More files. Longer conversation. Entire repository. That strategy runs into two different constraints. The first is cost. Everything added to context has to be processed somehow. The second is reasoning quality. A 2025 controlled study across five open and closed models found that performance degraded as inputs became longer even when retrieval was perfect and all relevant evidence remained available. Depending on model and task, the measured degradation ranged from 13.9% to 85%. Read Context Length Alone Hurts LLM Performance Despite Perfect Retrieval. Software-engineering research published in February 2026 found a similar issue specifically in automated bug fixing. Successful agentic trajectories typically stayed below 20-30k tokens, while artificially expanding inputs to 64K–128K tokens caused sharp performance degradation even when the relevant files were guaranteed to be present. Read The Limits of Long-Context Reasoning in Automated Bug Fixing. That doesn't mean long contexts are useless. The practical lesson isn't “short context good, long context bad”. It's: Selection and retrieval matter more than maximum window size. The model needs enough context to solve the problem. Not every context you can possibly find. [IMAGE 3 HERE — Diagram: More context vs better context] #### Retrieval quality deserves its own engineering work Once context becomes dynamic, retrieval becomes part of product quality. It isn't enough for a system to “search the code”. It has to retrieve the right code. Anthropic's work on Contextual Retrieval demonstrates how much retrieval quality can matter. In its experiments, adding contextual information to embeddings and BM25 reduced failed retrievals by 49%. Adding reranking reduced them by 67%. Read Anthropic's Contextual Retrieval research. The useful principle is broader: retrieval is an optimization problem, not a checkbox. For code context, a retrieval system needs to answer questions such as: - What is actually relevant? - How much should be returned? - What happens when confidence is low? - Can the user verify the result? - Are cross-repository relationships included? - Does the answer still reflect the latest code? An important behavior is often overlooked: ##### What happens when nothing relevant exists? A system that always returns something can be more dangerous than one willing to say: “I don't have enough grounded context to answer.” Retrieval precision matters more than volume, and below a relevance threshold the useful answer can be nothing rather than a best guess. That's less impressive in a demo. It's considerably more useful in engineering work. #### Every model still needs organizational context Context engineering sometimes gets framed as a solution only for general-purpose frontier models. It isn't. Consider three paths. ##### Frontier model Very capable. No built-in knowledge of your private repositories. Needs current private context. ##### Small local model Cheaper and easier to keep inside controlled infrastructure. Usually has less general capability. Needs precise private context even more. ##### Fine-tuned model Can absorb organization-specific patterns during training. But training captures a state of the world. The change merged this morning wasn't part of yesterday's training data. A fine-tuned model can still need retrieval for fresh system state. Different models change how much reasoning capacity you have. They don't remove the need to supply current facts. #### Where Tentaro fits Tentaro is built around the durable version of context engineering. It isn't another prompt-management layer and it doesn't generate code itself. Tentaro indexes private code and turns it into grounded context that engineers and compatible AI assistants can retrieve when they need to understand the existing system. Its shipped product boundary includes code-context extraction and MCP delivery rather than code generation. That maps directly onto the Source–Freshness–Selection–Delivery model. ##### Source Private repositories provide the structural ground truth. ##### Freshness Tentaro supports incremental indexing, so changed code can be processed without rebuilding the entire repository index. ##### Selection Indexed code context can be retrieved when engineers or compatible assistants need it, rather than rebuilding the same context manually in every session. ##### Delivery Context can be exposed through MCP to compatible developer tools and assistants. The point isn't to replace Claude Code, Copilot, Cursor or whatever comes next. Coding agents are a channel for context, not necessarily the product Tentaro is trying to replace. That is strategically important because the agent market changes quickly. The codebase changes too. The organization should own the layer connecting the two. #### Prompt engineering and context engineering work together There is no sensible “prompt engineering is dead” conclusion here. A strong coding workflow needs both. Context engineering gives the model: the right information Prompt engineering tells it: what to do with that information Consider: “Find the implementation responsible for retry behavior, identify all downstream dependencies, then explain the risk of changing it. Cite the relevant source files and say when the available context isn't enough.” The instruction is prompt engineering. Retrieving the relevant implementation, dependencies and current code is context engineering. Remove either half and the result gets weaker. Good instructions over bad context produce articulate fiction. Excellent context under vague instructions can produce technically correct but unhelpful output. The best systems treat the two as separate engineering problems. [IMAGE 4 HERE — Decision card: Source → Freshness → Selection → Delivery → Prompt] #### Before rewriting your prompt, ask: ##### 1. Did the model have the necessary facts? No → Context problem ##### 2. Were those facts current? No → Freshness problem ##### 3. Were the relevant facts selected rather than buried in noise? No → Selection problem ##### 4. Did the same context reach the model consistently? No → Delivery problem ##### 5. Did the model misunderstand what it should do with good context? Yes → Prompt problem Bottom: Fix the first failing layer, not the easiest layer to edit. #### Context engineering becomes infrastructure when teams stop rebuilding it The biggest shift isn't from prompts to context. It's from personal context assembly to organizational context infrastructure. If every developer creates their own collection of files, instructions and explanations, the organization hasn't solved context engineering. It has distributed the work of rebuilding context to every employee. A durable system should answer: - Where does the information come from? - How do we know it's current? - How is relevance determined? - How does the model receive it? - Can the user verify the sources? - What happens when the answer isn't known? Once those questions have shared answers, context stops being a clever trick inside one chat session. It becomes something the engineering organization owns. #### Before you rewrite the prompt again, test the context Pick one question your developers regularly ask an AI coding assistant. Run the Source–Freshness–Selection–Delivery test: SOURCE → Does the answer exist somewhere the model can access? FRESHNESS → Does that source reflect the current implementation? SELECTION → Will the model receive the relevant context without burying it in noise? DELIVERY → Will the relevant context reliably reach whichever assistant the engineer uses? If any answer is “no”, another line of prompt engineering probably isn't your highest-leverage fix. Tentaro is designed for that layer: private code becomes grounded, current context that can be delivered to compatible AI tools through MCP, while your existing assistants continue handling generation and reasoning. --- # Blog: When You Inherit a Codebase Nobody Can Explain… Source: https://www.tentaro.ai/blog/inheriting-a-codebase Technical due diligence can tell you a great deal about a software asset before an acquisition. It can evaluate architecture, infrastructure, security, product quality, technical processes and the engineering team itself. Snyk describes technical due diligence as an assessment of products, infrastructure, architecture, roadmap, services, practices and IT staff, usually performed around events such as M&A or investment. What it can't do is transfer understanding. The transaction closes. Someone now owns the repositories. Someone has to change the system on Monday, answer an auditor on Tuesday and debug it at 2 a.m. three months later. The diligence report described the asset. It didn't upload the previous team's mental model into yours. That gap is where post-acquisition engineering risk starts. #### Technical due diligence and technical ownership solve different problems A good diligence process should absolutely examine the codebase. Modern software due-diligence guidance typically covers architecture, infrastructure, security, IP and licensing, documentation, delivery processes and team capability. MadeWithLove makes the distinction particularly clearly: a code audit focuses on code, while technical due diligence evaluates the broader technical operation. Its 2026 guide breaks down the difference here. M&A advisers also increasingly treat key-person dependency as part of the risk picture. L40's 2026 M&A technology checklist includes dependence on a handful of individuals among the questions that can affect the investment thesis and post-deal execution. See its technology due-diligence checklist. But diligence has a natural boundary. It can tell you: “This service has poor test coverage.” It may not tell you: “The team stopped investing in those tests because the payment provider's sandbox behaved differently from production and every attempted rewrite created false confidence.” It can tell you: “These services communicate over a message queue.” It may not tell you: “The queue exists because a synchronous integration caused a production incident four years ago and nobody ever revisited the trade-off.” The first category is visible in systems and artifacts. The second often exists in history, conversations and people's heads. That's the knowledge you discover you bought only after some of it has already left. #### Three ways engineering teams inherit code they don't understand An acquisition is only one version of the problem. ##### #1 An acquisition closes The buyer inherits repositories created under conventions, constraints and business assumptions its engineers weren't present for. The code may be perfectly functional. The problem is that the new team can't yet distinguish deliberate design from historical accident. ##### #2 A new CTO or engineering leader arrives No repositories changed hands. Accountability did. The new leader is responsible for systems they haven't had time to internalize. Every architecture question initially flows downward to people who may themselves hold only fragments of the answer. ##### #3 A key engineer leaves No M&A process. No diligence room. The billing service is still there on Monday. The person who knew which part not to touch isn't. Different trigger, same underlying condition: a production system exists and the people now accountable for it can't yet answer basic operational questions without outside help. #### The first mistake is trying to understand everything The goal of the first month isn't mastery. That is impossible for a large inherited estate and usually counterproductive. The goal is to establish where ignorance creates risk. You need to know: - which systems have concentrated ownership - which critical areas no longer have an active owner - where documentation diverges from code - which architectural decisions carry large blast radius - which external dependencies have no current internal expert - which questions the new team simply can't answer That gives you a risk map. Without one, inherited-codebase work tends to follow curiosity: engineers explore the systems that are easiest or most interesting to understand first. Operational risk rarely follows the same order. #### How risky is the codebase you inherited? Pick one critical system, not the entire estate. ##### 1. Active ownership 0 points: multiple current engineers can change it 1 point: one clear owner plus a credible backup 2 points: one owner only 3 points: no current owner ##### 2. Knowledge concentration 0: system knowledge is distributed 1: some questions route repeatedly to one person 2: most non-trivial questions route to one person 3: the knowledgeable person is no longer available ##### 3. Documentation trust 0: docs are current and verified 1: mostly current 2: engineers regularly say “check the code instead” 3: nobody trusts the docs ##### 4. Architecture confidence 0: diagrams match current call paths 1: small differences 2: major unknowns 3: nobody can explain the real runtime architecture ##### 5. External dependency ownership 0: services, licenses and integrations have named owners 1: minor gaps 2: several unclear dependencies 3: critical jobs/services have no internal expert ##### 6. Safe-change ability Ask: Could someone on the current team ship a meaningful change to this system this week without help from the previous owner? 0: yes 1: probably 2: only with significant delay 3: no #### Result 0–4 — Operationally understood Normal transition work. 5–8 — Knowledge gaps Prioritize the exposed areas. 9–13 — High transition risk Treat knowledge recovery as roadmap work. 14–18 — Critical Avoid unnecessary structural change until the team can explain the system. CTA: ##### Map the top three exposed systems → Implementation note: calculate instantly. No email gate before the result. #### Your first 30 days: build an exposure map before an integration plan The first month should produce one outcome: a ranked list of systems the new organization can and can't safely change. Not a prettier architecture deck. Not a migration wishlist. A usable exposure map. ##### Days 1–3: map ownership concentration Start with repository history. For each critical subsystem, identify: - meaningful contributors - current employees - frequent reviewers - last substantial change - likely backup owners Don't equate commit count with knowledge. Research into bus factor shows why. A 2022 study of 269 engineers found that version-control history misses other important channels through which engineering knowledge is distributed. The researchers improved bus-factor estimation by including code-review and communication data alongside VCS information. Read Bus Factor In Practice. So the ownership question isn't: Who committed most? It's: Who can explain and safely change this now? ###### Days 1–3 deliverable Create an initial list: System Primary knowledge owner Still available? Backup? Confidence Any critical system with no available owner moves immediately into the exposure queue. ##### Days 4–7: identify orphaned systems and question routes For a week, capture unresolved questions. Not every Slack message. Only questions that reveal missing system context: - Where is this behavior implemented? - Why does this retry? - Who owns this scheduled job? - Can we remove this queue? - What calls this service? - Why does the schema look like this? - Which repository is authoritative? - What happens if this dependency disappears? Track where each question goes. If every difficult question routes to one former employee, contractor or overworked remaining engineer, you've found the real ownership map. This is the same problem bus-factor research tries to capture: project resilience depends on the distribution of knowledge, not simply the number of contributors. A 2016 study of 133 popular GitHub projects found that 65% had an estimated truck factor of two or lower, though the authors also stressed there's no universally accepted way to calculate the metric. See A Novel Approach for Estimating Truck Factors. On top of the above, you also need to plan the following steps: #### Week 1: inventory the things that aren't obvious from the repository tree Inherited systems often fail around their edges. Look for: - SaaS integrations - scheduled jobs - certificates - license servers - infrastructure scripts - service accounts - deployment credentials - manual production procedures - external APIs - data pipelines - old cron jobs - third-party libraries with special constraints Technical due diligence commonly includes infrastructure, security, licensing and third-party exposure precisely because software isn't only application code. Snyk's technical due-diligence overview lists infrastructure, architecture, products and practices among the areas under review. Post-close, though, you need an additional field: Who internally understands this dependency now? A perfectly documented vendor contract doesn't help much during an outage if nobody knows which production path still depends on the service. #### Week 2: reconstruct the decisions with the largest blast radius Don't try to reconstruct every historical decision. Pick five. Choose decisions where getting the rationale wrong could make future work expensive or dangerous: - database architecture - eventing model - authentication - tenancy - deployment topology - synchronization strategy - integration boundaries - data ownership For each decision, ask: - What exists now? - What alternatives were considered? - Why did the current design win? - Which constraint was decisive? - Is that constraint still true? - What evidence survives? Look in: - ADRs - old PRs - issues - commit messages - incident reports - meeting notes - archived chats - people who worked around the system If you can't find the rationale, mark it unknown. Don't reverse-engineer a plausible story and quietly turn it into fact. That distinction becomes especially important with AI. A model can generate a convincing reason why a queue, retry or abstraction exists. Convincing isn't the same as historically correct. #### Weeks 3–4: test the handover with work, not meetings A transition isn't complete because: - the previous team ran six walkthroughs - Confluence has 42 pages - the new owner attended every session - somebody recorded the calls Give the new owner a meaningful change. Not a typo. Something requiring them to: - identify the implementation - trace relevant dependencies - understand likely blast radius - decide what needs testing - make the change - explain it in review Then count the external dependencies on knowledge. How many times did they need someone from the previous team? How many answers came from unverifiable memory? Which questions couldn't be answered at all? That's your remaining transition backlog. #### Why handover sessions underperform Handover sessions aren't useless. The problem is timing. A person receiving a subsystem walkthrough on day three often doesn't yet know enough to understand which parts of the explanation will matter on day thirty. The source expert says: “Don't change that mapper unless you also update the reconciliation path.” The receiver records the sentence. Six weeks later they encounter the mapper and no longer remember what “the reconciliation path” referred to. Knowledge was transferred. Context wasn't. That is why queryable, source-linked knowledge can be more useful than bulk knowledge transfer for structural questions. The answer becomes available at the moment the engineer has enough context to ask the right question. But there is a boundary. A codebase can reveal current structure. It can't recover an unrecorded conversation from four years ago. #### AI makes inherited-code archaeology faster and more dangerous at the same time AI assistants are naturally useful in an unfamiliar codebase. They can help: - find usages - summarize files - trace call paths - identify related implementations - explain language or framework patterns - search large repository estates Those are exactly the kinds of tasks that consume the early weeks of inherited-code work. The danger appears when the model moves from: “Here's what the repository shows.” to: “Here's why the previous team designed it this way.” without evidence. Birgitta Böckeler has made a related point in the context of coding assistants and pair programming: LLMs don't automatically contain the tacit history of a codebase that human collaboration distributes through a team. Her discussion of coding assistants and shared codebase knowledge is here. For inherited software, the distinction is critical. ##### AI is strong at reconstructing structure Examples: - Where is PaymentRetryPolicy used? - Which service owns this database table? - What calls this endpoint? - Where else do we implement the same validation? - Which repository contains the producer for this event? ##### AI needs evidence for intent Examples: - Why was this timeout chosen? - Why did the team reject the obvious alternative? - Why is the deployment split across two clusters? - Why is this duplicated instead of shared? If the answer isn't recorded anywhere, the correct result is unknown. Not a better hallucination. #### Where Tentaro fits into inherited-code work Tentaro is useful on the structural side of that boundary. It indexes private repositories and turns them into grounded, queryable code context for engineers and compatible AI assistants. Its product boundary is explicitly context rather than code generation: it helps answer what exists, where it lives and how code relates without pretending to manufacture undocumented rationale. That matters particularly in inherited software because the first problem is often scale. The new engineer doesn't know: - which repository contains the implementation - which of three similarly named services is active - what depends on a component - where equivalent logic already exists - which files they should read before making a change Tentaro's internal dogfooding spans 100+ repositories built over 15 years of enterprise delivery, which makes the multi-repository problem more representative of the environment the product was built around than a single clean demo repo. The useful workflow looks like: question → grounded structural context → source references → engineer verifies → judgment not: question → plausible generated explanation → trust Most post-acquisition plans naturally become system plans: - migrate application A - consolidate database B - deprecate platform C - merge CI pipelines - move identity - standardize observability Those steps may all be right. But before sequencing by architectural convenience, overlay understanding risk. Imagine two systems: ##### System A Ugly architecture. Three current engineers understand it deeply. Strong tests. Clear operational ownership. ##### System B Cleaner architecture. Original owner gone. Docs unreliable. Nobody has changed it since acquisition. Which one should you restructure or migrate first? Probably not B. The condition of the code and the condition of the organization's understanding are different variables. Your integration plan should account for both. #### Integration readiness check Before scheduling a major change to an inherited system, can the current team answer: - Who owns it? - Who is the backup owner? - Where is the authoritative implementation? - What are its upstream dependencies? - What depends on it downstream? - How is it deployed? - How is it monitored? - Which external services does it require? - What is the rollback path? - Which major architectural decisions are understood? - Which decisions are explicitly still unknown? - Could someone other than the owner review a risky change? 10–12 checked: reasonable integration readiness 7–9: close gaps before major restructuring 4–6: high transition risk 0–3: learn before you migrate CTA: Run this against your riskiest inherited system #### The exit criterion for a codebase transition A transition needs a finish line. “Documentation delivered” isn't one. “KT complete” isn't one either. Use something operational. For example: The receiving team can answer and verify normal structural questions, change the system safely and operate it without relying on unavailable members of the previous organization. That doesn't mean every historical decision has been recovered. Some won't be. The point is to know where uncertainty remains and make it explicit. A mature transition produces three categories: ##### KNOWN We can answer and verify it. ##### RECOVERABLE We don't know yet, but the evidence exists. ##### LOST / UNKNOWN The rationale wasn't recorded or is no longer available. The dangerous category isn't “unknown”. It's unknown presented as known. #### A 30-day inherited-codebase checklist ##### Days 1–3 → Exposure - inventory critical repositories and systems - identify current meaningful contributors - identify departed owners - flag systems without backup ownership - freeze avoidable changes in critical unknown areas ##### Days 4–7 → Reality check - log unanswered engineering questions - validate sample architecture paths against code - inventory external dependencies - identify stale or untrusted documentation - rank systems by operational exposure ##### Week 2 → Recover - reconstruct five highest-risk decisions - capture evidence for each - label missing rationale explicitly - assign provisional owners - identify available previous-team knowledge paths ##### Week 3 → Make context usable - make structural repository knowledge searchable - connect decisions to relevant engineering artifacts - centralize system-specific unknowns - identify repeated questions that don't need human judgment ##### Week 4 → Test - give the new owner a real change - observe where they get blocked - verify their architectural assumptions - close remaining critical gaps - establish the next-quarter ownership plan #### Don't start with the whole acquired codebase Pick the system that creates the most hesitation. The one where engineers say: “We should probably wait until someone from the old team is available.” Bring that system into an onboarding teardown. The goal isn't a generic audit report. It's to expose what the new team can answer, what the repositories can recover and where the remaining knowledge risk lives. --- # Blog: Introducing Tentaro. Source: https://www.tentaro.ai/blog/introducing-tentaro For the past year, every time we showed CodeQA to someone, we spent the first few minutes explaining what it's not. Not a code generator. Not a QA tool. Not another Copilot. That's a sign the name was doing the wrong job. Today, we're excited to announce our new name: Tentaro. #### The naming journey CodeQA made sense when we started. We were building search for code, and "QA" nodded to questions and answers But the name kept pulling people toward the wrong mental model: testing, quality assurance, another checkbox tool in the CI pipeline. That's not what we do. We never generated a single line of code, and we never ran a single test. We index. We search. We explain. Many demos started with a correction instead of a conversation. So we went back to what the product actually does: it gives AI, and the humans using it, the context they're missing about a codebase. The new name carries a story. Picture a traveler crossing a dark forest at night. When they need it, they return to the camp: warmth, safety, people who share what they know. A stop. A moment of understanding. Then the journey goes on. Tentaro is that camp, and the guide who remembers the way. A name that says what we are - Tentaro. The name is built from three pieces. Tent: shelter, the base you come back to. Tarō: Japanese for the one who goes first - a guide. Tentare: Latin for to try, to explore. It sounds like a person's name, and that is on purpose - the product works like a colleague who remembers, not like another tool in the pipeline. And it doesn't compete for the same shelf as Copilot or Cursor, because we're not on that shelf. We're the layer underneath them. #### What Tentaro is Your team already has tools that write code: Copilot, Cursor, Claude. They're genuinely useful. But every one of them is only as smart as the context it's handed, and most of the time, that context is missing. They see the file that's open. They don't know your platform's history, conventions, or how its pieces connect across repositories. Tentaro is that context. We give your team, and your AI assistants, the real picture of your codebase: the what, and the why. Every answer comes straight from your own repositories, including the code that never leaves your infrastructure. Not a coding assistant. A context platform. What is Tentaro? #### The road ahead Search was step one. Tentaro already runs on-premise, searches across multi-repo codebases, and plugs into Claude through an MCP server, no separate UI required. We added voice-to-text search, so developers can just ask a question out loud and get the context back, without breaking their flow to type it out. The next problem is bigger: helping teams reason about impact, not just retrieve a file, turning every question a developer asks into context-aware intelligence, not just a pointer to a relevant snippet. We're focused on deepening that core experience before we chase anything new: better coverage across sprawling multi-repo setups, and tighter integration with the tools developers already use. The same shift is coming for agents. As coding agents move from suggesting lines to running autonomously across a codebase, the cost of missing context stops being an inconvenience and becomes a risk: an agent acting on the wrong assumption doesn't just slow someone down, it ships. Tentaro is built to be the context layer those agents call on before they act, not after something breaks. That's the direction we're building toward. Sharper name, sharper focus on what we're actually solving. #### Thank you To everyone who used CodeQA, asked hard questions in demos, and pushed back when something didn't quite fit: thank you. You're the reason the name changed and the product didn't have to. Every demo - Tentaro Same product you've come to know. New name that finally says what it does. Welcome to Tentaro. Get in touch: tentaro.ai · Try a demo #announcement #rebrand --- # Blog: On-premises AI coding tools - safeguarding data privacy in software development. Source: https://www.tentaro.ai/blog/on-premises-ai-tools-support-data-privacy #### Why privacy and security matter in AI-powered development As enterprises increasingly adopt AI to automate code reviews, testing, and vulnerability scanning, ensuring data privacy becomes paramount. Cloud-based AI tools may expose sensitive source code, customer data, or intellectual property to external risks. By contrast, on-premise AI tools allow organizations to keep data within their controlled environments by aligning with data sovereignty and compliance requirements like GDPR and CCPA. > According to Gartner, by 2026, 75% of organizations will demand AI solutions that guarantee strong data residency and compliance assurances. ##### What are on-premises AI tools for software development? On-premises AI tools are artificial intelligence solutions that are deployed and operated within an organization’s own infrastructure, rather than relying on external cloud services. In the context of software development, on-premises AI allows teams to leverage advanced AI capabilities such as code analysis, automated testing, and security scanning while keeping all data and processes within their own controlled environment. Core components of on-premises AI infrastructure include: - hardware: servers, GPUs, and storage devices physically located on-site or in a private data center - software: AI models, orchestration tools, and management platforms installed and maintained by the organization - security measures: firewalls, access controls, and monitoring systems tailored to the organization’s specific needs. Examples of on-premises AI tools in software development: - AI-powered code review platforms installed on internal servers - automated vulnerability scanners running within the company’s network - machine learning models for test automation, hosted locally. Primary connection to data privacy: on-premise AI ensures that sensitive code, intellectual property, and customer data never leave the organization’s boundaries, giving teams full control over where and how their data is stored and processed. Key characteristics of on-premises AI: - full control: organizations own and manage the entire AI infrastructure, including hardware and software - data locality: all data remains within the organization’s physical or virtual boundaries, reducing exposure to external threats - customization: security protocols and configurations can be tailored to meet specific regulatory or business requirements. ##### Cloud vs on-premises AI - key differences for privacy control When evaluating AI deployment options, privacy is a critical factor for software development teams. Here’s a comparison focused on privacy aspects: Feature Cloud AI On-Premise AI Data storage location Off-site, managed by third-party provider On-site, within organization’s infrastructure Control over security Limited to provider’s protocols Full control, customizable by organization Compliance capabilities May be limited by provider’s certifications Tailored to meet specific regulations Third-party access Provider staff may have access No external access unless explicitly allowed Data transmission risks Data travels over the internet Data stays within internal network For enterprise development, these aren’t theoretical differences, they define your risk surface. Why these differences matter for software development: - handling proprietary code or sensitive customer data often requires strict privacy controls - on-premises AI minimizes the risk of data leaks during transmission or from third-party access - regulatory compliance is easier to demonstrate when data never leaves your infrastructure. ###### Why it matters for developers If you work with proprietary code, regulated data, or customer IP, privacy isn’t negotiable. Every commit, every build artifact, and every log line can contain sensitive information. On-premises AI minimizes the risk of data leaks, not only from malicious actors but from simple misconfigurations or API exposure. It also makes compliance simpler, when data never leaves your network, audit trails write themselves. In regulated industries, “secure by design” isn’t optional - it’s the only way you’re allowed to operate. ##### Top security and compliance benefits of on-premises AI ###### Data sovereignty - your data, your jurisdiction One of the biggest advantages of on-premises AI is data sovereignty - keeping your data subject only to the laws of the country where it physically resides. When repositories, test data, and build artifacts stay inside your infrastructure, you maintain full legal and operational control. That’s a major advantage in regions like the EU, where data residency rules are strict. There’s no uncertainty about where your code is stored or who has the legal authority to access it. Your data, your infrastructure, your rules. ###### Encryption and access control - security you design In the cloud, encryption and access policies are pre-defined. You trust the provider’s key management. With on-premises AI, you manage everything - encryption standards, key rotation, and access logic. You can enforce role-based access control (RBAC) to limit exposure: - developers → read/write code - testers → read-only - admins → full control This simple model - least privilege - prevents 90% of internal data risks. It also lets you integrate directly with your existing stack: SSO, audit logs, and centralized security management. ###### Regulatory alignment - building for audits, not against them Auditors don’t care about marketing promises. They care about proof - who accessed what, when, and where the data resides. On-premises AI makes this straightforward. You own every event log, audit trail, and retention policy. That aligns perfectly with frameworks like: - ISO/IEC 27001 (ISO.org) - SOC 2 (AICPA) - NIST Cybersecurity Framework (CSF) (NIST.gov). For development teams, that means faster audits and cleaner documentation - because every control lives inside your environment. ##### Common privacy risks in software development I’ve seen teams underestimate how easily sensitive data can leak through daily workflows. Common pitfalls include: - proprietary code exposure - snippets sent to external APIs - test data leaks - real customer data reused in QA - intellectual property risks - cloud tools retaining or analyzing your code - pipeline vulnerabilities - third-party integrations introducing attack vectors. The consequences are data breaches, compliance fines, loss of competitive edge, and broken trust. On-premises AI addresses these by keeping everything - data, models, and analytics - inside your trusted perimeter. ##### Practical steps to reduce data exposure ###### Role-based access controls Define clear roles (developer, tester, admin). Apply the principle of least privilege and audit permissions regularly. Access creep is real - and it’s often where incidents begin. ###### End-to-end encryption Encrypt data both at rest and in transit. Use AES-256 for code repositories, for stored data and TLS for network traffic. Rotate keys. Never hard-code them. Treat encryption like part of your build pipeline hygiene. ###### Regular security audits Run quarterly audits covering infrastructure, access logs, and dependencies. Include penetration testing and document every remediation. Auditing isn’t bureaucracy - it’s learning. ##### Challenges to consider when deploying on-premises AI On-premises AI isn’t plug-and-play. It has real challenges - but all can be managed with the right mindset. - Hardware costs - start with scalable GPUs, expand as usage grows. - Technical expertise - train your engineers or partner with managed service providers. - Performance - use containerization (Docker, Kubernetes) for elasticity. - Setup time - automate deployments with templates and IaC tools. The key is not to treat on-premises as “legacy.” With modern DevOps, it’s just as dynamic as cloud - only safer. ##### Integrating on-premises AI into existing DevOps pipelines ###### Containerization We package AI tools into containers - lightweight, portable, reproducible. Kubernetes orchestrates them, ensuring uptime and isolation. Each container is sandboxed, with strict network policies to prevent data spillage. ###### CI/CD Integration Our typical pipeline looks like this: Commit → Build → AI Code Analysis → Automated Tests → Deploy All steps run locally or within the internal network. No data leaves the environment - ever. ###### Monitoring and Alerting We monitor resource usage, model performance, and access logs. Anomalies trigger alerts immediately. Security isn’t static - it’s observability in motion. ##### Is on-premises AI right for your team? Ask yourself - Do you handle sensitive or regulated data? - Is data residency legally required? - Do you want full control over compliance? - Are you concerned about third-party access? If yes, on-premises AI isn’t overkill — it’s common sense. For many teams, a hybrid approach works best: use on-premises AI for critical workloads and cloud AI for less sensitive ones. The ROI becomes clear when you compare it to the cost of data breaches, compliance fines, and vendor lock-in. ##### Building secure foundations for AI & data privacy AI will continue reshaping how we build and ship software. But one thing won’t change: ###### trust is non-negotiable. When your code, documentation, and internal knowledge remain under your control, you move fast and stay compliant. That’s exactly the balance we aim for with Tentaro - an on-premises AI assistant that helps teams search, analyze, and understand their codebases without sending a single line of proprietary code outside. If your organization values privacy as much as innovation, it might be time to explore this path. Try demo and see how on-premises AI can make your development process both intelligent and secure. --- # Blog: Tribal Knowledge in Software Engineering Source: https://www.tentaro.ai/blog/tribal-knowledge-in-software-engineering Tribal knowledge is the part of a software system that exists only in conversation and memory. It's why one engineer knows not to change a harmless-looking timeout. It's the abandoned implementation that isn't mentioned in the README. It's the production failure everyone remembers but nobody wrote down. It's the answer to “why does this work this way?” when the repository can only tell you what is there. That knowledge isn't unusual. Even disciplined engineering organizations create information faster than they can formally document it. The problem starts when important context remains concentrated in a few people and the rest of the team has no reliable way to recover it. Google's SRE organization has described documentation partly in these terms: operational documents help capture tribal knowledge so it becomes discoverable, searchable and maintainable rather than remaining dependent on individual memory. ACM Queue's Why SRE Documents Matter explains the role of documentation in preserving that knowledge. The goal, though, isn't to write everything down. It's to identify which knowledge becomes dangerous when it stays conversational and give it somewhere better to live. #### What tribal knowledge looks like from inside a team The signals are social before they're technical. There's one person everyone messages before touching billing. A two-line PR objection turns into a history lesson because the reviewer has to explain a decision made four years ago. New engineers reach a point where the remaining questions are all versions of: “Why does this work this way?” and none of the answers are written anywhere. The person at the center usually doesn't experience this as prestige. They experience interruptions. A developer asks about a queue. Someone else wants a review. An AI assistant produced a plausible explanation of a legacy module and somebody needs to confirm if it's true. Then an incident starts and three people need the same person's context at once. They have become the team's living FAQ. That creates a strange incentive. Their knowledge is part of what makes them valuable. At the same time, the concentration of that knowledge prevents them from spending their time on higher-leverage work. So the goal can't be: “Make the expert less important.” It should be: “Stop making the expert the default interface for information that doesn't require their judgment.” #### Why the wiki didn't fix it Documentation isn't useless. The problem is that different kinds of knowledge decay at different speeds. A page describing the current architecture might become inaccurate after the next sprint. A decision explaining that the team introduced asynchronous processing after a specific synchronous failure can remain useful for years. Knowledge that survives in writing tends to be the knowledge that changes least, especially decisions and reasoning, while documentation that attempts to mirror the current implementation can drift quickly. That suggests a better split. ##### Don't manually document what the code can answer Examples: - where a service lives - which files implement a feature - what calls an endpoint - where a type is used - which repository contains similar logic Those facts change with the code. If people have to update a wiki after every structural change, the wiki is competing with the development process. Eventually it loses. ##### Do record what the code can't infer Examples: - why a design was chosen - which alternatives were rejected - what production failure changed the architecture - which business constraint shaped the implementation - what trade-off the team knowingly accepted Martin Fowler's 2026 description of an Architecture Decision Record makes the same distinction. An ADR captures one significant decision, its context and its consequences rather than trying to duplicate the implementation itself. See Fowler's ADR overview. This gives us a practical rule: Let code describe structure. Let decision records preserve intent. #### AI made tribal knowledge more visible, not less important It's tempting to assume that AI assistants solve tribal knowledge because engineers can ask questions instead of asking colleagues. They can help. But only if the assistant has a reliable source for the answer. Understanding an unfamiliar codebase remains difficult even with LLM support. A 2025 human-AI codebase-comprehension study notes that developers still struggle to achieve adequate understanding of large unfamiliar systems under time pressure, including when using LLMs. The research focuses specifically on codebase understanding with human-AI collaboration. Recent onboarding research makes the same problem visible from another direction. A 2026 paper on expert mentoring describes expert walkthroughs as valuable for transferring tacit knowledge and helping newcomers navigate codebases, while also noting that this form of support is expensive and repetitive. Its proposed system captures expert mentoring into reusable code tours rather than requiring the same expert explanation every time. See the LACY research. AI therefore creates two possible outcomes. ##### Outcome 1: expertise becomes reusable An assistant retrieves grounded information, points engineers to relevant source and allows routine questions to stop interrupting the expert. ##### Outcome 2: missing knowledge gets filled with plausible text The system owner isn't available. Someone asks why the module behaves a certain way. The assistant produces a convincing explanation. Nobody knows enough to correct it. That is more dangerous than simply getting “I don't know”. Concentration of knowledge used to make organizations slow; when AI can answer confidently without the missing owner, it can also make missing knowledge unverified. #### The goal isn't to capture everything A “document everything before it walks out the door” program will fail. There is too much information. Most of it isn't equally valuable. Start with knowledge carrying one of three forms of risk. ##### 1. Decisions Ask: - Why is the system shaped this way? - Which alternative looked attractive but failed? - Which constraint made the current design necessary? - What would you reconsider if that constraint disappeared? ##### 2. Failure history Ask: - What has broken here before? - Which failure isn't obvious from the tests? - What looked safe and wasn't? - Which “temporary” workaround became permanent? ##### 3. Hidden dependencies Ask: - What looks local but affects another system? - Which third-party dependency surprises new engineers? - Which change requires coordination outside this repository? - Where are the operational assumptions that aren't visible in the call path? Those three categories are more useful than asking: “Can you document the billing system?” The first produces decisions. The second usually produces a document nobody can finish. #### TRIBAL KNOWLEDGE INTERVIEW KIT Don't ask the expert to “walk you through the system”. Use these questions instead. ##### Decisions - What are the three decisions a new owner is most likely to misunderstand? - What alternative did the team seriously consider? - Why did you reject it? - Which constraint shaped the current implementation? - Is that constraint still true today? ##### Failures - What has failed in a way the tests wouldn't have predicted? - What looks strange because of a past incident? - Which component would you be nervous about changing without context? - What workaround became part of normal production behavior? ##### Dependencies - What looks independent but isn't? - Which downstream consumer is easiest to forget? - Which external service has unusual behavior? - What breaks outside this repository when this changes? ##### Human routing - What questions do people ask you every week? - Which of them could be answered from code? - Which require historical context? - Which genuinely require your judgment? ##### Final question If you disappeared tomorrow, what would the team confidently get wrong? #### Record the interview, but don't stop at the transcript Structured expert interviews are better than broad subsystem monologues. A transcript preserves more detail than someone's summary written afterward. But a two-hour transcript isn't a knowledge system. Nobody wants to search 19 pages of conversation during an incident. After the interview, you or AI can extract only the durable pieces. ##### Decision What did we decide? ##### Context What problem or constraint existed? ##### Alternatives What else did we consider? ##### Reason Why did the current option win? ##### Consequence What becomes risky if someone changes it casually? ##### Evidence Where can the next engineer verify this? That last field matters. The more knowledge can point back toward code, incident reports, issues or PRs, the less it depends on somebody trusting another piece of prose. #### Write decisions where engineers will find them An ADR doesn't need a heavyweight governance process. Fowler recommends keeping ADRs short, focused on one decision and linked rather than rewriting old decisions when circumstances change. Location matters as much as format. If a decision concerns the code, keeping the record close to engineering artifacts has several advantages: - it can be reviewed with the work - links survive team changes - engineers don't need to know which wiki space contains the answer - future tooling can retrieve the decision alongside the implementation Broader work on infrastructure platforms also describes ADRs as a lightweight mechanism for leaving future teams clues about why a system became what it is. See Building Infrastructure Platforms. The important thing isn't .md versus Notion versus an ADR tool. It's that the answer survives the person who originally knew it. #### Extract structure from the source instead of interviewing people about it There's a second category of knowledge we shouldn't ask senior engineers to document manually at all. “What calls this?” “Where is this pattern used?” “Which repository owns this behavior?” “What depends on this interface?” Those are repository questions. The code should answer them. This is the split behind Tentaro's role in the workflow. The existing product boundary is context extraction rather than code generation: Tentaro indexes code and delivers grounded context to engineers and compatible AI assistants, so structural questions can point back to source instead of depending on a person's availability. Tentaro's internal product materials likewise define shipped capabilities around code-context extraction, MCP delivery and grounded source context rather than automatic reconstruction of undocumented rationale. The distinction matters enough to repeat: Structure can be extracted. Intent has to survive somewhere. If nobody ever recorded why the team rejected an alternative architecture, no retrieval system should pretend it knows. #### A 30-day tribal knowledge capture plan You don't need to launch a company-wide program. Pick the two systems with the highest concentration risk. Identify concentration, interview the bottlenecks, make structural code knowledge answerable and then test the result on someone else. Here's the expanded version. ##### Week 1: find the human APIs Look for: - repeated questions to one person - repeated review requests - systems with one credible explainer - dependencies only one person knows - new engineers repeatedly blocked in the same places Don't duplicate the entire bus-factor audit. If you already ran it, use the highest-risk systems from that work. ##### Week 2: interview two bottlenecks Schedule 90 minutes per person. Don't ask for completeness. Pick decisions, failures and dependencies. Record the session. Produce 5–10 knowledge cards, not a 40-page handbook. ##### Week 3: stop sending structural questions to humans Identify the questions that can be recovered from repositories: - usages - implementations - dependencies - relevant files - similar patterns Make those queryable. Keep human escalation for the things source code genuinely doesn't contain. ##### Week 4: test the system on someone who wasn't in the room Give a newer engineer a real task. Count: - questions answered independently - questions answered from code/context - questions requiring senior judgment - questions nobody can answer Don't ask if the new system “feels useful”. Measure how many expert interruptions remain. #### The metric worth keeping is interruptions avoided Tribal knowledge is difficult to measure because its cost appears as other things. Slow onboarding. Review queues. Senior-engineer overload. Systems nobody wants to change. Repeated Slack questions. The original draft therefore proposes a refreshingly simple measurement: after capture work, give someone a real task and count how often they still need the expert. We'd make that the primary metric. ##### Senior interruptions per system per week Don't optimize the number toward zero. Some questions should reach senior engineers. Instead classify them. RETRIEVAL → “Where is this implemented?” HISTORY → “Why did we make this decision?” JUDGMENT → “Given today's constraints, what should we do?” The target isn't “no interruptions”. It's: Stop paying senior-engineer attention for retrieval. Preserve it for history and judgment. #### How AI should change the pattern Research into onboarding is increasingly exploring AI as a way to augment expert mentoring rather than simply replace it. A 2024 systematic literature review of 32 studies on software onboarding found that tooling can reduce onboarding barriers and pressure on senior team members, but also concluded that many onboarding barriers remain insufficiently addressed. Read the systematic review. A 2026 research roadmap for software-engineering agents similarly identifies code, documentation and requirements as sources from which AI systems may extract and deliver context for onboarding, collaboration and knowledge sharing. See the research roadmap. The useful model isn't: AI replaces the knowledgeable senior. It's: AI and retrieval absorb repeatable context delivery so the knowledgeable senior spends more time on the knowledge that hasn't been captured yet. That is a much more realistic target. #### What can't be automated Some knowledge isn't in the repository. It isn't in Jira. It isn't in the wiki. The only existing copy is in someone's head. Until that person explains it, software can't extract it. That is why a tribal-knowledge program needs both sides: ##### MACHINE-RECOVERABLE - current structure - file relationships - implementations - dependencies - source history that still exists ##### HUMAN-CAPTURED - intent - rejected alternatives - historical constraints - failure lessons not recorded elsewhere - judgment Pretending one side replaces the other is how teams end up with either a giant stale wiki or an AI assistant confidently explaining history it never observed. #### Start with the system that interrupts the same person every week Don't inventory all organizational knowledge. Pick one subsystem where engineers repeatedly ask the same senior for help. For 30 days: - capture its high-risk decisions - make structural code knowledge queryable - give someone else a real task - count the remaining interruptions Tentaro can handle the repository-grounded part of that workflow: extracting structural context and making it available to engineers and compatible AI assistants through MCP. Historical reasoning still needs to be recorded by the humans who know it. --- # Blog: Where AI code context fits in your 2026 AI developer roadmap. Source: https://www.tentaro.ai/blog/where-ai-code-intelligence-fits-in-your-ai-developer-roadmap-2026 Code generation tools are powerful and can significantly accelerate development work. Their main limitation is not capability, but context. Without access to organizational knowledge, internal conventions, and system-specific patterns, generated output often requires careful verification. This is why generation tools work best when paired with AI code search, as the latter provides immediate visibility into the existing codebase, making it easier to align AI-generated changes with the realities of the system. In regulated environments, the adoption model may look different. Security or compliance constraints can restrict the use of cloud-based code generation. AI code search still improves developer efficiency across implementation, review, and documentation workflows by enabling fast navigation and comprehension of large multi-repository codebases. #### What is AI code context, and how does it help in practice? code context tools, help developers find and understand existing code. If a search returns a poor result, the developer simply searches again. Nothing changes in your codebase. Code search also integrates without friction. No new review processes, no changes to CI/CD, no new permissions. Generation tools require policies for AI-written code that stall many pilots before they produce data. #### Clear metrics for measuring AI code context An AI code search assistant only reads your code, which makes it much easier to measure its impact. You can track simple things like: • how long it takes to find the right piece of code • how quickly new developers get up to speed • how many hours the team spends searching each week. If your team of 20 developers each spends 5 hours weekly understanding code, that equals 100 hours of engineering time. At $75 per hour, that’s $360,000 per year. A 10% reduction recovers $36,000, a realistic input for an AI ROI framework for tech teams. #### Faster path to Phase 3 expansion Code generation tools face tough questions from security and legal teams. Code search tools face fewer objections because they produce no code that enters production. This approach indexes your repositories on your on-premise servers, without ever publishing your IP outside of your organization and lets developers ask natural-language questions against company’s codebase. Tentaro follows that model and runs entirely on your infrastructure. That baseline ROI for developer tools in Phase 2 lays the groundwork for expanding into code generation in Phase 3. Phase Timeline Key outputs Discover Weeks 1–4 AI use policy, pilot candidates, risk assessment Pilot Weeks 5–12 Baseline metrics, adoption data, rollout plan Scale Months 3–6 Standardized toolchain, workflow integration, context setup Optimize Month 6+ Outcome metrics, cost controls, governance updates #### ROI quantification: metrics for measuring AI code search assistants The calculation above (search time × hourly rate × team size) is a starting point. But CFOs want a complete picture. To build a defensible AI ROI framework for tech teams, you also need to account for time lost to interruptions, rework, and duplicated effort. ##### The metrics competitors ignore Most dashboards show how much code was written. But velocity depends on how much time was wasted. Time saved on code discovery: Developers spend a noticeable part of their day working through code that already exists - checking prior implementations, tracing dependencies, and looking for similar solutions. This often adds up to around an hour per workday. Cutting that effort from roughly 60 minutes to 10 minutes per day recovers close to 200 hours per engineer over the course of a year. This overhead tends to increase with seniority. Product Owners, Tech Leads, and CTOs operate across multiple projects, repositories, and architectural contexts. Without dedicated code context tooling, moving through this knowledge layer becomes time-consuming and mentally demanding. Reduced senior interruptions: Every "how does this authentication wrapper work?" question breaks a senior engineer's flow. An AI code search assistant acts as the first line of defense, deflecting queries before they reach your most expensive resources. Faster onboarding: Measure time-to-first-PR. By giving new hires instant answers to architectural questions, onboarding time typically shrinks by 30-40%. Fewer duplicated implementations: Semantic search reveals existing utility functions, stopping teams from rebuilding logic that already exists. This is a major source of long-term technical debt. ##### Sample before/after measurement model Metric Before With AI code search Discovery time 45 mins/day (manual search, asking colleagues) 5 mins/day (instant retrieval) Context switching High (senior devs interrupted 5x/day) Low (self-serve answers) Code reuse Low (reinventing logic) High (finding existing patterns) This is the difference between testing AI in isolation and measuring its impact across your 2026 technology roadmap. #### Generation and search - different value mechanics in AI-assisted development The ROI examples above focused on code search, but they also highlight a practical difference between common AI tools. Code generation primarily affects how quickly new code is produced. AI code search influences how much time engineers spend working through the code that already exists. Both mechanisms improve productivity, but they operate on different parts of daily development work. Generation tools speed up implementation. Code search tools reduce the effort required to find, inspect, and verify existing logic, dependencies, and patterns. This becomes particularly visible in larger systems. Code generation increases output, which makes fast access to existing patterns and dependencies more important. Code search shortens the time needed to inspect how the system already behaves, making AI-assisted changes easier to validate and adapt. For organizations operating under security or compliance requirements, this difference often influences how AI adoption unfolds. Improving codebase visibility and knowledge retrieval typically becomes an early step that supports broader use of generation tools later. ##### Conclusion The future of AI developer tools in enterprise environments follows a pattern: organizations that start with low-risk, high-visibility tools build the metrics foundation and organizational trust needed for broader adoption. Tentaro fits this approach. It runs on your infrastructure, indexes your repositories locally, and produces no code that enters production. Talk to us about a pilot. --- # Blog: Why generating code isn’t the same as code context? Source: https://www.tentaro.ai/blog/why-generating-code-isnt-the-same-as-code-intelligence AI code generation tools can spin up a new endpoint, a data model, or a UI flow in minutes. The problem starts when that code needs to land inside a ten-year-old system with shared libraries, half-documented conventions, and business rules buried in multiple different services. This article looks at what vibe coding does well, and why AI code context has become the missing piece for teams that need to find the logic they want to change before generating new code. #### What is vibe coding? Vibe coding is prompt-driven code generation without a detailed plan for implementation - you describe what you want in natural language, and an AI tool produces the code. No more switching between your editor and the docs to figure out the correct syntax. Andrej Karpathy coined the term in early 2025 to describe a workflow in which AI handles most of the code generation while developers focus on direction and review. ##### From writing to reviewing Developers increasingly act as reviewers of generated code rather than its sole authors. Different tools support this shift in various ways. - Cursor and Claude Code let you make changes across multiple files by describing what you want and then approving the diffs. - GitHub Copilot suggests blocks of logic based on the file you are working in. All AI code generation tools are optimized for speed to first output. The workflow is the same: you prompt, you review, you accept. ##### The fake productivity trap It feels incredibly productive. You don't have to remember syntax or type out boilerplate. You describe what you want, and the model generates a working function before you finish your coffee. I've seen developers prototype entire API endpoints in an hour that would have taken a day to write manually. But there's a reason it feels productive rather than being productive. You're generating code, but you may not fully understand it. If you don’t understand what’s being generated, the project effectively lives inside the model’s context window. Once that context is gone, the model starts reasoning almost from scratch, with limited memory of earlier decisions. That gap becomes much more visible when working in an existing codebase with years of accumulated logic, undocumented decisions, and patterns that exist for reasons no one remembers. Vibe coding encourages isolated, local changes without a view of the broader system. Over time, this turns enterprise codebases into a patchwork rather than a coherent architecture. #### How AI code context works AI code context solves a different problem than vibe coding. Instead of generating new code from a prompt, it helps you locate and understand existing code. ##### Grep vs semantic search Traditional search tools like grep rely on pattern matching. They search for exactly what the developer specifies, whether that’s a literal string or a regular expression. This makes them powerful for finding known patterns, but limited to the form of the query itself. A search for “user authentication” will still miss a function named verify_identity because the words don’t appear, even though the behavior is related. Semantic code search works differently. The system converts both code and your natural language query into vector representations in a high-dimensional space, then calculates the distance between them. A query for "handle payment failure" will mathematically align with process_transaction_error because the model understands the semantic relationship between "failure" and "error" in a transactional context. I still use grep when I search for exact matches with 100% accuracy . But when I'm trying to answer "where do we handle retries?" in a codebase I didn't write, pattern matching won't get me there. ##### Understanding real, production code paths Vibe coding tools might hallucinate a library or method that should exist but doesn't. With AI search, results are constrained to actual code. The best search tools go further than semantics. They include static analysis (call graphs), so you're not just finding a function, but also seeing where it fits. Who calls it, what data it takes in, and what it triggers downstream. And because the output is always a pointer to a real file and line number in version control, there's nothing to hallucinate. The code either exists or it doesn't. ##### code context tools for complex architectures These tools index entire repositories, sometimes dozens at once, so developers can search across the full engineering footprint. - Sourcegraph pioneered this category. It combines code search with Cody, an AI agent that follows connections between repos to answer questions such as "where is rate-limiting applied across all microservices?" - Tentaro is built for enterprises that need to keep data on-premises - answers are grounded in your production code, pointing to specific files and line numbers. It’s optimized for LLMs which can be hosted locally on private - nothing leaves your environment. #### Code generation vs. code comprehension Most conversations about AI code generation tools focus on how fast the model can produce working code. But writing new code isn’t the most time-consuming part. Maintenance and evolution of existing systems take up 50-80% of total software lifecycle costs. Most of that cost comes from: - understanding how legacy systems connect - tracing why architectural decisions were made - finding where specific logic actually lives ##### How greenfield and brownfield work differ Greenfield means starting from scratch - no legacy code, no existing constraints. Brownfield is the opposite: building within existing systems, working around live software and decisions made years ago that nobody fully remembers. Most developers work in brownfield. Greenfield projects require 40-60% higher initial investment, which is why enterprises usually choose to evolve what they have rather than rewrite from zero. Responsible vibe coding handles greenfield well. But when you try to generate a feature into a ten-year-old monolith, you hit limits. The model can only see what fits in its context window; it has no visibility into the rest of the codebase. That’s a structural blind spot. I've seen this go wrong in predictable ways. The generated code compiles fine, but it skips the error-handling pattern everyone else uses. Or it pulls in a library that was deprecated two years ago. Or it rebuilds a utility function that already exists three folders over. The code works. It just doesn't fit. ##### The "more code" problem There's a misconception that enterprises need more code. In my experience, the opposite is true. Most organizations I work with are drowning in complexity. They are trying to figure out how to search code faster within existing systems. Studies on AI adoption have shown an 8x increase in duplicated code blocks. Developers spend less than 20% of their time writing new code. The rest goes to CI/CD, monitoring, security, as well as maintenance of existing code and fixes.. More code without more capacity to understand it means technical debt grows faster than the team can manage. Vibe coding adds to the pile. Code search, meanwhile, works the other way: it helps teams find and reuse existing code before writing new one. ##### The hidden cost of hallucinated patterns And sometimes what it adds shouldn't be there at all. Researchers found that nearly 20% of package recommendations from code-generating LLMs referenced non-existent packages. In private codebases, the problem often looks different. Instead of guessing blindly, the model recreates functionality that already exists, because it has no visibility into the company’s internal code. That grounding is what makes code search safe. When the answer is always a file, a function, and a line number from your own repo, there’s no room for invented packages or imaginary APIs. #### Why vibe coding fails at scale Vibe coding is constrained by the model’s context window. Even when it attempts to search the project and understand its details, that window is too small for large codebases, so it works with an incomplete picture of the system. In enterprise systems, where logic, dependencies, and constraints accumulate over years, that level of understanding is not sufficient. ##### The problem with AI code search across multiple repos Most vibe coding tools only operate on what the developer has open - the current project and the current file. They can't see the API contract defined in a different repository. A developer asks the AI to update a user payload. The AI updates the local Python service, but it misses the TypeScript type definition in the frontend repo and the Kafka schema in the data pipeline. The code passes unit tests locally but causes a runtime serialization error in production. AI code context works differently - it lets you ask “where do we build and validate the user payload?” across the entire organization, not just the active window. ##### What the model doesn't know Old codebases are full of code that looks wrong but exists for a reason. A weird workaround that handles an edge case from 2016, or a manual parser instead of a standard library, because the standard library couldn't handle a specific input format. These decisions often aren't documented. They live in the heads of senior engineers or are buried in commit messages nobody reads. AI doesn't know any of that. It sees the weirdness as inefficiency and "fixes" it. The code gets cleaner, but then, something breaks. ##### Why AI-generated code creates security and compliance risk 62% of AI-generated code solutions contain design flaws or known security vulnerabilities. Models tend to produce code that runs, not code that follows a team’s security or compliance standards. When dozens of developers rely on their own prompts, the codebase drifts. - one team uses async/await, another sticks to Promises, a third introduces its own helper layer around the same API - security conventions fade - compliance rules bend across a long stream of pull requests Code search brings those patterns back into view. It shows the shared helper code and the conventions that passed review. Knowing what is already in place beats adding another variation. #### The hybrid reality and intelligent code navigation The question is not whether to use AI code generation or AI code context. Mature teams use both, with clear roles for each. ##### Why generation and search work together Generation tools write code fast. Search tools assist them in creating fitting code. In strong teams, search comes first. Before a developer asks an AI system to build or refactor something, they review the services, interfaces, and prior implementations that already handle similar work. The generator then operates within that context, so the output matches the system's design rather than introducing a parallel version. In practice, that means: - using generation for scaffolding, repetitive logic, and well-defined changes - using code context tool before generating to surface existing components and patterns - using code understanding and generation simultaneously, with code generation asking code search questions about the existing codebase Teams that get this right treat search as the starting point, not a cleanup step. ##### code context as the grounding layer for long-lived systems Generation gives you something to start from, but search tells you how this problem was handled last time, in this system, by this team. That context decides whether new code slides into place or starts pulling the codebase apart. In teams that run large, long-lived systems, this turns into a habit. Developers look for how data, APIs, and flows are already wired together before asking AI to add anything new, so the codebase grows by extension rather than by copy-paste. ##### Conclusion The market keeps asking how fast AI can write code. For most enterprise teams, the harder part is understanding their existing codebase and building on top of it without breaking production. That is where AI code context tools change how teams work. Book a DEMO and check how AI code context works on real repositories. --- # Blog: Your Seniors Became AI Babysitters Source: https://www.tentaro.ai/blog/your-seniors-became-ai-babysitters The job description didn't change. It’s the job that did. A senior engineer who spent a decade learning how to design systems can now spend half a morning deciding which AI-assisted pull requests are safe to merge. The assistant can produce another implementation in seconds. The senior still has to work out if it belongs in the system. That's the part of AI coding economics we don't talk about enough. Generation scaled. Judgment did not follow. Faros AI's 2025 telemetry across more than 10,000 developers and 1,255 teams found that high-AI-adoption teams merged 98% more pull requests and completed 21% more tasks. At the same time, PR review time increased 91% and average PR size increased 154%. At organization level, Faros found no corresponding improvement across overall throughput, DORA metrics or quality KPIs. That's not evidence that AI coding doesn't work. It's evidence that when one stage of a system accelerates, the constraint can simply move somewhere else. And increasingly, it moves to the humans who know enough to say no. #### Generation got cheap Writing code was never the only expensive part of software engineering. The harder part is deciding what belongs in a system that already exists. That requires context: - what already solves the problem - which dependency isn't obvious from the current file - why an earlier team made a particular trade-off - what looks local but has consequences three services away - which implementation is technically valid but wrong for this architecture AI dramatically reduces the friction of producing a plausible change. It doesn't automatically reduce the effort required to establish that the change is the right one. Faros's data makes the shift visible. High-AI-adoption teams in its 2025 dataset were producing substantially more pull requests, but review time increased at the same time. Faros describes human approval as a new bottleneck in the software-development lifecycle. The research report includes the underlying metrics and methodology. That's an important distinction. A company can improve generation throughput without improving delivery throughput. If everything downstream remains fixed, more code simply arrives at the queue faster. #### The queue is where the cost becomes visible Think of an engineering workflow as a pipeline. Before widespread AI coding: design → implementation → review → test → deploy Implementation consumed a meaningful share of the time. Now an agent may dramatically compress that stage: design → IMPLEMENTATION → review → test → deploy The rest of the pipeline hasn't magically compressed with it. Faros calls this pattern an AI productivity paradox. Its 2025 analysis found 98% more merged PRs on high-adoption teams alongside 91% longer review times, while aggregate organizational delivery metrics showed no significant improvement. The company hasn't necessarily become slower. It may have created more work-in-progress upstream than its existing verification capacity can absorb. And unlike token usage, review capacity isn't elastic. You can't API-call another five years of architectural experience. #### When verification runs out, it doesn't announce itself Nobody schedules a meeting and says: “From Monday, we're going to understand less of the code we merge.” The standard shifts quietly. The queue grows. A change looks reasonable. Tests pass. The diff is larger than anyone would like, but another eight PRs are waiting. So review moves from: “I traced what this touches and I understand why it belongs here.” toward: “Nothing obvious looks wrong.” Faros's 2026 report, based on two years of telemetry from 22,000 developers across 4,000 teams, suggests the pressure did not ease as teams got used to the tools. Comparing the periods of lowest and highest AI adoption within each organization, median time in pull-request review was up 441.5%, bugs per developer were up 54%, and pull requests merged without any review, human or agentic, were up 31.3%. Those are observational measurements, not proof that AI directly caused every change. But they describe a failure mode engineering leaders should recognize: when verification capacity saturates, the work doesn't necessarily stop entering production. The debt leaves the review queue. It moves into the codebase. When verification runs out, it doesn't announce itself. The person reviewing the code is often also the missing context Why can't we solve this by simply adding more reviewers? Sometimes we can. Generic bugs, formatting, obvious security patterns and mechanical checks are excellent candidates for automation or wider review distribution. But some reviews repeatedly route toward senior engineers for a different reason. The reviewer isn't only checking code quality. They're supplying organizational memory. They know: “We tried that abstraction two years ago.” “This service looks independent, but settlement assumes that ordering.” “You can't move this call without breaking the fallback path.” “There's already an implementation in the other repository.” “The reason this ugly piece exists is incident 481.” That's not generic programming knowledge. It's knowledge of this system. Which means the senior engineer is simultaneously: - reviewer - architecture historian - dependency map - duplicate detector - incident memory - escalation endpoint You can hire another competent engineer. You can't instantly give them the same organizational context. #### Confident wrong answers scale faster than corrections There's another reason the senior becomes important as AI usage grows. AI can produce explanations as easily as implementations. That's useful when the explanation is grounded. It's dangerous when nobody knows enough to challenge it. Anthropic tested this from a learning perspective in a randomized controlled study published in January 2026. Developers learning an unfamiliar asynchronous programming library with AI assistance scored 50% on a later comprehension quiz, compared with 67% for developers who worked without AI assistance. The result wasn't uniform across all AI use: participants who asked conceptual questions and engaged with explanations retained more than those who primarily delegated the work. Anthropic publishes the study and methodology here. The interesting failure mode isn't: AI wrote bad code. It's: AI did enough of the reasoning that the person shipping the result built a weaker mental model of what happened. That matters during review. An AI assistant working on a system with an available expert has a correction mechanism. The assistant says: “This queue exists to reduce latency.” And the senior says: “No. It exists because the synchronous version caused ordering failures.” The hallucinated rationale dies. Now remove the senior. The same explanation can become the best answer anyone has. A fluent answer starts filling the gap where organizational knowledge used to be. That's how concentrated knowledge changes from a productivity problem into a verification problem. #### The most dangerous modules aren't necessarily the oldest ones We tend to associate tribal knowledge with legacy systems. A billing platform from 2014. A Java service nobody wants to touch. A home-grown integration that survived four reorganizations. AI changes that assumption. A new module can accumulate weakly distributed understanding quickly if: - an agent generates much of it - one engineer directs the work - another engineer gives a shallow review - nobody else builds a full mental model The code may be three weeks old. Its effective bus factor can still be one. That is one reason raw contribution counts aren't enough to measure knowledge distribution. Research into software bus factor has found that engineering knowledge also flows through code review and team communication, not just authorship history. A 2022 study based on 269 engineer responses proposed a multimodal model combining version-control, code-review and communication signals. Read Bus Factor In Practice. More people touching code doesn't automatically mean more people understand it. #### More contributors ≠ more shared understanding A repository can have: 20 contributors and still have: 1 person who can explain why the important parts work the way they do. #### The reason teams don't notice is that AI feels fast This is where the METR result becomes useful. In its 2025 randomized study, 16 experienced maintainers worked on 246 real issues in mature open-source repositories they already knew well. When allowed to use AI tools, they took 19% longer on average. Before the study they expected AI to make them 24% faster, and afterward they still believed it had made them roughly 20% faster. METR publishes the complete study, sample and limitations here. The narrow sample matters. It doesn't establish that AI makes developers slower in general, and METR explicitly warns against that interpretation. What it gives us is much more relevant here: developers can be wrong about their own AI-driven productivity. AI changes the subjective experience of work. Waiting for yourself to type 80 lines feels slow. Watching an agent produce them in ten seconds feels fast. The review, correction, rediscovery and coordination costs happen later and are spread across different people. That makes them psychologically easier to miss. #### “Just automate more of the review” only solves part of the problem We absolutely should automate more review. Static analysis. Tests. Security checks. Linting. Common defect detection. Policy enforcement. These tools raise the floor and keep humans from spending scarce review time on mechanical problems. But no generic reviewer knows automatically that: the company already solved this problem in another repository or: the current implementation looks inefficient because of a customer-specific constraint or: the proposed change reintroduces an architecture the team deliberately abandoned Those questions require organization-specific context. You can give that context to an AI reviewer. But then you've moved the same problem one layer back: where does the reviewer get reliable knowledge of the system? The answer can't simply be “whatever fits in the prompt.” #### Two kinds of context, two different fixes Look again at what the senior supplied in those reviews. Some of it is structure: where the existing implementation lives, what calls this function, which service owns the event, which files a change touches. That knowledge is in the code. Anyone with the right tooling can retrieve it, and nobody should need ten years of experience to do so. The rest is rationale: why the abstraction was rejected two years ago, why the ugly piece exists (incident 481), why settlement depends on that ordering. None of that is in the code, and no index will find it. It is retrievable only if someone wrote it down. That second category has a process fix, not a tooling fix. Every time a senior reviewer supplies a "why" in a review comment, the team needs a place where it lands for the next reader, human or AI: an architecture decision record, a decision log in the repository, a comment next to the code that links to the incident. Writing those used to lose out to delivery pressure because it was slow. It is not slow any more. The same assistant that produced the change can draft the decision record from the review thread, with the senior correcting instead of writing. Teams that do this turn every review into a deposit into shared context. Teams that do not keep paying the same senior to answer the same question. #### The scalable part is retrieval, not judgment A lot of senior-engineer interruption isn't senior-level work. Questions such as: - Where is this implemented? - What calls this? - Is there an equivalent in another repository? - Which service owns this event? - Where is this configuration used? - Which files are relevant to this change? don't inherently require ten years of experience. They require access to the right codebase context. Today, those questions often land on seniors because the senior can answer them faster than another engineer can reconstruct the system. That's the layer Tentaro targets. Tentaro indexes private repositories and makes grounded code context available to engineers and compatible AI assistants through MCP. Its product boundary deliberately stops short of code generation: the value is supplying the organizational context around code, with answers grounded back in source. That changes the routing pattern. Not: AI generates → senior reconstructs everything → senior approves but: AI generates → system-specific context is retrievable → senior spends attention on judgment The senior doesn't disappear. Their scarce time gets used for questions that genuinely need them. #### Questions to ask before adding another coding agent Before increasing seats, agent concurrency or autonomous workloads, look at what happened to the existing verification layer. ##### 1. Did PR volume grow faster than review capacity? If yes, more generation may simply deepen the queue. ##### 2. Which reviewers receive the most AI-assisted changes? Don't average across the team. Find the humans at the constraint. ##### 3. What percentage of their review time is actually retrieval? Sample ten reviews. How much time was spent deciding versus finding context that could have been retrieved? ##### 4. How often can authors explain the generated change without reopening the AI session? That's a surprisingly useful comprehension test. If the author needs the agent to reconstruct its own work before they can discuss it, the team may be merging output faster than ownership is being created. ##### IS YOUR SENIOR REVIEW QUEUE A CONTEXT PROBLEM? Check what your senior reviewers did last week: - explained where logic lives - pointed developers to another repository - identified existing implementations - reconstructed dependencies - explained historical architecture - corrected an AI explanation of the system - reviewed large AI-assisted diffs - answered questions that could be resolved from code - delayed higher-level design work because review was waiting If most boxes are checked, you don't have only a review-capacity problem. You also have a context-distribution problem. #### Senior review should be a scarce resource The most expensive reviewer shouldn't spend their day telling people which file to open. Their value is in judgment that the repository alone can't give you. Questions such as: - Is this trade-off worth making? - Does this fit where the product is going? - Are we accepting the right operational risk? - Is the obvious solution wrong because of something the team learned before? - Should this abstraction exist at all? Those are senior questions. “Where is the implementation?” isn't. The more AI scales code generation, the more important that distinction becomes. You don't need to eliminate human review. You need to stop consuming senior review capacity on work that isn't actually judgment. #### AI didn't remove the bottleneck. It revealed it. For years, implementation limited how much engineering work a team could put into motion. AI is weakening that constraint. That's valuable. But software delivery is a system. When implementation becomes cheaper, another scarce resource becomes visible. In many teams, that resource is verified organizational understanding: - Faros's telemetry gives us one view of the shift: high AI adoption correlates with much higher output and much longer review cycles. - Anthropic's learning experiment shows that task completion and retained understanding don't always move together. - METR shows that the people doing AI-assisted work can misjudge its effect on their own speed. Put those together and a more useful question emerges. Not: How much more code can our agents generate? But: How much more change can our organization understand, verify and safely absorb? That's the capacity worth scaling next. #### What are your seniors actually reviewing? Take ten AI-assisted pull requests from the last two weeks. For every senior-review comment, classify it: MECHANICAL → Could a tool catch it? RETRIEVAL → Did the reviewer supply information already present somewhere in the codebase? JUDGMENT → Did the reviewer make a decision that required experience, historical intent or trade-offs? If retrieval is consuming a meaningful share, that's a fixable bottleneck. Tentaro is built for that middle layer: making private code context queryable to engineers and compatible AI tools so senior attention stays available for the work that actually requires judgment. ##### Test one review-heavy repository See how Tentaro supplies code context through MCP, keep the coding tools, and review process you already have.