Организованное программирование | Кирилл Мокевнин

Почему нам нужны визионеры Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает). Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение? DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру. Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных. Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий. Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной. Netflix сам начал уничтожать свой успешный dvd-бизнес ради стриминга. Это особенно важный пример, потому что проблема больших компаний обычно не в том, что они не замечают новые технологии. Они часто прекрасно их видят. Проблема в том, что новое направление угрожает существующему бизнесу, который прямо сейчас приносит деньги. И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей. Знать недостаточно. Нужно быть готовым сделать из знания ставку, которая может навредить сегодняшнему успешному бизнесу. В этом и состоит одна из главных особенностей визионеров. Они не просто придумывают новые продукты. Они способны поставить под сомнение то, благодаря чему сами стали успешными. Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется. Большинство людей и организаций хорошо умеют оптимизировать существующую реальность. Улучшать продукт на несколько процентов, уменьшать затраты, отвечать на запросы клиентов, следить за конкурентами. Для работающего бизнеса все это критически важно. Но переход из одной реальности в другую почти никогда не получается как результат такой оптимизации. Для него нужен кто-то, кто в какой-то момент скажет: то, что сегодня составляет основу нашего бизнеса, завтра может вообще перестать иметь значение. И начать действовать исходя из этого раньше, чем это станет очевидно всем остальным.

Причем важно не превращать это в культ великих людей. Визионер вполне может завести компанию не туда. Чем сильнее убеждение, тем опаснее ошибка. Стив Джобс ошибался. Безос ошибался. DHH ошибался и еще много раз ошибется. Но есть фундаментальная асимметрия. Большинство людей и организаций хорошо умеют оптимизировать существующую реальность. Улучшать продукт на несколько процентов, уменьшать затраты, отвечать на запросы клиентов, следить за конкурентами. Для работающего бизнеса все это критически важно. Но переход из одной реальности в другую почти никогда не получается как результат такой оптимизации. Для него нужен кто-то, кто в какой-то момент скажет: то, что сегодня составляет основу нашего бизнеса, завтра может вообще перестать иметь значение. И начать действовать исходя из этого раньше, чем это станет очевидно всем остальным. p.s. Ход конем, Хекслет запланировал переписывание бека на go в 27 году 🙂

Почему нам нужны визионеры Недавно DHH выступил на Rails World и по полной прошелся по привычному программированию. Сказал, что писать код руками становится экономически бессмысленно, что сам почти перестал писать на Ruby, а часть нового HEY они делают на Rust, который он сам не знает и воспринимает как черный ящик для агентов (но уверен что он тут специально нагнетает). Этим он подорвал столько пердаков, что из космоса было видно зарево. Мой твиттер на неделю превратился в бесконечный срач. На Reddit появились треды в духе "уберите DHH из Rails", Aaron Patterson посвятил значительную часть своего закрывающего доклада ответу DHH. Как вообще создатель Rails может выйти на Rails-конференцию и рассказывать людям, что язык, фреймворк и даже понимание собственного кода скоро могут перестать иметь прежнее значение? Но я зайду в эту историю со стороны технического прогресса и предпринимательства. DHH самый настоящий визионер, не в смысле что он умеет и хорошо предсказывает будущее, такие люди вообще довольно часто ошибаются. Визионерство это способность увидеть большой сдвиг раньше большинства, построить вокруг него цельную картину будущего и начать действовать так, как будто эта картина уже становится реальностью. Поэтому визионеры почти всегда выглядят слишком радикальными. Когда их идеи становятся очевидными, никакого визионерства уже не требуется, тут уже можно строить планы, выделять деньги, нанимать команду и вперед на галеру. Но до этого момента все выглядит совсем по другому в глазах большинства людей. Доказательств недостаточно, огромные риски, да и текущий бизнес работает неплохо. Клиенты просят совсем другое, а профессиональное сообщество может считать новую идею откровенной чушью. Или как в данном случае, считает что человек предал конкретно их и все человечество. Практически любой большой технологический переход требует от кого-то сделать ставку раньше остальных. Apple много раз отказывалась от вещей, которые рынок считал обязательными. Стив Джобс убирал флопи диски, отказывался от физической клавиатуры в смартфоне, воевал с флешом. Каждое отдельное решение можно было критиковать, но за ними стояла цельная картина того, что ПК должен стать ближе к бытовому устройству, чем к набору технологий. Амазон годами инвестировал в инфраструктуру и рост вместо прибыли. AWS поначалу вообще выглядел почти побочным направлением интернет-магазина. Сегодня идея покупать вычисления как электричество кажется естественной, но кто-то должен был вложить в эту модель миллиарды до того, как она стала естественной. Netflix сам начал уничтожать свой успешный dvd-бизнес ради стриминга. Это особенно важный пример, потому что проблема больших компаний обычно не в том, что они не замечают новые технологии. Они часто прекрасно их видят. Проблема в том, что новое направление угрожает существующему бизнесу, который прямо сейчас приносит деньги. NVIDIA десятилетиями инвестировала в программируемые GPU и CUDA задолго до нынешнего бума генеративного AI. Дженсен Хуанг не мог знать, какой именно вид примет сегодняшний рынок. Но у него была достаточно сильная картина будущего вычислений, чтобы продолжать ставить на нее, когда рынок видел прежде всего видеокарты для игр. И обратных примеров тоже полно. Компании редко погибают потому, что вообще не знали о новой технологии. Kodak одной из первых разработала цифровую камеру. Nokia прекрасно видела развитие смартфонов. Большие корпорации обычно располагают огромным количеством исследований, аналитики и талантливых людей. Знать недостаточно. Нужно быть готовым сделать из знания ставку, которая может навредить сегодняшнему успешному бизнесу. В этом и состоит одна из главных особенностей визионеров. Они не просто придумывают новые продукты. Они способны поставить под сомнение то, благодаря чему сами стали успешными.

