AI не просто ускоряет старый software development — он делает его исходные предпосылки неверными

 Публичный пост
8 сентября 2026  35

Старый цикл примерно такой:

идея → требования → декомпозиция → backlog → implementation → review → test → deploy

Он возник в мире, где изменение программы дорого. Поэтому вокруг изменения построили огромную машину: заранее решить, что делать, нарезать это на manageable chunks, распределить между людьми, синхронизировать, проверить и аккуратно выпустить.

А теперь индустрия делает примерно следующее:

Отлично, implementation стал в 5–20 раз дешевле.

Давайте оставим всю остальную машину неизменной и просто быстрее хуярить тикеты.

А это война уже даже не вчерашняя, а позавчерашняя.

Потому что если производство решения стало дешёвым, то bottleneck переехал.

Он больше не здесь:
spec → code

Он теперь здесь:

что вообще происходит?
→ что мы хотим изменить?
→ какое изменение действительно имеет смысл?
→ как узнать, что оно сработало?
→ что мы узнали после изменения?

То есть bottleneck стал эпистемическим, а не производственным.

И отсюда довольно неприятный вывод для нынешнего AI coding восторга:

если ты в десять раз ускорил execution неправильного цикла, ты можешь просто в десять раз быстрее производить мусор.

Feature factory + AI = high-frequency feature factory.

Те же рандомные хотелки. Те же quarterly goals. Те же Jira tickets. Те же абстрактные user stories. Те же PM, пытающиеся заранее угадать правильное решение. Только теперь код появляется практически мгновенно.

И организация получает чудовищную иллюзию прогресса, потому что output взлетел.

  • PR'ов больше.
  • Фич больше.
  • Экспериментов больше.
  • Release cadence выше.

А learning rate может вообще не измениться.
И вот это, мне кажется, вторая очень сильная ось:
Stop measuring how much faster AI lets you build. Start measuring how much faster your system learns what should exist.
Потому что если разворачивать это до конца, сам объект «software development» начинает распадаться.

Раньше человек говорил:
нам нужна функция X, надо написать программу, которая делает X.
Теперь правильнее:
у нас есть некоторое намерение, текущее состояние мира и разница между ними. Давайте найдём преобразование, которое эту разницу уменьшает.

  • Иногда результатом будет код.
  • Иногда изменение workflow.
  • Иногда prompt.
  • Иногда SQL query.
  • Иногда новая форма.
  • Иногда вообще выяснится, что ничего строить не надо.

Код перестаёт быть центром.

Не:
Product → Features → Tickets → Code

а:

Intent
→ Observed reality
→ Residue
→ Possible transformations
→ Apply
→ Observe Δ
→ Stabilize what worked

И только внутри конкретного transformation при необходимости появляется software.

Это уже совсем другой operating model.

Причём AI здесь нужен не столько для того, чтобы быстрее реализовать заранее придуманный solution, сколько чтобы делать сам цикл разрешения неопределённости быстрее:

  • посмотреть на материал;
  • найти скрытую структуру;
  • предложить несколько преобразований;
  • быстро воплотить дешёвую проверку;
  • измерить изменение;
  • выбросить неработающее;
  • стабилизировать сработавшее.

То есть настоящий AI-native development cycle выглядит не как старый SDLC + Copilot.

Он гораздо ближе к:
continuous model-building of the world.

Software — это просто один из осадков этого процесса.

И поэтому особенно смешно сейчас смотреть на компании, которые говорят «мы внедрили agentic development»: агент взял Jira ticket, написал код, тесты, открыл PR.

То есть мы создали робота, который идеально обслуживает бюрократический артефакт, придуманный из-за ограничений человеческой разработки двадцатилетней давности.

Замечательно.

Самый интересный вопрос вообще другой:
а почему существует Jira ticket?

  • Что он представляет?
  • Какая неизвестность породила его?
  • Какой residue он должен закрыть?
  • По какому наблюдаемому изменению мы поймём, что он был правильным?
  • Можно ли вообще не превращать это в ticket?
  • И вот когда AI начинает работать на этом уровне, начинается действительно новая разработка.

А следующая ступень ещё интереснее: если система хранит уже найденные transformations, evidence и результаты, то со временем ей даже не нужно снова «разрабатывать фичи». Она начинает собирать поведение из уже известных частей под конкретное намерение.

То есть путь получается примерно такой:
software development
→ AI-assisted software development — то, где сейчас почти все
→ intent-driven system evolution
→ systems that continuously reconfigure themselves around observed reality

Вот между вторым и третьим пунктом, по-моему, сейчас и лежит огромная слепая зона рынка.
Все обсуждают, насколько быстрее стало писать код.

А гораздо более неприятный вопрос:
зачем вы вообще всё ещё организованы вокруг написания кода?

2 комментария 👇
🕵️ Юзер скрыл свои комментарии от публичного просмотра...

Obligatory “Software engineering at tipping point” reference

  Развернуть 1 комментарий

😎

Автор поста открыл его для большого интернета, но комментирование и движухи доступны только участникам Клуба

Что вообще здесь происходит?


Войти  или  Вступить в Клуб