Lingma adoption in an enterprise with mixed legacy code and security constraints
A 300-developer enterprise is rolling out Lingma. The codebase is a mix of a modern service written in Go and a 15-year-old monolith with sparse comments and inconsistent naming. Security forbids sending source code to external services, but the company runs an internally hosted deployment. Early feedback: developers on the Go service report useful completions and good test generation; developers on the monolith report irrelevant suggestions and say the assistant 'doesn't understand our code.' A few developers have started pasting large blocks of proprietary code into public chat tools to get explanations, which security has flagged. The rollout sponsor wants metrics to justify continuing the investment.
1. Explain why the assistant performs well on the Go service but poorly on the monolith, and what interventions would help.
Read the worked answer
The difference is context quality, not model quality:
- The Go service has consistent naming, types, and structure, so local context is informative and completions are predictable.
- The monolith has sparse comments, inconsistent naming, and likely generated or duplicated code. The model has little signal to infer intent, so suggestions are generic or wrong. Repository-wide context helps only if the code itself is legible.
Interventions, in order of leverage:
- Improve the input, not just the tool: add doc comments and rename key functions as developers touch them; even partial cleanup raises suggestion quality.
- Use targeted prompting: ask for explanations of specific functions with the relevant file open, rather than open-ended 'explain this codebase.'
- Scope the rollout: prioritize teams and modules where the tool demonstrably helps (new code, tests, Go service), and set expectations that legacy modules need more human review.
- Generate documentation and tests as a byproduct: use the assistant to produce comments and characterization tests for the monolith, which both helps developers and improves future context.
The judgement is that 'the tool doesn't understand our code' is usually a codebase-legibility problem that the team can influence.
2. Address the security incident and propose rollout metrics.
Read the worked answer
Security: The public-tool usage is a policy and tooling gap, not just a discipline problem. Developers resort to external tools when the internal tool is inconvenient or unavailable for a task. Responses: (a) make the internal deployment cover the missing use cases (e.g., explanation of large files, chat over selected code); (b) clarify policy and add network controls blocking public AI endpoints from corporate devices; (c) provide an internal channel for 'I need this capability' so gaps surface before workarounds appear. Do not rely on warnings alone.
Metrics that justify investment should tie to outcomes, not vanity counts:
- Adoption depth: weekly active developers and suggestions accepted per active developer, segmented by team and codebase area.
- Quality proxy: acceptance rate and edit distance of accepted suggestions; test-generation acceptance.
- Delivery impact: cycle time on tasks in pilot teams vs. control, review comments per PR, test coverage change.
- Risk: incidents related to external tools, and review findings on AI-assisted changes.
Segment every metric by Go service vs. monolith so the sponsor sees where value is real and where it needs investment. A single blended number would hide the story.