Сегодня в подкасте про принятие решений в компаниях. Насколько менеджеры понимают что делают и почему от этого страдает разработка: https://youtu.be/-XAWWoxHfpo?is=gMrfxTH_PzpnFVxN

Статистика по коду Хекслета Раз пошла такая пьянка, давайте я вам выдам еще кучку разной инфы. Про деньги и бизнесовую часть поговорим потом, а щас про коммиты и код. И так погнали. Хекслет не такой маленький проект, как может показаться тем, кто не погружен в нашу кухню. Это по сути lms (learning management system), где много разных биллинговых историй (покупки подписки), управление студентами, кабинет для b2b клиентов, маркетинговые инструменты, управление контентом и большая подсистема запуска и подготовки практик. И это не считая отдельного редактора (по сути ide) и множества других систем делающихся в отдельных репах. В базе порядка 300 таблиц, а про код поговорим ниже. Задач тут много от всех команд, поэтому и изменений тоже много. Активно писать через ИИ мы начали в конце 24 года, но там был долгий этап подготовки, мы типизировали проект, переходили на sdd, делали рефакторинги и всячески адаптировали проект под удобство ии. И вот когда это закончилось (плюс минус), мы рванули фигачить фичи. Поэтому я взял данные за последний год. Учитывайте что это не показывает как было до ии и после ии. Это показывает разгон на фоне улучшения харнеса и перехода в sdd. Итоги года по кодовой базе Hexlet, с октября 2025 по октябрь 2026 Автогенерацию я не считал, только реальный код. В цифрах «было» нет легаси, которое мы за год удалили. Объём кода вырос со 180 до 322 тысяч строк, в 1,8 раза. TypeScript вырос втрое. Ruby полгода стоял на месте, а с весны пошёл вверх. За год мы сделали 5 268 коммитов. Добавили 633 тысячи строк, удалили 460 тысяч. Самым активным месяцем стал сентябрь: 713 коммитов. Сейчас две трети кодовой базы написаны на языках программирования: 114 тысяч строк на Ruby и 103 тысячи на TypeScript. Ещё четверть составляют данные и конфиги: фикстуры, локали, YAML и JSON. По rails stats бэкенд вырос с 20 до 78 тысяч строк кода, а тесты к нему — с 6 до 25 тысяч. Контроллеров было 118, стало 310. Моделей было 122, стало 205. Живых таблиц в базе данных было 149, стало 228. Тестов стало вдвое больше: 1 948 против 918 год назад. Из них 1 536 интеграционных (79%) и 401 юнит-тест (21%), ещё 11 проверяют архитектурные правила. Тестовый код растёт вровень с приложением: на каждые 100 строк кода приходится около 35 строк тестов. Покрытие сейчас 92,4%. Около 60% текущей кодовой базы написано с помощью ИИ. Точно это известно для кода с середины мая: тогда мы начали коммитить через Claude, и с тех пор на ИИ приходится 83% новых строк. Если считать, что до этого доля была такой же, выходит около 60%. По коммитам с явной пометкой получается минимум 38%.

