The post has been translated automatically. Original language: Russian
In the continuation of a series of articles from the CNCF 10th anniversary event, CNCF currently oversees more than 240 projects, from Kubernetes and Prometheus to Argo and dozens of lesser-known tools. This is the largest cloud-native ecosystem, with more than 700 corporate participants, thousands of developers, and an infrastructure that de facto standardizes how enterprise builds and runs applications). I would also like to touch on the implications of AI tools for development and products in general.
CI/CD and “Eternal September”
Two things Bryce calls the direct consequences of AI development tools. Both are in a sore spot.
First, the existing code review processes and CI/CD platforms will not be able to cope with the pace of change introduced by AI coding tools. An honest recognition from a person whose ecosystem includes several CI/CD projects. I've seen teams that simply drown in PR from Copilot-assisted developers - not because the code is bad, but because there's too much of it and it's physically impossible to check it with the same care. When a junior who used to write a conditional 50 lines per day starts generating 500 (the numbers are conditional, my illustration), the quality of each individual line may be normal, but the cumulative load on the verification team increases by an order of magnitude. Pipeline, designed for a conditional 20 PR per day, receives 200.
Second: the phenomenon that Bryce calls “Eternal September.” A term from the early history of the Internet - every September, freshmen appeared on university campuses who did not know any of the rules and processes of Usenet. The old-timers spent their efforts on training newcomers, and then the next September came. In 1993, AOL connected Usenet to the mass Internet, and “September” became eternal - the newcomers never ended.
The analogy is direct. AI tools allow developers to contribute more code than ever before. Maintainers of open source projects are already overloaded. We need to expand their ranks, but this is a slow, human process. You can't train a new maintainer in a week, because for a high-quality check, you need not just to know the language, but to understand the architectural solutions of the project, the history of compromises, and non-obvious dependencies.
I see real pain here, not metaphorical. When the number of incoming PRS doubles, but the number of people able to check them qualitatively remains the same, the quality inevitably decreases. Bryce says bluntly: the amount of sloppy code created by AI tools continues to grow. And I have no reason not to believe him - I see it in the projects I work with.
The role of an engineer: platform engineering as an answer
Bryce is not saying that engineers will become unnecessary. He says the role is evolving. As organizations adopt platform engineering as the primary methodology for building and deploying applications at scale, it is this role that becomes central.
I see this in real teams. A developer who knows how to work with AI tools and at the same time sees the system picture - how services interact, where bottlenecks are, and how to ensure reliability - becomes more valuable. Not cheaper. AI tools lower the entry threshold for writing code, but raise the bar for what “engineer" means. Copilot can write a function. Understanding that this feature will create a race condition for concurrent requests, increase latency by 200ms, or violate a contract with a lower-level service still requires a person with experience and system thinking.
And someone who simply generates code without understanding the architecture creates problems for maintainers and, as a result, for the entire system. Hence the growing importance of platform engineering, a discipline that sets limits, standards, and infrastructure within which AI tools can work productively rather than chaotically. The Platform team determines which API contracts are required, what the deployment pipeline looks like, and which metrics are collected. Without this, AI coding tools are a multiplier not only of productivity, but also of chaos.
An open question about 240+ projects
And here Bryce is honest.: It is not clear to what extent all 240+ CNCF projects will remain relevant in the age of AI. In some cases, AI agents trained on open source software are already creating specialized versions of the same software to solve similar problems. This is a subtle point - AI learns from the project code, and then generates a competitor for this project.
The question is, in fact, an existential one for a part of the ecosystem. If an agent can generate a specialized version of a tool tailored to a specific use case, better than a community-supported universal project, why use the latter? Today, open source projects are winning at the expense of the community: bug fixes, security patches, integrations that one person won't write. But if an AI agent can support a specialized solution on its own, including security updates, the advantage of the community is eroded.
I do not know the answer. It seems to me that large projects like Kubernetes or Prometheus will remain - their complexity and scale are not yet available for AI generation. But dozens of small utilitarian projects out of 240+ may come under pressure. Maybe in a couple of years I'll say that I was naive to think that the open source community would retain its current form.
Source: CNCF Chief: AI Inference Will Drive Increased Cloud-Native Software Consumption (report from the CNCF 10th Anniversary Event, New York, February 2026, based on a speech by Executive Director Jonathan Bryce)
В продолжении серии статей с мероприятия в честь 10-летия CNCF(CNCF сегодня курирует более 240 проектов - от Kubernetes и Prometheus до Argo и десятков менее известных инструментов. Это крупнейшая экосистема cloud-native, с более чем 700 корпоративными участниками, тысячами разработчиков и инфраструктурой, которая де-факто стандартизирует то, как enterprise строит и запускает приложения), также хотелось бы затронуть последствия AI-инструментов для разработки и продуктов в целом
CI/CD и “Вечный сентябрь”
Две вещи, которые Bryce называет прямыми последствиями AI-инструментов для разработки. Обе - в больное место.
Первое: существующие процессы code review и CI/CD-платформы не справятся с темпом изменений, который вносят AI coding tools. Честное признание от человека, чья экосистема включает несколько CI/CD-проектов. Я видел команды, которые просто тонут в PR от Copilot-assisted разработчиков - не потому что код плохой, а потому что его слишком много и проверять его с той же тщательностью физически невозможно. Когда джуниор, который раньше писал условные 50 строк в день, начинает генерировать 500 (цифры условные, моя иллюстрация) - качество каждой отдельной строки может быть нормальным, но совокупная нагрузка на команду проверки вырастает на порядок. Pipeline, рассчитанный на условные 20 PR в день, получает 200.
Второе: явление, которое Bryce называет “Eternal September”. Термин из ранней истории интернета - каждый сентябрь на университетских кампусах появлялись первокурсники, не знающие никаких правил и процессов Usenet. Старожилы тратили силы на обучение новичков, а потом приходил следующий сентябрь. В 1993 году AOL подключил Usenet к массовому интернету, и “сентябрь” стал вечным - новички никогда не заканчивались.
Аналогия прямая. AI-инструменты позволяют разработчикам вносить больше кода, чем когда-либо. Сопровождающие (мейнтейнеры) open source проектов уже перегружены. Нужно расширять их ряды - но это медленный, человеческий процесс. Нельзя натренировать нового мейнтейнера за неделю, потому что для качественной проверки нужно не просто знать язык, а понимать архитектурные решения проекта, историю компромиссов, неочевидные зависимости.
Здесь я вижу реальную боль, не метафорическую. Когда количество входящих PR удваивается, а число людей способных их качественно проверять остается прежним, качество неизбежно падает. Bryce прямо говорит: количество небрежного кода, создаваемого AI-инструментами, продолжает расти. И у меня нет оснований не верить ему - я вижу это в проектах, с которыми работаю.
Роль инженера: platform engineering как ответ
Bryce не говорит, что инженеры станут ненужными. Он говорит, что роль эволюционирует. По мере того как организации принимают platform engineering как основную методологию для построения и развертывания приложений в масштабе, именно эта роль становится центральной.
Я вижу это в реальных командах. Разработчик, который умеет работать с AI-инструментами и при этом видит системную картину - как сервисы взаимодействуют, где узкие места, как обеспечить надежность - становится ценнее. Не дешевле. AI-инструменты снижают порог входа для написания кода, но поднимают планку для того, что значит “инженер”. Написать функцию может Copilot. Понять, что эта функция создаст состояние гонки при параллельных запросах, увеличит задержку на 200ms или нарушит контракт с нижестоящим сервисом - это по-прежнему требует человека с опытом и системным мышлением.
А тот, кто просто генерирует код без понимания архитектуры, создает проблемы для мейнтейнеров и в итоге для всей системы. Отсюда и рост значимости platform engineering - дисциплины, которая задает ограничители, стандарты и инфраструктуру, внутри которой AI-инструменты могут работать продуктивно, а не хаотично. Platform team определяет, какие API-контракты обязательны, как выглядит pipeline развертывания, какие метрики собираются. Без этого AI coding tools - это умножитель не только продуктивности, но и хаоса.
Открытый вопрос про 240+ проектов
А вот тут Bryce честен: не ясно, в какой мере все 240+ проектов CNCF останутся релевантными в эпоху AI. В ряде случаев AI-агенты, натренированные на open source software, уже создают специализированные версии этого же ПО для решения схожих задач. Это тонкий момент - AI учится на коде проекта, а потом генерирует конкурента этого проекта.
Вопрос, на самом деле, экзистенциальный для части экосистемы. Если агент может сгенерировать специализированную версию инструмента, заточенную под конкретный сценарий использования, лучше, чем поддерживаемый сообществом универсальный проект - зачем использовать последний? Сегодня open source проекты побеждают за счет сообщества: исправления багов, патчи безопасности, интеграции, которые один человек не напишет. Но если AI-агент может поддерживать специализированное решение самостоятельно, включая обновления безопасности, - преимущество сообщества размывается.
Я не знаю ответа. Мне кажется, крупные проекты вроде Kubernetes или Prometheus останутся - их сложность и масштаб пока недоступны для AI-генерации. Но десятки мелких утилитарных проектов из 240+ могут оказаться под давлением. Может быть, через пару лет скажу, что был наивен, думая, что open source сообщество сохранит нынешнюю форму.
Источник: CNCF Chief: AI Inference Will Drive Increased Cloud-Native Software Consumption (репортаж с мероприятия в честь 10-летия CNCF, Нью-Йорк, февраль 2026, на основе выступления исполнительного директора Jonathan Bryce)
Share
