[3/3] Integrating AI into a Large Company’s Development Process: Why Giving Everyone Cursor Is Not Enough (Category Management)

The large-company examples in the previous post show an approach that starts by extending human capabilities and successfully delegates some scenarios to agents. At T-Bank, we are following roughly the same path. My colleagues describe it in detail in their Platform Engineering Night talks:

• Igor Maslov’s “AI and Platform Engineering.”
• Denis Artyushin’s “Developing Your Own AI Coding Assistant: Sprint or Marathon?.” We have passed the first, basic level, covered many second-level scenarios, and reached the point of delegating engineers’ work to agents. A centralized team builds our copilot, Nestor, but Nestor is also an umbrella brand for initiatives driven by working groups in planning, analysis, design, development, testing, and SRE. Here, for example, is a talk about introducing an SRE AI assistant. With our observability platform Sage, we are taking AI in roughly the same direction as the Datadog example mentioned earlier.

This broader trend in platform development in the generative-AI era is clear in Red Hat’s November 2024 report, State of Platform Engineering in the Age of AI (my review). Its main findings include:

• Platform engineering is becoming strategic. Some 62% of companies already have dedicated platform engineering teams. It is a strategic tool for accelerating innovation and AI adoption, beyond infrastructure automation alone.
• AI’s impact. Some 76% of organizations already use generative AI for development tasks such as documentation, code generation, and suggestions. For 45%, AI is central to their platform strategy.

So why is simply letting everyone use Cursor not enough?

For small companies, it can be a very reasonable option:

• These tools quickly produce code for landing pages, prototypes, and MVPs.
• They are not very expensive, and intellectual-property, data, or sanctions risks are usually less of an issue.
• Engineering skills are still necessary. You do not want to repeat the story in which an agent deleted all the code and Git could not restore it because the vibe coder did not know what Git was or why to use it.

Larger companies need the more involved approach described above:

• Copilot, Cursor, and Windsurf cannot use internal platform tools out of the box. MCP servers for platform products can teach them to, but…
• Information-security, intellectual-property, and personal-data risks are often too high for external SaaS solutions.
• By working with LLMs inside the SDLC, these companies can learn on familiar, lower-risk products before applying that expertise to customer-facing products.
• Sanctions add substantial risk: external SaaS may officially be unavailable, and access obtained by other means can disappear, leaving the company stranded. Large companies therefore often build their own LLM solutions and learn to integrate them into their SDLC and products. At their scale, that can make economic sense. Released model weights from Llama, DeepSeek, and Mistral help them keep reasonably close to the mainstream.

Medium-sized companies have a harder choice: external solutions may be too risky, while building their own may cost too much. Fortunately, some Russian companies are developing SDLC products where AI is a first-class participant :)

#AI #PlatformEngineering #Engineering #Software #Processes #Productivity