Статистика по задачам. Как повлиял ии? Заметил интересный эффект. По мере внедрения агентов, мы стали очень сильно ускорятся в скорости закрытия тасок, в какой-то момент мне почудилось что еще чуть-чуть то текучка пропадет и мы займемся, новыми большими фичами почти без отвлечения. Но как я был не прав :) Задач было столько не потому что их было столько, а потому что где-то мы не все видели и ИИ подсветил, где-то просто перестали добавлять даже в беклог, понимая что за эти задачи мы в ближайшее десятилетие не возьмемся. Когда задачки стали закрываться, а у продактов и других ребят появились коннекторы ко всем системам, мы получили такой рост количества тикетов, что уже пришлось просить притормозить. У нас бывают дни когда за раз открывается новых несколько десятков и закрывается несколько десятков. То что раньше делалось недели, проскакивает за часы. В итоге прямо сейчас задач висит столько, сколько не висело никогда. А между тем 5 агентов (только у меня) херачат сутками. У меня кстати накопилось уже материала по изменениям, буду про это писать скоро. И переписывания на го и снижение цены лида и улучшение аналитики. Ух сколько всего. Цифры Посчитал все тикеты разработки, фидбека и контента в Трекере с октября 2025 по сентябрь 2026. За год создано 1340 тикетов, закрыто 1032. Точка отсчёта — 14 мая: в этот день в репозитории появился первый коммит, написанный вместе с Claude. Сколько создаём и закрываем в месяц • Октябрь–апрель: создавали около 70, закрывали около 50. • Июнь–август: создаём около 105, закрываем около 105. • Сентябрь: создали 422, закрыли 222. Как быстро закрываем • До мая тикет жил до закрытия в среднем от 3 недель до 2 месяцев. Начиная с мая — 5–6 дней. • Доля тикетов, закрытых за неделю, выросла примерно с 20% до 35–48%. Исключения — июнь и сентябрь. Коммиты • До мая было около 400 в месяц, в сентябре — 713. У 87% сентябрьских коммитов соавтор — Claude. Выводы 1. Тикеты закрываются примерно в 6–10 раз быстрее, чем до мая. 2. Летом мы впервые закрывали не меньше, чем создавали. До этого очередь только росла. Аппетиты растут во время еды :)

Плановое обслуживание кода Даже если вы настроили у себя процесс разработки, в котором все делают агенты, есть задачи которые они не могут выполнить качественно в моменте. В основном это связано с тем, что они фокусируются вокруг тех изменений с которыми работают прямо сейчас. Причем каждое конкретное изменение может выглядеть допустимо, но если посмотреть на дистанции, то будет видна деградация, постепенное расползание плохих практик, дублирование, отсутствие обобщения там где оно напрашивается. Поэтому в процесс нужно включать задачи по расписанию, которые имеет смысл запускать раз в неделю или месяц. Ниже расскажу что я делаю сам с помощью каких команд или скилов. Эффективность агента /doctor (Claude Code) — раз в месяц проверяю здоровье агентского окружения: конфигурацию, неиспользуемые скилы и MCP, медленные хуки, проблемы с permissions и другие накопившиеся проблемы. Заодно помогает освобождать память от устаревшего и лишнего. /fewer-permission-prompts (Claude Code) — анализирует историю работы и предлагает, какие часто используемые безопасные команды стоит добавить в allowlist, чтобы агент меньше отвлекал подтверждениями. /run-skill-generator (Claude Code) — периодически пересобирает знания агента о том, как поднять и проверить проект, чтобы /run и /verify не опирались на давно устаревшие команды. /retro (Matt Pocock Skills) — формально не плановая задача. Запускаю после сессии, где агент заметно буксовал, делал лишние шаги или его приходилось несколько раз исправлять. Скил анализирует, что можно поменять в инструкциях, автоматических проверках и окружении, чтобы эта проблема больше не повторялась. Качество кода /simplify (Claude Code) — прохожусь по активно меняющимся частям проекта. Ищет дублирование, лишние абстракции, возможность переиспользовать уже существующий код и просто слишком сложные решения. Удобно запускать раз в неделю по нескольким наиболее активно меняющимся каталогам. /code-review (Claude Code; у Matt Pocock также есть одноимённый skill) — отдельный проход по изменениям за неделю на корректность, качество кода и возможные упрощения. Обычный review конкретного изменения такую накопительную деградацию часто не замечает. /improve-codebase-architecture (Matt Pocock Skills) — ищет места, где архитектура постепенно поплыла: слишком мелкие модули, неудачные границы, сложные интерфейсы, размазанное по нескольким местам поведение. Можно натравливать прямо на конкретные слои, типа посмотри сервисы Чтобы не потерять это добро, я включил в его книгу паттернов агентной разработки Кстати есть неочевидный нюанс. По идее все это надо стартовать автономно, но автономный запуск где-нибудь на github actions подразумевает работу не от подписки конкретного пользователя, а по апи. А хорошие модели чертовски дороги в таком варианте использования, поэтому пока по старине, стартуем все это ручками. p.s. Поделитесь своими фишками, что запускаете вы? Telegram | YouTube | AI Клуб | Внедрение AI

