AI in SDLC: why just allowing Cursor isn't enough

GitHub Copilot, Alexander recalls, was not the first tool of its kind but the first mass one: it could be rolled out to every GitHub user, and once it showed signs of life the effect was a wow, especially paired with VS Code. Then came Cursor: the team, if Alexander remembers rightly, arrived at a code editor and developer tooling from building ML infrastructure for running large language models. There was one more notable company that OpenAI almost bought and did not: the founders left for Google and the startup went to another buyer. The term vibe coding was launched in early 2025 by Andrej Karpathy, former director of AI and Autopilot at Tesla and one of OpenAI's founding members: a new kind of coding where you give in to the flow and forget about the code, which writes itself. Y Combinator picked the idea up, since it suits startup prototypes perfectly, and its startup school published tips on vibe coding properly.

The market's optimism is illustrated by Dario Amodei: some four months before the talk the CEO of Anthropic said AI would be writing 90 per cent of code within three to six months and almost all of it within twelve. Alexander notes that the head of a company shipping one of the best coding models is partly biased. Anthropic did more than make statements: its Model Context Protocol took the niche between assistants and agents on one side and tooling on the other, and companies now stand up MCP servers around their own tools so an assistant can answer mail, run a calendar and post to Slack. The protocol's limit is a synchronous call that waits for an answer, while agents need a distributed asynchronous architecture; that problem, Alexander says, is what Google's A2A protocol closes. An individual developer can take whichever tool he likes, yet engineering skills are still needed — otherwise you get the meme where a man whose assistant rewrote his entire project is advised to restore the previous commit and asks what git is.

Some of that engineering the tools take on: Replit, Alexander recalls, took over snapshots and state restoring, so an agent can be driven while barely looking at the code. In a large company it does not work that way, and the talk rewinds the history. Development and operations once lived apart, requirements arrived up front as big specifications, and the work amounted to throwing half-finished parts over to the neighbour. From the mid-2000s came DevOps culture with its infinity loop of plan, code, build, test, release, deploy, operate and monitor, and part of big tech overtook its competitors simply by shipping products, collecting feedback and fixing bugs faster. Everyone else had to adapt, and adapting proved expensive: CI/CD pipelines, code storage, tests and observability appeared everywhere, and by 2019 about a quarter of all the bank's engineers were not doing product work but supporting that tooling.

Towards the end of the 2010s came the idea of separating product development from platform development to take away cognitive load; their own attempts began around 2018 but stayed scattered, and in 2020 Igor Maslov arrived to assemble the platform, whose contours were visible by the end of that year. A platform is a product for developers, so the next step is developer experience: a whitepaper originally titled What Actually Drives Productivity proposed measuring cognitive load, the speed of feedback loops and how well engineers can hold a flow state. The example of load is the Cloud Native Computing Foundation landscape: when Alexander sat the Certified Kubernetes Administrator exam some seven years ago there were few boxes on it, whereas an average engineer who has features to ship will look at today's landscape, take fright, weep and close it. The platform hides that complexity behind push-button scenarios.

A 2024 Google whitepaper on measuring developer goals breaks the lifecycle into phases and jobs, derived from internal tool logs and quarterly surveys run since 2018: a job such as writing high-quality code links to the IDE, code review and code search, so it is visible whom the next tool improvement helps. Another paper in the same series, on what developers want from AI, ranks improvements by how deeply AI penetrates: power steering and anti-lock brakes are code completion; a rear-view camera and blind-spot sensors are suggestions in code review and a chat with the model inside the IDE; advanced cruise control is delegation — automatic rollbacks of bad changes, dead code removal, test generation. The same research shows what hurts engineers: technical debt, poor documentation, learning new technologies. The first case is Google: two 2024 whitepapers on API governance describe a formal process where design rules live roughly like Python Enhancement Proposals, a linter gives feedback early and the design review passes almost automatically when the rules are followed; the second paper added a generator that turned product requirements into an API specification. Alexander's conclusion is the Matthew effect — a mature engineering culture with formalised rules adopts generative AI far more effectively.

At ByteDance code review is built as a taxonomy of rules plus two models: one generates comments, the other scores their quality, useless rules are dropped and the model retrained, with adoption and retention watched from the start. Uber calculated that moving from Java to Kotlin by hand would take 10 years and with plain LLMs 3 years, then assembled a pipeline combining models with work on abstract syntax trees. Booking brought in an external contractor and finally moved a fourteen-year code migration, while Datadog is building an on-call agent that works an incident through the runbooks at two in the morning and writes the postmortem. At T-Bank generative models are woven into the existing Spirit platform rather than bought as a tool that will solve everything: the Nestor copilot does code completion, chat with a model, search over internal documentation and edits to a selected fragment, while the phases of the SDLC — from business analysis and testing to SRE, support and documentation — each have a working group, and the SRE block already runs its own bot.