Выпуск опубликован, можно смотреть и слушать. Сегодня в подкасте создатель Вастрик Клуба Василий Зубарев с которым мы обсуждаем сообщества, контент и конечно же программирование https://youtu.be/VwNYYIFlahY?is=he5vbWEAqJ3OxrgL

Костные наушники Под каждым видео коммент, что за наушники ты носишь? Это костные наушники компании shokz, которые, насколько я знаю, сделали по технологии изначально созданной для слуховых аппаратов. Они не вставляются в уши, а прижимаются снаружи передавая звук через вибрацию. Зачем это надо? Мелкие наушники-вставки это всегда проблема для меня. Я постоянно их теряю, батарейки не хватает на весь день если активно разговаривать, их надо вынимать/вставлять, от них устают уши и они мешают слышать что происходит снаружи когда это важно (например на велике катаешься). С костными в этом смысле приятнее. Их можно в принципе никогда не убирать, а если надо убрать они легко оказываются на шее. У них намного дольше работает батарейка, а я много говорю по телефону и air pods мне тупо не хватало на день. Из минусов ниже качество звука из-за самой природы передачи. А если снаружи шумно или ветер, то в них очень плохо слышно. Иногда приходится прямо затыкать ухо, чтобы услышать. Тоже самое касается микрофона, если ветер, то тебя уже не слышат нормально, поэтому для себя я купил версию с выносным микрофоном. Ее вы видите в видео :) Плюс у меня есть отдельный вариант (на картинке) для плавания. А еще у каждого в семье по такому наушнику. Кстати, они очень популярны у нас тут p.s. Вы пробовали?

Статистика участия в опенсорсе Активно разрабатывая я регулярно наыткаюсь на баги и не доработки в используемых либах. Мне всегда было интересно помогать авторам улучшать их либы, но не всегда была возможность это делать, хотя я так или иначе это делал. А тут иишка конечно развязала руки. После очередной сессии дебага и понимании, что бага в либе, я взял за правило помимо локального фикса отправлять пулреквест в саму либу. И вот какая у меня накопилась статистика за 30 дней: За последние 30 дней отправил в чужие проекты 31 пулреквест. Из них 17 влиты (55%), 12 ещё ждут ревью, 2 закрыты без мержа. Куда влиты (17): - stathis-alexander/boba: 9 (из 10, один закрыт без мержа) - Shopify/rbi-central: 5 (из 6, один ещё открыт) - Shopify/tapioca: 1 - ElMassimo/vite_ruby: 1 - lostisland/faraday: 1 Ещё открыты (12): - hougesen/mdsf: 2 - jedrzejboczar/devcontainers.nvim: 2 - Shopify/rbi-central: 1 - brianhuster/live-preview.nvim: 1 - RubyMoney/money-rails: 1 - WeAreFarmGeek/diplomat: 1 - bkeepers/dotenv: 1 - kjvarga/sitemap_generator: 1 - rudderlabs/rudder-sdk-ruby: 1 Как видите тут все подряд от типизации (очень много про тулинг для типов в ruby) и http либы до работы с докером вимом и генератором сайтмапов. Причем не всегда я слал сразу пулреквест, если это фича, то обычно сначала спрашивал в ишьюсе как на это смотрит автор. Ну и везде очень позитивная реакция. Иногда, кстати, пулреквест уже есть от другого человека и я просто докидывал туда контекст. Был один кейс, где мое предложенное решение в комменте понравилась ментейнеру больше и он попросил автора пулреквеста поправить его код (inertia.js). А какая стата у вас? Telegram | YouTube | AI Клуб | Внедрение AI

Банда четырех для эпохи агентов Количество паттернов по тому, как эффективно работать с ИИ, дошло до точки, когда их уже нужно собирать, фильтровать и классифицировать. Как ни странно, чего-то подобного в сети нет даже на английском (в том виде как мне бы хотелось), поэтому пришлось делать самому. В общем, встречайте, возможно, это первая книга, которую я допишу до конца: Agentic Design Patterns. Что это такое? Каталог паттернов агентного программирования в духе «Банды четырёх». Каждый паттерн это проверенное решение повторяющейся задачи при работе разработчика с ИИ-агентом: как поставить задачу, дать контекст, проверить результат и организовать проект. Сейчас в книге уже 32 готовые главы: 27 паттернов и 5 антипаттернов. Они разбиты на шесть больших разделов: постановка задач, SDD, работа с контекстом, верификация, организация проекта и антипаттерны. Например, там уже есть Four Phases (Explore → Plan → Code → Commit), Context Engineering, OpenSpec, Writer–Reviewer, TDD with Agent, Isolated Parallel Work, Executable Guardrails и другие практики, которые постепенно становятся стандартным набором при работе с coding agents. Здесь же про SDD и антипаттерны. Помните, я писал статью про преждевременную спецификацию? Именно с нее все началось. Книга, по сути, сборник того хорошего, что появляется в сети, плюс какие-то мои мысли и попытка привести всё это к общей системе. Причем фокус именно на том, как разработчик работает с агентом, а не на устройстве самих агентных систем — orchestration, routing и прочая внутренняя кухня агентов сознательно вынесены за рамки. Все это open source, книга уже ведется на русском, английском и испанском, а участие всячески приветствуется! Telegram | YouTube | AI Клуб | Внедрение AI

Главное правило принятия архитектурных решений Когда-то давно в одной из книжек я прочитал такую фразу: "Defer decisions until the last responsible moment". Не то чтобы я сразу понял и проникся, но со временем, этот принцип стал важной частью моих правил работы. Его популяризировали Mary и Tom Poppendieck в книге Lean Software Development: An Agile Toolkit. Суть принципа в том, что необратимые или дорогие в изменении решения стоит принимать не "как можно раньше", а настолько поздно, насколько это безопасно, то есть когда дальнейшее откладывание уже начнет закрывать важные альтернативы. В архитектуре это обычно формулируют примерно так: > Delay architectural decisions until the last responsible moment Важно именно responsible, а не possible. То есть это не "тянуть до последнего", а сохранять пространство вариантов, пока появляется новая информация. Приведу пример. Когда Хекслет только стартовал и мы запустили практику в браузере, то на обслуживание этой системы уходил один сервер. Со временем количество студентов росло и нагрузка на него сильно выросла. Причем речь идет не о просмотрах страниц сайта, одна практика это полноценный контейнер с кучей сервисов, терминалами, самим редактором и запуском практик, по ресурсам это очень много. Но на тот момент мы не до конца понимали, как лучше распилить эту систему и каждый раз когда упирались ограничения, то просто переходили на все более мощный сервер. И только спустя несколько лет эксплуатации этой системы, мы наконец-то окончательно поняли как лучше ее развивать с учетом большого количества очень специфичных проблем для такой задачи. Мы могли начать строить распределенную систему гораздо раньше. Технически для этого уже были причины. Но у нас еще не было знаний, необходимых для хорошего решения. Более мощный сервер покупали нам не только производительность, но и время на то, чтобы понять систему. Вообще тема проектирования красной линией идет через все мои публикации, но я все равно получался сапожник без сапог, потому что занимаюсь образованием и по проектированию систем у меня не было никаких материалов, только по архитектуре кода. Давно собирался это исправить и наконец-то это произошло, я в соавторстве с очень крутым человеком из большой известной международной компании подготовил масштабный курс по системному дизайну. Гляньте программу, думаю вам понравится. Ближайший запуск 21 сентября, сама программа идет 4 месяца. Telegram | YouTube | AI Клуб | Внедрение AI

Сегодня у меня в гостях Александр Поломодов, который до недавнего времени был одним из проектировщиков AI SDLC трансформации в Т-банке. Мне давно было интересно узнать его мнение по тому, как трансформируются компании и разработка в будущем в гораздо более широком смысле чем просто SDD. Саша пропускает через себя много white papers и держит руку на пульсе. https://www.youtube.com/watch?v=uImPHIhHzFs

Ассемблер неправильная абстракция Каждый раз когда заходит речь о повышении уровня абстракции, в разговоре всплывает ассемблер в стиле "когда то мы писали на нем, а теперь не пишем". Особенно часто это повторяют сейчас в эру AI. Честно говоря, мне это никогда не казалось правильным сравнением и кажется я могу объяснить почему. Переход от ассемблера к языкам высокого уровня был переходом от слишком низкого уровня завязанного на технические детали, к конструкциям, которые которые задают базис для построения программ практически любой сложности. И вот этот уровень принципиально не менялся десятки лет. Менялись языки, платформы, библиотеки и способы организации кода, но сам программист продолжал работать примерно с теми же конструкциями. Программа на современном языке устроена концептуально почти так же, как программа пятьдесят лет назад. Но после этого характер повышения абстракции изменился. Мы больше не поднимались от технической реализации к естественной модели вычислений. Мы пытались подняться от программирования к описанию намерения, того, что должна делать система, и автоматически получить реализацию. Cobol был одной из первых попыток подняться от описания вычислений к описанию бизнес-намерений. Предполагалось, что программы на похожем на английский языке смогут читать и, возможно, писать сами специалисты бизнеса. Но понятный синтаксис не устранил сложность программирования. Для точного описания поведения все равно понадобились переменные, условия, циклы, структуры данных и процедуры. В результате cobol стал успешным языком для бизнес-систем, но не стал языком самого бизнеса, так как писали на нем по-прежнему программисты. Успешные примеры появились там, где намерение удалось ограничить конкретной и хорошо формализованной областью. Хорошие примеры это регулярки, sql, html/css или terraform. Это конечно еще не бизнес уровень, но уже что-то. Для разработки произвольных программ такую модель создать не получилось. Как только языку намерений требовалось описывать нестандартное поведение, в нем появлялись все привычные конструкции. Постепенно он снова превращался в обычный язык программирования, только с другим синтаксисом и новым набором абстракций. Это хорошо видно на примере BDD. В изначальной идее сценарии на языке, понятном бизнесу, должны были стать общей спецификацией системы и одновременно основой для автоматической проверки. Но довольно быстро выяснилось, что реальные сценарии либо остаются понятными, но описывают только верхний уровень поведения, либо становятся достаточно точными для исполнения, но обрастают техническими деталями и фактически превращаются в еще один код. А между сценариями и работающей системой все равно остается большая часть логики, которую кто-то должен спроектировать и реализовать. Я не думаю, что AI решает эту проблему. Спецификация произвольной системы либо остается неполной, и тогда множество неописанных решений агент принимает самостоятельно, либо обрастает правилами, исключениями, состояниями и способами обработки ошибок и по сложности начинает приближаться к самой программе. AI может значительно увеличить расстояние от намерения до кода и избавить нас от ручной реализации многих деталей, но он не создает универсального уровня абстракции, на котором можно точно описывать любые системы и при этом не программировать. Я был бы рад ошибиться, но пока не вижу предпосылок. А как вы думаете?

Уровни зрелости ai в sdlc Несмотря на то, что все кричат про ИИ, в большинстве компаний реальный уровень внедрения это "мы с клодом кодим парой". Это вроде как неплохо, но уже делают все так или иначе (отрицателей в расчет не берем). А дальше что? Общей модели не придумали, но есть плюс минус устоявшийся взгляд на уровни зрелости: 1. AI как личный инструмент. Разработчик работает с coding-агентом: пишет код, тесты, разбирается в кодовой базе, делает рефакторинг. 2. AI как часть командной среды. Агент получает нормальный контекст проекта: правила, документацию, архитектуру, историю решений, задачи. Появляются общие инструкции, skills, harness, SDD и воспроизводимые способы работы вместо "каждый промптит как умеет". 3. AI внутри SDLC. AI подключается не только к коду, но и ко всему процессу: тикетам, документации, CI/CD, code review, мониторингу, логам и остальным инженерным системам. Появляются устойчивые воркфлоу, которые проходят через несколько этапов разработки. 4. Агентные процессы. Агент самостоятельно выполняет целые куски работы: берет задачу, исследует код, реализует, проверяет, открывает PR; расследует инцидент; обновляет документацию. Человек все больше задает цель, ограничения и принимает результат. 5. Самоулучшающийся AI SDLC. Работа агентов измеряется эвалами и продуктовыми/инженерными метриками. Harness, контекст, модели и воркфлоу постоянно меняются на основании данных. Компания оптимизирует весь AI-конвейер разработки. Все это может выглядеть идеализированно, но элементы разных уровней уже постепенно проникают в реальную разработку. То, что еще вчера казалось фантастикой, сегодня вполне работает. Не идеально конечно, но никто и не обещал легких путей. А теперь самое интересное. Какие шаги нужно предпринять чтобы двигаться по этим уровням? Например нужен контекст через раги и mcp: интеграция всех коммункаций (чаты/почты/тикеты) интеграция базы знаний интеграция сервисов (от sentry до grafana) В лучшем случае это встроено в корп системы типа microsoft, google workspaces, yandex 360 (они только интегрируют), в худшем надо самостоятельно делать раги и писать mcp. Кто-то уже прошел этот этап, но многие еще не дописали. Где-то параллельно должно развиваться SDD и куча разных воркфлоу начиная от код ревью, заканчивая автономным расследованием сбоев (желательно автономным). Причем проблема не всегда в том чтобы дать доступ, а в том чтобы дать его в нужном объеме и нужным людям, иначе что-нибудь лишнее утечет или "ой, снесло базу данных". Так получилось, что ко мне стало обращаться все больше и больше компаний (особенно после моего летнего трипа), на эту тему, поэтому я от "пишу про ai в sdlc" пришел к "внедряем ai в sdlc". Встречайте праксор, компанию, которую мы организовали с основателем ScrumTrack Асхатом Уразбаевым, который имеет прямое отношение к Agile-трансформации многих крупных российских бигтехов и энтерпрайзов. В общем если ваша компания хочет ускориться и сделать все правильно, то пишите, мы с удовольствием станем вашим надежным партнером в этом непростом деле (можно через заявку на сайте, можно в директ канала) p.s. На каком уровне развития сейчас ваша компания и как идет продвижение?

Редкий случай, когда подкаст офлайн в студии и я гость 🙂 Рассказываю про свой путь программиста и предпринимателя, травлю байки про индустрию, рассказываю про эдтех и Хекслет. Наслаждайтесь https://www.youtube.com/watch?v=EQSzqxqgi50

В подкасте снова гости! В этот раз с Сергеем Бережным обсуждаем Performance Review в целом и конкретно в яндекске. https://www.youtube.com/watch?v=ceA9zUWp7IU Как вы относитесь к этой процедуре? Без нее лучше или хуже? Telegram | YouTube | AI Клуб

Сетапим окружение с нуля Коротко: mise умеет сетапить не только версии языков под проект, но и настраивать все окружение, по сути упрощая настройку как машины так и проекта до буквально одного файла. Я буквально на этой неделе перевел на него и свои dotfiles (https://github.com/mokevnin/dotfiles) и проекты. Кто-то скажет, нафига мне это надо у меня все в докере. У меня на этот счет два соображения, даже если у вас язык в докере, снаружи часто есть разного рода cli, которые нужны всем (и нам и агентам). Сюда относятся cli агенты, терминалы, docker compose, kube, helm, git, google cloude, oh my zsh и еще тыща приблуд, которые хочется сетапить. И второе, есть немало людей, которые разрабатывают не только готовые приложения, но и библиотеки, например, я работаю с большим количеством опенсорса, где докера нет и нафиг не нужен (с ним тупо сложнее, а стейта там нет). Напомню, что mise (придеший на замену asdf) это, пожалуй, самый классный способ управлять версиями языков в конкретном проекте. Он работает универсально для любого стека и ставит ровно то что нужно чтобы работал конкретный проект делая сетап независимым. В принципе это давно существующая штука и под каждый язык есть менеджер версий (не путать с пакетным менеджером). Но mise пошел дальше и сделал декларативный способ указывать что засетапить, какие симлинки создать и так далее. Причем он не пытается построить абстракцию поверх существующих решений (как некоторые devops тулзы), в нем явно описывается что откуда ставить. А уже дальше, когда будет выполняться настройка, mise сам определит что конкретно запускать на текущей системе. Если у нас mac, то он не будет запускать apt, но запустит brew. Кусочек файла mise.toml:

[settings]
idiomatic_version_file_enable_tools = []
dotfiles.root = "~/dotfiles"
dotfiles.default_mode = "symlink"

[tools]
node = "26.7"
ruby = "latest"
pnpm = "latest"
overmind = "latest"
caddy = "latest"
docker-cli = "latest"
docker-compose = "latest"
fzf = "latest"

[bootstrap.packages]
"brew:libpq" = "latest"
"brew:vips" = "latest"
"apt:git" = "latest"
"apt:libpq-dev" = "latest"
"apt:libvips" = "latest"

[bootstrap.repos]
"~/.oh-my-zsh/custom/plugins/you-should-use" = { url = "https://github.com/MichaelAquilina/zsh-you-should-use.git", ref = "master" }

[dotfiles]
"~/.config/nvim" = "nvim"
"~/.config/mise/config.toml" = { source = "mise.toml", mode = "symlink" }

В общем я попросил клод проанализировать мою систему и проекты. В результате он добавил mise.toml в несколько основных проектов и полностью пересобрал мои dotfiles, удалив кучку всяких скриптов и make тасков. Заодно я попросил его подсказать, что еще классного есть в мире cli что стоит поставить. Он нашел десяток полезнях, которые я теперь юзаю. Например он поставил какую-то прикольную штуку, которая меняет поиск через "вверх" в терминале, когда жмякаешь эту кнопку, то он сразу показывает список всего что было набрано до этого.

Адаптация проекта под LLM Есть два подхода к организации агентного программирования в проекте. Первый это все описывать и заставлять агентов делать все как надо, второй - менять проект под ожидания ии. Обычно в проектах делают и то и то, но сейчас я бы хотел акцентировать внимание на втором. Чем дольше живет проект, тем больше в нем косяков в именовании (чего угодно), кастомных решений и самопальных либ, разных подходов в реализации одного и того же (накопленных за годы). А еще просто банально устаревшие штуки, которые уже давно никем не используются. Раньше мы со всем этим жили, потому что времени на исправления нет, но где-то год назад начали массовые рефакторинги, которые сейчас почти закончены. Правда мне регулярно возражают, что вот у нас так а llm хочет сильно по другому или llm делает фигню. Это правда, llm может делать фигню, но далеко не всегда потому что она училась только на говнокоде. И модель и харнес и много чего влияет, но, глобально, модель учится на типовом коде и ее решения достаточно типовые, поэтому в большинстве случаев можно пренебречь какими-то своими ноухау и быть как все. Что не отменяет элементов, которые приходится делать по другому. Есть и другой поинт, что модель поменяется и захочет делать по другому. Не захочет потому что обучение идет на одних и тех же данных, которых становится только больше. А деградировать ей просто не даст рынок, тогда все уйдут туда где как минимум не хуже. Ключевые вещи которые мы сделал: Там где получилось, привели имена в домене к общепринятым (мы мучали llm отдельно от проекта на тему того какой понятийный аппарат используется в образователей сфере. Может показаться что это фигня, но нет, есть немало слов, про которые мы не то чтобы сильно знали, потому что все это было заложено лет 12 назад, а с тех пор многое утекло. Иногда наше именование не совпадало с общепринятыми (международными) понятиями, а иногда просто все так поменялось, что потерялось изначальное значение. Раньше мы даже взяться за это не могли, а тут без проблем, даже учитывая что один такой пулреквест может тянуть изменения в сотнях, а то и тысячах файлах (спасибо типам и тестам за контроль). Привели в порядок имена слоев внутри кода, у нас типами называлось то что было не типами. В общем привели в порядок имена сервисов, dto и других штук. Иначе llm регулярно делало не те выводы. Да и в целом лучше развели по слоям и уточнили барьеры абстракции, когда есть четкие правила, что может и не может быть входом или выходом на каждом уровне. Например внутрь сервиса может поступать только структура, модели появляются внутри, но не снаружи и тому подобное. Когда единообразие стало повсеместным, генерируемый код стал максимально предсказуемым. Иишка смогла найти готовые решения, благодаря которым мы выкинули немало самопала. Это может выглядеть контритуитивно, но несмотря на то что ии позволяет нахерачить все самим, лучше брать готовые промышленные решения (популярные и стандартные). Это касается как фронтовой части (полностью ушли на Mantine), где теперь мы получаем почти 100 процентный уровень генерации в one shot режиме, так и решения для бекендовых задач, например подписок, которое требует определенной модели данных и предоставляет готовые общепринятые сущности. Плюс постепенное обрастание спеками, проработанными тикетами, глоссарием, adr, коммитамии с хорошими сообщениями, все это вместе дало возможность ии гораздо быстрее и точнее понимать что происходит. На активный рефакторинг ушло чуть больше года, сейчас мы тоже продолжаем доводить, но уже точечно, потому что ключевые вещи поправлены и иишка достаточно хорошо понимает проект. Следующий шаг, это создание и добавление детерминированных инструментов стат анализа, которые чекают достаточно высокоуровневые вещи.

Прошлый раз с лайвкодингом породил так много вопросов, что пришлось записать еще один выпуск. Он состоит из двух больших тем: Мой сетап. Как устроен мой воркфлоу кодинга: терминалы, комбо, слепая печать, навигация использование специализированных тулов. SDD. В прошлый раз не все заметили, что кроме мелких тикетов, был один, который я делал по spec driven development, поэтому в этот раз мы прямо сетапим воркфлоу Matt Pocock и через него делаем одну задачку https://www.youtube.com/watch?v=CVJ01XSmHEY