Подробно мою (и Opus) модель сверхинтеллекта можно прочитать здесь. Детально хочу разобрать три теоремы, которым будет следовать сверхинтеллект - потому, что эти ограничения выполняются для любой информационно-обрабатывающей системы в физической вселенной.

Сверхинтеллект не может реагировать на каждое отклонение - это дороже, чем позволить отклонению быть.

Автопилот Tesla не корректирует траекторию машины каждую миллисекунду, хотя технически мог бы. Если бы он это делал, машину бы трясло - все микроотклонения компенсировались бы микрорулевыми движениями. Ехать было бы невозможно.

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

В руководстве ровно то же самое. Менеджер, который реагирует на каждое колебание метрики - это Tesla, которая пытается компенсировать каждую неровность асфальта. Машину трясёт. Пассажиры болеют. Батарея садится за два часа.

Сверхинтеллект не может относиться к обратимому и необратимому одинаково - цена ошибки структурно разная.

Ты можешь удалить ветку. Можешь удалить коммит через reset. Можешь удалить файл. Всё это обратимо - есть reflog, есть история, есть пушы на remote. Пять минут, восстанавливается.

А можешь удалить репозиторий. Force push в main. Revoke ключа, которым шифровался backup. Удалить S3-бакет с production-данными без версионирования. Эти действия - другого класса. Не «сложнее восстановить» - а структурно невосстановимы или восстановимы только через признание катастрофы.

Любой инженер, у которого был хоть один инцидент, знает эту разницу нутром. Есть rm file и есть rm -rf /. Они оба - команда rm. Но это разные действия, требующие разной процедуры.

В управленческих решениях - то же. Но управленческой практики, отделяющей rm file от rm -rf /, почти нигде нет. Все решения идут через одно и то же ревью, с одними и теми же сроками, в одной и той же очереди. И раз в полгода кто-то делает rm -rf / в карьере или в команде.

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

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

В середине квартала приходит руководитель на уровень выше: «Эту фичу нужно выкатить к понедельнику. Тестов сделать не успеваем. Это исключение, один раз».

Вы уступаете. Правильно ли? На эту конкретную фичу - возможно, да. В конкретном квартале - может быть, оправдано. Но посмотрите, что происходит с правилом.

Вся команда теперь знает, что правило «фичи с тестами» отменяется, если нажать достаточно сверху. Через три недели приходит руководитель отдела дистрибуции/внедрения: «Клиент требует к четвергу». Через две недели - маркетинг: «К запуску кампании». Через месяц тесты пишут только на то, что совсем не горит. То есть почти никогда.

Вы не отменили правило. Вы просто показали, что оно отменяемое. В нашей среде это - одно и то же.

Единственный ответ - правило, которое у вас нет полномочий отменить. Не «я решаю для каждого случая», а «у нас релиз без тестов не выпускается, и я технически не могу подписать». Это выглядит как утрата гибкости. На самом деле - это единственный способ сохранить правило в среде, которая учится на каждом вашем решении.

Распожаризация невозможна, пока работают поджигатели

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

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

Всех участников объединило одно. Из памятки по факторам работоспособности у всех на крайние низких значениях был сон. Обменялись друг с другом идеями и приемами, уделили внимание улучшению сна. Все отметили улучшение общего состояния, снижение стресса, повышение работоспособности. И за это были благодарны. Но дальше направили свои новые силы на бег вокруг пожаров.

Тогда я этого не понял. Если у вас всё горит, то может быть стоит потратить силы на то, чтобы не допускать пожаров? Но теперь я осознал, что руководство по распожаризации отвечает на 1 и 3 теоремы выше, нащупав часть математического оптимума.

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

Мы читаем умные книги. Смотрим крутых практиков. Внедряем сложные системы управления проектами. Настраиваем учет задач и времени. И при этом работаем в организациях, которые требует от нас нарушения всех трёх ограничений одновременно.

Нарушение 1. От вас ждут реакции на каждое отклонение — потому что организация не определила, какие отклонения требуют вмешательства, а какие нет. У вас нет границ допуска.

Симптом: «всё срочно».

Нарушение 2. Вы принимаете решение о найме/увольнении и решение о цвете кнопки с одинаковой скоростью — потому что они идут в одной очереди.

Симптом: «я за пятницу согласовал переход на новый фреймворк, увольнение сотрудника и название релиза».

Нарушение 3. Вы 10 раз решаете один и тот же вопрос - потому что в организации нет правил, есть только прецеденты.

Симптом: «в понедельник то же самое, что было в прошлый понедельник, но решаем с нуля».

Вот почему тайм-менеджмент не помогает. Он не трогает корень.

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

Если ты такой умный, то как не работать на износ?

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

Идеального решения нет. Но можно облегчить себе жизнь уже с завтрашнего дня. Три простых действия, которые разгрузят наш с вами пока ещё не сверх, но всё-таки интеллект.

Опишите на бумаге три полосы “скоростей” решения. Для каких типов решений вы сознательно не реагируете в первые сутки. Не как «я молодец и терплю», а как осознанная политика. Тут как с защитой от мошенников (что телефонных, что магазинных) - если требуют принять решение здесь и сейчас, то значит пытаются манипулировать.

Как говорит мой знакомый безопасник: когда от меня требуют принять решение, то думать о нём я начну не раньше завтрашнего дня.

Заведите вторую очередь - для необратимых решений. Они не идут в общем потоке. Они ждут отдельного окна. Пятница, 10:00–12:00, только необратимые. Что делать, если там уже новые пожары? Горели вчера, будут гореть завтра. А в это окно вы занимаетесь важным. Каждую неделю. Защищайте свое право на подумать.

Это как с капиталами. Копим их годами и десятилетиями. Растратить можно за один вечер в казино или на бирже. Поэтому важнее не принять одно фатальное решение, чем принять десять обратимых.

Найдите три решения, которые вы принимали больше трёх раз. Напишите правило. В следующий раз применяйте его без пересмотра. Вас убеждают, что правило устарело и его нужно поменять? Хорошо, это задача другой скорости. На неё должно быть выделено отдельное время и не раньше, чем через 48 часов.

Честно - это не спасет, но даст 20–30% облегчения. Корень проблемы в “чайка менеджменте” и бесконечном тушении кризисов. Но обозначить настоящую проблему - не половина решения, но начало пути к реальным изменениям.

Сверхинтеллект тоже будет перерабатывать в среднем менеджменте средней российской организации

В прошлую пятницу я утвердил ещё один MVP в Figma. На выходных отдыхал. Даже не заглядывал в рабочие чаты. Никто не сгорел и не умер.

Нет, я не победил систему и не превратил её в бочку с вином. Но перестрал растворяться в ней.

Задачи-пожары прилетают всё так же часто, но решаются в порядке “скоростных очередей”. И знаете что? За прошлую неделю только одна неожиданная задача требовала реакции в течение трех часов. 12 были распределены на следующие дни. 7 и вовсе ушли в мусорку, стоило отложить их на пару дней.

Коллеги и начальство знают, что если я сказал, что решение будет принято в четверг вечером, то бессмысленно требовать от меня ответа раньше, чем в четверг 17 часов. Это мое окно особо важных решений - четверг с 14 до 17. Даже под угрозой увольнения я сохранил правило. Работать продолжил. Это отдельная история.

Потому что даже сверхинтеллект выгорит в среднем менеджменте средней российской организации. Не потому, что он не имеет степени MBA или не успел овладеть практиками PMBOK 8. Потому что такая среда. Потому что он эффективен и на нём будут ездить, пока не сломают. Потому что учитывать ограничения заинтересован сотрудник (мы с вами), а не организация.

Поэтому теперь в моей очереди работ на первом месте стою я. И учитываю свои ограничения, которые не сможет преодолеть даже сверхинтеллект.

Приветствую вас, коллеги и соратники в мире управления проектами! При разработки программного обеспечения существует множество подходов, методологий к управлению IT проектами. Среди них топ места занимают Scrum и Kanban. Сегодня освежим наши знания об этих двух методах, и принципах их применении.

Скрам: Кратко о главном

Scrum — это фреймворк для управления проектами, который фокусируется на гибкости и адаптации к изменениям. Это одна из основных методологий по управления проектами из семейства Agile.

Основные элементы Скрам:

Роли:

• Product Owner: отвечает за создание и приоритизацию бэклога продукта.

• Scrum master: помогает всей команде следовать процессам скрам и устраняет препятствия, которые могут мешать работе.

• Developers: группа специалистов, которые выполняют работу по созданию продукта.

Артефакты:

• Бэклог продукта: список всех задач и требований, которые должны быть выполнены.

• Бэклог спринта: задачи, выбранные для выполнения в текущем спринте.

• Инкремент: завершенная работа за спринт, которая добавляет ценность продукту.

События:

• Спринт: имеет фиксированный период (обычно 2-4 недели), в течение которого команда работает над задачами.

• Планирование спринта: встреча для определения задач, которые будут взяты в работу и выполнены входе спринта командой.

• Ежедневный стендап(daily-ки): короткие ежедневные встречи для обсуждения прогресса и препятствий.

• Обзор спринта: встреча для демонстрации завершенной работы(демо) заинтересованным сторонам.

• Ретроспектива: встреча для анализа прошедшего спринта и выявления возможностей для их улучшения.

Канбан: Кратко о главном

Канбан — это метод управления процессами, который акцентирует внимание на визуализации работы, ограничении незавершенных задач и постоянном улучшении. Это одна из методологий по управления проектами из семейства Agile.

Основные элементы Канбана:

Визуализация вашей работы:

• Использование доски Kanban, на которой отображаются задачи в виде карточек, перемещающихся по колонкам доски, имеющие различные стадии/статусы (к примеру, "Todo", "In progress", "In QA", "In review", "Done").

Ограничение незавершенной работы(WIP):

• Установка лимитов на количество задач(WIP лимитов), которые могут находиться в каждой колонке одновременно, чтобы предотвратить перегрузку команды и улучшить поток работы.

Постоянное улучшение:

• Регулярный мониторинг и оптимизация процессов, использование метрик для оценки производительности, результатов и выявления узких мест, горлышек.

Давайте сравним Scrum и Kanban по различным атрибутам, чтобы знать основные отличия, между этими методами управления (помним, скрам — это фреймворк, а канбан — метод организации и управления задачами). Таблица ниже показывает разницу между Scrum и Kanban.

Разница между Скрамом и Канбаном: Памятка для менеджеров проектов

1. Work cycle

Scrum: Итерации. Scrum включает спринты, в течение которых команда следует циклу plan-do-check-act (PDCA).

Kanban: Continuous flow. В Канбан, как только одна задача завершается, команда сразу берется за следующую.

2. WIP - Work In Progress

Scrum: WIP лимиты устанавливаются командой Scrum для каждого спринта, и новая работа берется в работу только после завершения всех текущих задач.

Kanban: WIP лимиты в Канбан означает количество задач, которые могут одновременно находиться в одной колонке в течение заданного промежутка времени на конкретном этапе работы.

3. Inspect-Adapt (Empiricism)

Scrum: Каждый спринт — это возможность для инспекции и адаптации.

Kanban: Нет конкретного механизма для инспекции и адаптации. Работа движется в одном направлении.

4. Transparency (Empiricism)

Scrum: Артефакты в Scrum включают product backlog, sprint backlog и increment. Соответственно обеспечить прозрачность требований, реализации и результатов.

Kanban: Никаких специфических артефактов для прозрачности. Канбан-доска обеспечивает некоторую прозрачность. Многие команды используют бэклог продукта (из Scrum) в сочетании с досками канбана.

5. Planning

Scrum: Конкретный митинг для планирования спринта и дня — sprint planning и daily scrum.

Kanban: Нет четких указаний по планированию работы. Команды самостоятельно выбирают свой ритм и подход к планированию.

6. Responsibility/Structure

Scrum: Ответственность в Scrum - владелец продукта фокусируется на бизнесе, разработчики на реализации и Scrum мастер на устранении препятствий и имплементации Скрам. Вся работа выполняется кросс-функциональной командой.

Kanban: В канбане нет такого разбиения как в Скраме: владелец продукта, разработчики и т. д. Предполагается, что над задачами работает группа людей, они двигаются по флоу, пока не переходят в задачу со статусом done. И команда может быть не кросс-функциональной.

7. Stakeholder/Customer

Scrum: Скрам предполагает активное участие заинтересованных сторон и клиента — по крайней мере, один раз за спринт во время мероприятия sprint review(демо).

Kanban: Канбан не дает возможности привлечь заинтересованные стороны или клиентов. Некоторые команды применяют подход “обзора проделанной работы” раз в месяц.

8. Daily meetings

Scrum: Daily в скраме — это короткая ежедневная встреча команды, обычно длится 15 минут, на которой участники обсуждают, что они сделали, что планируют сделать и какие препятствия у них есть. Цель — координация работы и повышение прозрачности.

Kanban: Daily в канбане — стендап не является частью практик Канбана, но все равно можно проводить эту встречу. Стендап можно считать одним из способов реализации принципа improve continuously. Вопросы на них лучше задавать с фокусом на задачи.

9. Поток работы

Scrum: Скрам использует фиксированные временные рамки, называемые спринтами, которые обычно длятся от одной до четырех недель. Это позволяет командам "пушить" заранее запланированные задачи в рамках каждого спринта.

Kanban: Канбан основан на принципе "пул", что означает, что работа вытаскивается из очереди по мере необходимости. Это позволяет командам адаптироваться к изменяющимся требованиям и приоритетам, так как новая задача берется только тогда, когда есть свободный ресурс.

10. Метрики

Scrum: Основные метрики, которые применяются в скраме: Velocity (Скорость), Burndown Chart (График сгорания), Sprint Goal Achievement (Достижение цели спринта), Release Burndown.

Kanban: Основные метрики, которые применяются в канбане: Lead Time (Время производства), Cycle Time (Цикловое время), Throughput (Производительность), Work In Progress (WIP).

11. Оценка и приоритизация

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

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

12. Изменения в ходе работы

Scrum: Скрам изначально не приветствует изменения объема задач, включенных в спринт. Дело в том, что если мы определили цель для конкретного спринта и команда взяла на себя ответственность за ее достижение, то любые изменения в объеме работ могут подорвать все наши планы.

В таких случаях целесообразно завершить текущий спринт раньше срока и начать новый. Однако на практике это приводит к дополнительным затратам времени. Поэтому часто выделяется часть ресурсов команды на внеплановые задачи, что противоречит принципу Agile о "ранней поставке ценного ПО".

Kanban: В методологии Kanban всё гораздо проще — изменения могут быть внесены в любое время. Если бизнес решает, что необходимо срочно приступить к выполнению задачи, это не требует долгих процессов перепланировки (работу можно начать буквально через несколько минут). Однако здесь также существуют свои сложности, например, возможные блокировки задач, которые уже находятся в работе, и снижение производительности разработчика из-за необходимости переключаться на новую задачу. О том, как с этим справляться, я постараюсь рассказать отдельно.

13. Начала работ над тасками

Scrum: Скрам строится на основе спринтов, ограниченных во времени. Работа начинается только после того, как задачи будут расставлены по приоритету и оценены, проработаны ac, после чего они попадают в список спринта (Sprint Backlog). Обычно это происходит с регулярностью, соответствующей итерациям, что подразумевает ожидание включения конкретной задачи в ближайший спринт (хотя это не всегда происходит быстро).

Kanban: В Канбане нет таких ограничений, как в Скраме: задачи берутся сразу в работу по мере возможности или необходимости (например, когда кто-то завершает свою текущую задачу или возникает задача более высокого приоритета). Таким образом, разрыв между созданием задачи и началом работы над ней меньше, чем в Scrum.

14. Проведение демо

Scrum: Demo проводится в конце спринта и является частью Sprint Review. На этом митинге команда демонстрирует завершенные элементы работы (например, функционал, который был разработан за спринт) заинтересованным сторонам, включая владельца продукта. А также в получении ОС по проделанной работе.

Kanban: Формальные демо-сессии не являются обязательными в канбане, их проведение может быть полезным для улучшения коммуникации и сотрудничества в вашей команде.

Поэтому демо-сессии можно проводить, как на регулярной основе (например, раз в определенный период) или после завершения значительных задач.

Напоследок пару слов о СкрамБане

Скрам-бан — это гибридная методология, объединяющая элементы, как Scrum так и Kanban, которая предназначена для управления проектами и улучшения процессов разработки.

Основные характеристики Скрам-бан:

• Гибкость: Скрам-бан сохраняет гибкость, позволяя командам вносить изменения в процессе работы, что особенно важно в динамичных условиях.

• Визуализация: Использование визуальных инструментов, таких как доски и карточки, помогает командам отслеживать задачи и их прогресс.

• Поток работ: Скрам-бан фокусируется на оптимизации потока работ, уменьшая время выполнения задач и повышая эффективность команды.

• Непрерывное улучшение: Команды регулярно анализируют свои процессы и ищут способы их улучшения, что способствует росту и развитию.

Скрам-бан подходит для команд, которые хотят сохранить структурированный подход (как в Скрам), но при этом желают иметь гибкость и визуализацию рабочего процесса (как в Канбан) и командам что хотят перейти из скрама в канбан как промежуточный степ.

Напишите в комментариях, что вы чаще используете в своих проектах — Scrum или Kanban? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!

Подтолкнула к изысканиям меня одна история.

Поскольку я участвую в пресейлах с клиентами, собеседую кандидатов к нам в компанию, да и в целом много общаюсь внутри отрасли, через меня проходит довольно большой поток людей. Поэтому до меня долетает множество разных историй. Одна из них – про новый стартап. Его основатель делает сервис доставки наподобие Яндекса в Казахстане для уже существующей (своей) курьерской службы.

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

Через некоторое время мы встретились снова. Он уже активно собеседовал людей и жаловался, что никто в отрасли нормально нейросетями не умеет пользоваться. Рынок еще не переквалифицировался… Но он все еще настаивал на новом подходе к проектированию.

После этого рассказа я начал экспериментировать с ИИ. Мучения мои продлились, наверное, недели четыре. После чего взялся изучать матчасть вглубь и вширь.

Движемся от проектирования

Я понял, что на качество результата работы нейросети очень влияет подход к проектированию. Писать таким образом код – как разговаривать с джуном, который знает синтаксис языка, но не понимает, как писать правильно, как должны работать микросервисы, как они между собой взаимодействуют в проекте, как все это должно запускаться и т.п. Так что я пошел подтягивать навыки проектирования: изучил подходы к написанию ТЗ, углубился в DDD, BDD, SDD, которые и начал применять, чтобы лучше формулировать задания.

Как в итоге выглядит процесс: я беру какой-то концепт, декомпозирую его в соответствии с моделью C4. А потом начинаю взаимодействовать с нейросеткой.

Помните, как мы создавали системы на блокчейне? Спека должна была стоять во главе угла, поскольку любые изменения в уже запущенную систему внести очень дорого. Смарт-контракты, которые живут в продакшене, уже не остановить. Поэтому спека и контракты должны разрабатываться в первую очередь. Сначала мы описываем их на бумаге, потом пишем спецификации и только по ним код и всю архитектуру. Это Spec-Driven Development (SDD).

Обычно в других сферах разработки все сильно проще. Поэтому требованием сначала писать спеки пренебрегают. Но с точки зрения взаимодействия с нейронкой это очень хороший подход. Если его не использовать – не объяснять нейросети, что нужно на выходе получится как в известной формулировке: “Без ясного ТЗ результат ХЗ”. Это та самая история про написанный нейросетью макаронный код, в котором человеку разобраться уже очень сложно.

Чтобы самому не закопаться в документации, задачу написать спеку тоже можно выдать нейросети, указав, какие при этом нужны API, методы и структуры данных. Ее же можно попросить описать юзеркейсы бизнесовым языком, используя Behaviour-Driven Development (BDD). С Domain-Driven Design (DDD) несколько сложнее. Нейронка в этот подход не умеет, но его можно реализовать руками, грубо говоря, на доске со стикерами или в Miro.

Спеками дело не ограничилось. Я пошел копать дальше и в своих изысканиях наткнулся на ролевые истории, когда ты просишь нейросеть встать на позицию, допустим, DevOps или QA-автоматизатора, и покритиковать только что написанные спецификации. Дошел до того, что в параллели запускал четыре-пять ролей, которые критиковали ТЗ, спорили между собой и пытались прийти к консенсусу. В процессе они подсвечивали целый пул проблемных сценариев ТЗ, указывая доступные варианты решения. Мне оставалось только выбрать тот, что я считал правильным, и дополнить ТЗ. Каждый предметный пункт при этом претерпевал до 10 итераций изменений. И только когда они были все внесены, запускалась разработка.

В целом получалось весьма неплохо. А можно было пойти дальше и вспомнить про более жесткие требования к коду – что есть разные модели структуры данных, чистый код или стандарты его написания (например, PEP8 в Python). Нейросеть можно заставить писать все в соответствии с ними, скормив ей текст правил. Причем, человек, который заявляет, что пишет свой код на основе этих стандартов, скорее всего, сделает это хуже. Нейросеть также можно заставить отрефакторить уже написанный код в соответствии с этими стандартами. Она сделает это минут за 15 – щелк и готово – в то время, как человеку придется долго переписывать весь проект, вложив в это огромный труд.

Первые работающие проекты

Буквально за месяц, набив руку на декомпозиции задач, я написал свой первый проект –прототип игрушки в 2D. На голом движке Pygame герой из зеленых, красных и коричневых квадратов бегал по карте, ставил и разбивал кубики.

Второй мой кейс – за новогодние праздники я написал простое управление складом для своих домашних, которые занимаются изготовлением мерча по играм. Бэкенд на Go, фронт на Next JS. Здесь нейросеть сделала все – написала спецификацию, полное ТЗ и тест-кейсы (обеспечила unit, end-to-end тесты и проверку фронтенда с полным прокликиванием всех сценариев). На сладкое я получил 100% покрытие тестами, чего не добивался в реальной жизни ни в одном проекте.

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

Ложка дегтя – квалификация архитектора

Осознав возможную скорость проектирования, я пробовал запустить все в параллель - четыре нейросети сразу писали код. И все получилось! В теории, если написано ТЗ, я мог бы так озадачить любое количество нейросетей. Потом писать следующее ТЗ и снова запускать модель. Так можно даже прикрывать отсутствие у себя каких-то знаний - по бэку, фронту или тестированию.

Например, QA я более-менее понимаю, бэкенд – тоже, SRE и DevOps навыки у меня отличные и с архитектурой тоже хорошо. Однако закрыть полный цикл разработки без нейросети я не мог, потому что у меня слабые скиллы по фронтенду. Нейросеть помогла компенсировать эту “хромоту” за счет тестов.

Однако ты все еще должен писать спецификации и быть внимательным. Поэтому какая бы основная специализация фронт, бэк или тестирование у тебя не была, если при этом не обладать экспертизой хотя бы на уровне архитектора джуна, все пропало. И в моем случае если бы не было именно архитектурных навыков, ничего бы не получилось. Поэтому без эксперта все это пока работать не будет.

Плата за доступ

В своих экспериментах я использовал облачные модели. За 5 дней работы (примерно по 6 часов) при создании складского инструмента MiniMax M2.1 потребовала около 2 тысяч рублей. Подписка на Claude Sonnet 4.5 – а сейчас это лучшая нейросеть для написания кода – стоила бы дороже, особенно если брать отечественный платежный шлюз. В зависимости от способа оплаты, потребовалось бы от 4 до 10 тысяч рублей.

Не так давно Nvidia анонсировала свои коробочки для запуска моделей – DGX. Выглядит как неттоп, подключается по сети. По сути, это маленький компьютер, в котором очень много быстрой памяти. Его можно использовать, чтобы запускать нейронную сеть локально, грубо говоря, на своем рабочем месте. Вижу, что аналогичные коробочки выпускает Raspberry Pi, Orange Pi и другие. Но пока ничего из этого нет в продаже в РФ (то, что есть, продается по заоблачной цене).

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

Похоже, упомянутые коробочки тоже метят в тренд. Мы подходим к моменту, когда каждому разработчику нужна будет нейросеть на рабочем месте. Вместо видеокарт будем покупать эти отдельные блоки, чтобы нейронка жила на столе, а не в облаке по подписке. И нам придется за это заплатить.

Кстати, заплатить придется не только деньгами, но и навыками. Это же все придется поддерживать!

Хорошо описал ситуацию мой коллега, Михаил Евдокимов: “Модель в ноутбуке у Data Scientist'а – это 0% бизнес-результата. Нужен MLOps, который позволит модели работать в реальном мире, под нагрузкой, 24/7, и не деградировать. Обучить модельку – это не так сложно. Вот у тебя модель готова, высокая точность. Но сделать так, чтобы она работала в инфре, чтобы она работала на новых данных и не теряла качество – вот это задача. Внедрить ее так, чтобы люди реально пользовались, чтобы данные корректно подтягивались с 1С-ки и других разных источников, нормально обрабатывались, чтобы ничего не ломалось. Сотрудник случайно вобьет что-то не так в 1С, данные с этой ошибкой подтянутся в модель – произойдет сбой, модель нормально не обучится или выдаст ерунду. А потом модель еще дообучать нужно (потому что мир меняется, жизнь меняется, тренды меняются). А еще модель может начать деградировать со временем.  Всё это сделать и заставить работать стабильно – это и есть самая большая задача на самом деле”.

Что в итоге

Большинство пользуется нейронками как продолжением гугла. Но отрасль разработки меняется прямо на наших глазах – мы в начале этой волны. Думаю, что очень скоро нейросети станут стандартом де-факто и одним из требований к разработчикам в вакансиях.

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

Завтра каждый бизнес в стране получает одинаковый суперкомпьютер. Одинаковые программы. Одинаково обученных сотрудников.

Кто победит?

Тот, у кого суперкомпьютер мощнее? Нет. Они одинаковые.

Побеждает тот, кто знает, что именно считать и зачем.

Не гипотеза. Реальность. Происходит прямо сейчас.

Почему «все равны в ИИ» - неизбежно

ИИ - программы, которые анализируют данные, пишут тексты, считают прогнозы, автоматизируют рутину. Сегодня доступ к самым мощным стоит несколько тысяч рублей в месяц. Завтра дешевле. Послезавтра бесплатно.

Февраль 2026. Рынок подошёл к точке: все компании используют одни и те же модели ИИ.

Электричество в 1890-х - колоссальное преимущество фабрики с электромотором. К 1920-м преимущество испарилось. Электричество у всех. ИИ повторяет путь. Быстрее в десятки раз.

Навыки работы с ИИ выравниваются. Интерфейсы упрощаются. Разница между «продвинутым» и «начинающим» пользователем тает каждый месяц. Через два года вопрос «умеете работать с ИИ?» звучит так же нелепо, как «умеете пользоваться почтой?».

Вопрос остаётся один: что именно определяет, кто зарабатывает, а кто закрывается?

Контекст - не что вы знаете, а как понимаете

Два ресторана. Один город. Одна программа анализа спроса. Программа: «По пятницам люди заказывают больше мяса».

Первый ресторан закупает больше мяса по пятницам. Всё.

Второй знает: по пятницам рядом заканчиваются корпоративы в бизнес-центре напротив. Люди приходят группами. Уставшие. Голодные. Готовые тратить. Этот ресторан перестраивает меню, добавляет групповые сеты, ставит большие столы у входа, запускает предложение «для компаний от четырёх человек».

Одна информация. Один ИИ. Результат принципиально разный.

Разница - контекст.

Контекст - не данные. Данные - цифры, факты, таблицы. Контекст - понимание, что эти цифры означают именно для вашего бизнеса. В вашем районе. С вашими клиентами. В вашей ситуации. Накопленная годами способность превращать сырую информацию в точные решения.

ИИ обрабатывает миллион строк за секунду. Но не знает:

1. Ключевой клиент на прошлой неделе поссорился с партнёром. Ищет нового поставщика. Сейчас.
2. Арендатор соседнего помещения съезжает через месяц. Вы можете расшириться.
3. Лучший менеджер хочет уволиться. Потому что не дали проект, который просил полгода.

Контекст - память и понимание организации. Компании, которые системно собирают, выстраивают и обновляют своё понимание реальности, получают решения на порядок точнее тех, кто «спрашивает ИИ».

Собственные данные - нефть, которую нельзя купить

Все модели ИИ обучены на открытых источниках. Интернет, книги, статьи. Всё, что знает ИИ, он знает одинаково для всех. Знания общие.

У каждого бизнеса есть информация, которой в открытом доступе нет:

· История покупок конкретных клиентов
· Записи звонков
· Внутренние отчёты
· Причины отказов
· Сезонные закономерности именно в вашей нише
· Жалобы за последние пять лет
· Результаты экспериментов, о которых никому не рассказывали

Вы подключаете ИИ к этим данным. Он начинает выдавать результаты, невозможные в другой компании. Даже с той же программой. Потому что у неё нет вашей истории, вашей специфики, ваших наработок.

Собственные данные - фундамент преимущества. Базовые модели опираются на общедоступное. Ваши данные - нет.

Важно не просто иметь данные. Важно выстроить систему постоянного накопления. Каждый звонок. Каждая сделка. Каждый отказ. Каждая жалоба. Оседают в упорядоченном виде. Обогащают вашу частную библиотеку знаний. Со временем эта библиотека становится настолько ценной, что её невозможно воспроизвести. Даже с неограниченным бюджетом. Потому что для этого нужно прожить вашу бизнес-историю заново.

Защитный ров копает себя сам

Средневековье. Замки окружали рвом с водой. Чем шире ров - тем сложнее штурмовать. В бизнесе аналог - барьер, который защищает вас от конкурентов и со временем становится только глубже.

Практика. Вы - логистическая компания. ИИ анализирует маршруты. Решение принимает человек. Потому что знает:

1. На этом участке часто проверяет полиция
2. Один клиент нервничает при опоздании больше десяти минут
3. Другой спокойно ждёт сутки

Каждое решение - обратная связь для системы. ИИ запоминает: этот маршрут отвергли, вот почему. Следующий раз - предложение точнее. Через год ваша система принимает решения, которые учитывают тысячи нюансов. Недоступных конкуренту с тем же ИИ.

Ров копает сам себя.

Дольше работает - точнее система. Точнее - лучше результаты. Лучше результаты - больше клиентов, данных, обратной связи.

Конкуренту, чтобы догнать, нужно прожить тот же путь обучения. Годы.

Бренд - единственный маяк в тумане

Полка в магазине. Двадцать бутылок воды. Абсолютно одинаковых. Состав, объём, цена. Какую берёте? Ту, которой доверяете.

ИИ позволяет любой компании производить продукт одинакового качества. Писать одинаково хорошие тексты. Обеспечивать одинаково быстрый сервис. Бренд остаётся единственным критерием выбора.

Бренд - не логотип. Не красивый сайт. Обещание, которое выполняется каждый раз. Клиент знает: обращусь к этим людям - результат будет таким-то. Предсказуемость качества, помноженная на время.

ИИ генерирует терабайты текстов ежедневно. Кризис доверия к информации. Люди не могут отличить текст практика от текста программы. В хаосе хватаются за знакомые имена. Проверенные источники. Голоса, которым верят.

Малый и средний бизнес: ваша личная репутация, история, имя - актив, который конкурент не воспроизведёт подпиской на нейросеть.

Скорость обучения - кто быстрее поворачивает

Мир ускоряется. Тренды живут месяцы вместо лет. Рынки переворачиваются за кварталы. Побеждает не самый большой. Не самый технологичный. Самый быстро обучающийся.

Скорость обучения организации - время от момента, когда заметили изменение, до момента, когда бизнес отреагировал. Не «обсудил на совещании». Не «включил в план на квартал». Реально изменил поведение.

Аналитик обнаружил: клиенты чаще уходят после третьего месяца подписки.

Компания А: созвала совещание, назначила рабочую группу, через месяц утвердила план, через два начала внедрять.

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

ИИ одинаковый. Данные похожие. Разница - устройство организации:

· Сколько уровней согласования
· Сколько людей должны сказать «да»
· Насколько сотрудники вправе принимать решения на местах

Не про технологии. Про управленческую архитектуру.

Человек + машина - искусство дирижирования

ИИ:

· Блестяще анализирует
· Плохо сочувствует
· Мгновенно находит закономерности в данных
· Не способен почувствовать, что клиент расстроен, хотя говорит «всё нормально»
· Пишет безупречные отчёты
· Не умеет построить отношения с партнёром за ужином

Конкурентное преимущество - не в замене людей на ИИ. Не в игнорировании ИИ. В точном определении: где работает машина, где человек, как передают друг другу эстафету.

Оркестр. ИИ - инструменты, играющие безупречно по нотам. Без дирижёра нет музыки. Есть набор правильных звуков. Дирижёр - человеческое суждение. Решает: здесь пауза, здесь громче, здесь вообще сменить произведение - зал сегодня в другом настроении.

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

Бизнес-модель - менять правила, а не фигуры

Все играют в шахматы одинаковыми фигурами. Можно играть лучше. Можно сменить игру.

Инструменты одинаковы. Выигрывает тот, кто перестраивает саму логику заработка:

Вместо «плата за работу» - плата за результат.
Клиенту не нужна ваша работа. Нужен итог. ИИ позволяет достигать итога в пять раз быстрее - берите деньги за итог, не за часы.

Вместо продажи инструмента - продажа превращения.
Никто не хочет покупать систему управления клиентами. Хотят, чтобы продажи выросли. Упакуйте ИИ, опыт и сопровождение в результат, который клиент может измерить.

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

Система партнёрств - один в поле не воин

ИИ делает отдельную компанию мощнее. Связка компаний, обменивающихся данными и знаниями - создаёт возможности, недоступные одиночке.

Закрытые соглашения об обмене данными. Совместные решения, создающие бесшовный опыт клиента. Отраслевые союзы. Всё это формирует составные возможности. Конкуренту для воспроизведения нужно повторить всю сеть связей разом, а не отдельные звенья.

Пример. Риелтор, банк, страховая объединили данные через общую платформу. Предлагают клиенту одобренную ипотеку, подобранную квартиру, оформленную страховку. В одном окне. За один день.

Конкурент-одиночка, даже с лучшим ИИ, физически не способен воспроизвести без партнёров.

Ясность мышления - последнее, что нельзя автоматизировать

Всё описанное выше упирается в одну точку: качество мышления людей, принимающих решения.

Технологии уравнены. Ясность мышления - главное различие между победителем и проигравшим.

Ясность цели.
Зачем существует бизнес. Не «заработать денег». Конкретно - какую проблему решает, для кого, почему именно так.

Ясность приоритетов.
Из тысячи возможностей, которые подкидывает ИИ, выбрать три, которые двигают вперёд. ИИ генерирует варианты. Человек решает, какие имеют значение.

Ясность исполнения.
Не «мы внедряем ИИ». Конкретно: в какой процесс, ради какого результата, с каким мерилом успеха.

Ясность клиентского опыта.
Клиент в любой точке соприкосновения понимает: что происходит, чего ожидать, что делать дальше.

Побеждают не те, у кого набор программ дороже. Те, у кого острее мышление и точнее исполнение.

Глубокое знание отрасли - то, что нельзя скачать

Есть вещь, которую ИИ не заменит в обозримом будущем. Наименее подверженная превращению в общедоступный навык. Глубокое знание предметной области.

Знание:

· Как именно устроен ваш рынок
· Какие неписаные правила действуют
· Какие подводные камни ждут новичка
· Какие решения «по учебнику» не работают и почему
· Какие люди принимают реальные решения, а какие только подписывают

ИИ прочитал все книги по вашей отрасли. Но не сидел за столом переговоров. Не терял ключевого клиента. Не разруливал кризис в три часа ночи. Не чувствовал запах сделки, которая вот-вот сорвётся.

Это знание живёт в людях. Единственный ресурс, который нельзя скачать, купить по подписке или наработать за квартал.

Карта факторов успеха

Итог

ИИ станет общедоступным. Как электричество. Как интернет. Конкурентная борьба переместится с технологий на фундаментальные организационные способности.

Победят не те, у кого лучше подписка на нейросеть.

Победят те, кто:

· Глубже понимает свой рынок
· Быстрее учится
· Точнее выстраивает баланс между человеком и машиной
· Последовательнее выполняет обещания бренда

Парадокс эпохи ИИ: чем доступнее технологии, тем важнее люди.

Их суждение. Их опыт. Их ясность мышления. Их способность превращать информацию в понимание.

Три ключевых фактора успеха

Десять факторов из статьи - это тактика. Способы выживания и отстройки. Но ключевой фактор успеха - категория другого порядка. Это корневое условие, без которого бизнес не просто проигрывает конкуренцию, а теряет право на существование.

Тактика отвечает на вопрос «как». КФУ отвечает на вопрос «почему вообще».

1. Способность порождать смысл

ИИ обрабатывает информацию. Человек создаёт из неё смысл. Разница - пропасть.

Информация - «продажи упали на 12%». Смысл - «мы перестали решать ту проблему, ради которой к нам приходили. Клиент вырос, а мы нет».

Обработка данных, контекст, знание отрасли, собственные данные - всё это сырьё для производства смысла. Но само по себе сырьё ничего не производит. Нужна способность видеть связи, которых нет в таблицах. Формулировать то, что рынок ещё не осознал. Давать название тому, что клиент чувствует, но не может выразить.

Бизнесы, которые порождают смысл, не конкурируют. Они задают систему координат, в которой конкурируют остальные.

Apple не продавала телефоны. Она определила, чем телефон является. Все остальные играли в рамке, которую задала она.

В эпоху ИИ этот фактор усиливается кратно. Машина генерирует бесконечный объём контента, решений, вариантов. Возникает дефицит не информации, а интерпретации. Не ответов, а правильных вопросов. Не вариантов, а направления.

Организация, способная порождать смысл, становится точкой притяжения. Для клиентов - потому что объясняет им их собственную ситуацию лучше, чем они сами. Для сотрудников - потому что даёт работе значение. Для партнёров - потому что формирует повестку, а не подстраивается под чужую.

Это не про маркетинг. Не про позиционирование. Это про когнитивную функцию бизнеса - его способность думать.

2. Необратимость накопленного

Тактические преимущества копируются. Технологии тиражируются. Процессы воспроизводятся. Единственное, что невозможно воспроизвести - время, прожитое определённым образом.

Защитный ров, собственные данные, скорость обучения - это проявления одного глубинного фактора: организация накапливает нечто, что нельзя отмотать назад и нельзя перепрыгнуть.

Не любое накопление создаёт необратимость. Можно десять лет копить данные в хаосе - и они будут стоить ноль. Необратимость возникает, когда:

· Каждое решение обогащает следующее
· Каждая ошибка сужает коридор будущих ошибок
· Каждое взаимодействие с клиентом углубляет понимание его мира
· Каждый цикл «сигнал - реакция - результат» калибрует систему точнее

Это организационная эволюция. Не рост - эволюция. Рост - количественное увеличение того, что есть. Эволюция - качественное изменение того, чем являешься.

ИИ ускоряет циклы. Но направление эволюции задаёт не ИИ. Его задаёт первый фактор - способность порождать смысл. Без направления ускорение бессмысленно. Быстрее бежишь - быстрее оказываешься не там.

Компания, которая десять лет осмысленно накапливала опыт в своей нише, находится не на десять шагов впереди конкурента. Она находится в другом измерении. Конкурент может купить те же инструменты. Нанять тех же людей. Скопировать процессы. Но он не может прожить эти десять лет.

Это не про размер. Новый проект с правильной архитектурой накопления за два года создаёт необратимость, которую корпорация с хаотичными процессами не создала за двадцать.

3. Плотность человеческого присутствия

Бренд, мышление, суждение, партнёрства, баланс человека и машины - всё это грани одного явления. Но само явление глубже.

Плотность человеческого присутствия - это мера того, насколько бизнес пронизан живым, неалгоритмизируемым, незаменимым человеческим участием в критических точках.

Не количество сотрудников. Не «человекоцентричность» из корпоративных презентаций. А концентрация необходимого человеческого суждения в тех местах, где оно определяет исход.

Хирург. 95% операции могут быть автоматизированы. Но 5% - момент, когда что-то пошло не по плану и нужно принять решение за секунду - определяют, жив пациент или нет. Плотность человеческого присутствия - не про то, что хирург делает всё руками. А про то, что он присутствует в точке, где его присутствие решает всё.

В бизнесе так же. ИИ берёт на себя 80% процессов. Остаётся 20%, где:

1. Нужно уловить то, что не выражено словами
2. Нужно принять решение в условиях принципиальной неопределённости
3. Нужно создать доверие, которое невозможно запрограммировать
4. Нужно сказать «нет» тому, что выглядит логично, но ощущается неправильно

Компании, которые размазывают человеческое участие тонким слоем по всем процессам, проигрывают. Компании, которые концентрируют его в критических точках - выигрывают.

Чем мощнее ИИ, тем меньше этих точек. И тем выше цена каждой.

Это не парадокс. Это закон: ценность человеческого растёт пропорционально мощности нечеловеческого.

Три КФУ образуют каскад:

Смысл определяет направление. Необратимость накапливает преимущество в этом направлении. Плотность присутствия обеспечивает качество каждого шага.

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

Примеры построения бизнеса на конкурентных преимуществах в эпоху ИИ

В эпоху ИИ выигрывает не тот, у кого «умнее программа», а тот, у кого глубже контекст, сильнее накопление и плотнее человеческое присутствие.

Часть 1: Малый бизнес 

Чтобы не говорить абстрактно, разберем три ключевых фактора успеха в эпоху, когда ИИ становится инфраструктурой: способность порождать смысл, необратимость накопленного и плотность человеческого присутствия, на примерах малого бизнеса.  

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

1. Кофейня: контекст вместо данных

Две кофейни на одной улице подключили одну и ту же программу учёта. Программа показывает: в понедельник утром продажи капучино растут на 30%.

Первая кофейня закупает больше молока на понедельник.

Вторая знает: в здании напротив по понедельникам планёрка в 9:00. Люди прибегают за 15 минут, стоять в очереди не будут. Владелец ставит второй кран на кофемашину, вводит быстрый формат «кофе за 90 секунд», поднимает цену на 15%. Продажи утром понедельника вырастают на 40%.

Рычаг: завести тетрадь (или заметку в телефоне), куда бариста ежедневно записывает одно наблюдение – что происходит вокруг точки. Кто открылся, кто закрылся, откуда идут люди, что спрашивают и не находят. Через три месяца эта тетрадь содержит контекст, недоступный ни одному конкуренту с тем же ИИ. Через полгода – основу для решений, которые программа не подскажет.

2. Автомойка: защитный ров из обратной связи

Автомойка в спальном районе. Клиенты постоянные – жители окрестных домов. Владелец фиксирует каждое обращение: какой автомобиль, какая мойка, какие замечания, когда приезжает повторно.

Через полгода система знает: у Петрова белый кроссовер, он приезжает раз в десять дней, всегда берёт полную мойку и жалуется на разводы на лобовом. У Сидоровой чёрный седан, ей важна скорость, мойка базовая.

Мойщик получает карточку клиента до начала работы. Петрову протирают лобовое вручную без напоминаний. Сидорову пропускают без очереди.

Рычаг: простая база (хотя бы таблица на диске) с полями: имя, авто, частота, особые требования, замечания. Каждый мойщик вносит запись после обслуживания.

Через год эта база – тысячи микро-нюансов, которые конкурент через дорогу не повторит, даже подключив такую же программу. Ров копает себя сам: чем дольше база наполняется, тем точнее сервис, тем выше возвращаемость.

В этих примерах работает первый и второй фактор: способность порождать смысл (видеть контекст за пределами отчёта) и необратимость накопленного (опыт и данные, которые невозможно «подгрузить» из готового решения задним числом).

Следующие примеры — про третий фактор, плотность человеческого присутствия, и про то, как устройство малого бизнеса либо усиливает его, либо размазывает по мелочам до нуля.

1. Барбершоп: бренд через плотность присутствия

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

Владелец – сам мастер. Стрижёт три дня в неделю. Знает по имени каждого второго клиента. Помнит, кто женился, кто сменил работу.

Его мастера обучены не только стричь, а замечать: клиент молчит – не лезть с разговором; клиент хочет поболтать – поддержать. Точка концентрации человеческого присутствия – момент, когда клиент садится в кресло.

Рычаг: определить 2–3 точки в пути клиента, где живое участие решает всё. В барбершопе: приветствие (узнавание), момент обсуждения стрижки (понимание без долгих объяснений), завершение (обратная связь). Остальное автоматизируется: запись через интернет, оплата, напоминания.

Человеческое присутствие не размазывается, а собирается в узлы, где формируется доверие.

2. Пекарня: скорость обучения как преимущество

Две пекарни. Обе отслеживают продажи по часам. Обе видят: после 15:00 остаётся непроданный хлеб.

Первая обсуждает проблему на еженедельной планёрке. Через месяц решает сократить выпечку. Через два – внедряет.

Вторая в тот же день уменьшает замес на 20%, вводит вечернюю скидку «минус 30% после 16:00», через неделю видит результат: списание сократилось вдвое, вечерняя выручка выросла. Ещё через неделю проверяет формат «свежее к ужину» – булочки с начинкой, которые выпекают в 17:00 специально под вечерний поток.

Рычаг: дать пекарю или старшему смены право менять объём замеса и ассортимент в пределах дневного бюджета без согласования с владельцем. Убрать уровни согласования между сигналом и действием. Установить правило: любая догадка проверяется за 48 часов.

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

3. Шиномонтаж: партнёрство вместо одиночной конкуренции

Шиномонтаж в промзоне. Конкуренты – три точки в радиусе километра. Все с одинаковым оборудованием и ценами.

Владелец договаривается: с магазином запчастей напротив – взаимное направление клиентов; с ближайшим автосервисом – пакет «техническое обслуживание + сезонная замена шин» по единой цене; с автомойкой – комплект «помыл, переобул, уехал».

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

Рычаг: составить список из 5–7 бизнесов поблизости с той же аудиторией. Предложить каждому простой обмен: вы рекомендуете меня, я рекомендую вас, фиксируем через промокоды или визитки. Со временем – общая база клиентов, совместные предложения, непрерывный маршрут для клиента. Ценность сети растёт с каждым новым участником.

ИИ становится фоном, а выигрывают те, кто сочетает три слоя — смысл (понимание, в какой игре вы вообще участвуете), необратимость накопленного (опыт, который нельзя украсть) и плотность человеческого присутствия (точки, где человек остаётся последним аргументом, который машина не воспроизводит).

Часть 2: Средний бизнес

Теперь о среднем бизнесе.
Здесь ставки выше: больше людей, больше процессов, больше денег, больше инерции. И именно поэтому разница между компанией, которая просто использует ИИ, и компанией, которая перестраивает под него саму логику работы, становится особенно заметной.

У среднего бизнеса есть один важный плюс: он уже накопил достаточно данных, опыта и связей, чтобы строить собственные конкурентные преимущества. И один важный риск: если управленческая система остаётся старой, ИИ просто ускорит слабости, а не усилит силу.

1. Оптовая торговля стройматериалами: собственные данные как невоспроизводимый актив

Оптовик работает с 300 постоянными клиентами. За пять лет накопил: историю заказов каждого, сезонные паттерны, причины отказов, предпочтения по логистике, пороги ценовой чувствительности.

ИИ, подключённый к этой базе, прогнозирует: клиент X через две недели закажет цемент, потому что три года подряд он начинает закупку в конце марта. Менеджер звонит заранее, предлагает зафиксировать цену. Клиент соглашается. Конкурент с тем же ИИ, но без пяти лет истории, работает вслепую.

Рычаг: внедрить обязательную запись в CRM после каждого контакта – не только сумма сделки, а причина покупки, причина отказа, упомянутые планы клиента, замечания по логистике. Назначить ответственного за качество данных.

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

Через три года – ров, который копает сам себя.

2. Небольшое производство мебели: бизнес-модель «плата за результат»

Мебельное производство. 30 человек. Клиенты – застройщики, дизайнеры интерьеров. Конкуренты делают то же самое на том же оборудовании с тем же ИИ для раскроя.

Владелец меняет модель: вместо «продаём шкаф» – «меблируем объект под ключ за фиксированный срок». Берёт на себя замеры, проект, производство, доставку, монтаж, гарантию. Застройщику не нужен шкаф – ему нужен сданный объект. Цена контракта выше, маржа выше, конкурент с ценой за погонный метр не конкурирует – он в другой системе координат.

Рычаг: пересмотреть единицу продажи. Определить, за какой конечный результат клиент готов платить больше, чем за промежуточный продукт. Упаковать производство, логистику и сервис в один контракт с измеримым итогом. ИИ ускоряет расчёт себестоимости и проектирование – экономия времени конвертируется в маржу, а не в снижение цены.

ИИ ускоряет расчёт себестоимости и проектирование. Но экономия времени должна конвертироваться не в снижение цены, а в маржу.

3. Региональный дистрибьютор продуктов питания: скорость обучения через управленческую архитектуру

Дистрибьютор обслуживает 500 розничных точек. ИИ анализирует заказы и выявляет: в одном районе резко выросли продажи растительного молока.

Компания А (конкурент): торговый представитель пишет отчёт, региональный менеджер выносит на планёрку, коммерческий директор согласует расширение ассортимента, через шесть недель продукт появляется на складе.

Компания Б: торговый представитель имеет полномочия сделать пробный заказ новой позиции в пределах лимита. Через три дня продукт в точках. Через неделю – данные по продажам. Через две – решение о масштабировании на всю зону.

Рычаг: сократить цепочку согласований для экспериментов. Установить бюджет эксперимента (например, 50 000 руб.), в пределах которого торговый представитель принимает решение самостоятельно. Определить формат отчёта: что тестировал, что получил, рекомендация.

Скорость обучения организации – функция количества уровней согласования. Чем их меньше – тем быстрее компания адаптируется.

4. Производство промышленных фильтров: глубокое знание отрасли как стратегическое оружие

Завод выпускает фильтры для систем вентиляции. 50 человек. Конкуренты – крупные и мелкие – используют те же чертежи, те же материалы, те же станки.

Главный инженер проработал в отрасли 20 лет. Знает: на объектах конкретного застройщика вентиляционные шахты уже в проекте, стандартный фильтр встанет, но через полгода начнёт вибрировать из-за аэродинамики конкретного сечения. Он предлагает модифицированный фильтр заранее. Застройщик экономит на рекламациях. Конкурент с тем же ИИ проектирования этого не знает – потому что не стоял на тех объектах.

Рычаг: создать внутреннюю базу знаний: нетиповые решения, особенности конкретных клиентов, ошибки на объектах, результаты нестандартных применений. Не в головах сотрудников – в системе. Каждый проект оставляет запись: что сделали, почему именно так, что сработало, что нет.

ИИ, подключённый к этой базе, начинает предлагать решения, учитывающие всю нетиповую практику. Это знание нельзя скачать.

5. Оптовая компания по продаже электрики: порождение смысла для рынка 

Оптовик продаёт электротехническую продукцию. 80 человек. Сотни конкурентов с теми же каталогами и теми же ценами от тех же производителей.

Владелец формулирует: клиенту (электромонтажнику, подрядчику) не нужна розетка. Ему нужно сдать объект в срок, без переделок, без рекламаций. Компания перестраивается: вместо каталога – комплектация под проект. Менеджер читает спецификацию, собирает комплект, предупреждает о несовместимостях, предлагает замены, которые ускорят монтаж. ИИ считает спецификации за минуту. Но смысл – «мы отвечаем за то, что объект сдаётся без проблем» – задаёт человек.

Рычаг: определить, какую конечную задачу решает клиент вашим продуктом. Сформулировать обещание на уровне этой задачи, а не на уровне товара. Перестроить работу менеджеров: не «принять заказ», а «закрыть потребность проекта». Обучить команду видеть за заказом – цель клиента. Это задаёт систему координат для рынка. Конкуренты продают позиции из цены. Вы продаёте результат. Они играют в вашей рамке.

Во всех этих примерах ИИ — не источник преимущества, а усилитель того, что уже есть внутри компании. Если внутри есть порядок, знание, скорость обучения и ясное понимание, какую конечную задачу решает бизнес, ИИ это масштабирует. Если внутри хаос, размытая ответственность и продажа «товара вместо результата», ИИ лишь сделает этот хаос быстрее и заметнее.

В среднем бизнесе ИИ не делает чудес. Он просто беспощадно подсвечивает, у кого есть собственная память, собственная скорость и собственная рамка игры, а у кого — только цены, регламенты и надежда на авось.

Сильный средний бизнес в эпоху ИИ строится не вокруг технологии, а вокруг трёх вещей: собственных данных, управленческой скорости и умения продавать не продукт, а итог, который нужен клиенту. Конкуренты могут купить то же программное обеспечение. Не могут купить вашу историю, вашу отраслевую память и вашу способность принимать решения быстрее рынка.

Поэтому вопрос уже не в том, внедрять ИИ или нет. Вопрос в другом: что именно в вашем бизнесе ИИ должен усиливать — и что вы готовы выстроить так, чтобы это нельзя было скопировать.

Представлен мотор вашей ИИ-компании

9 марта 2026 года состоялся публичный релиз Paperclip. Это не новая языковая модель и не фреймворк для создания ИИ-агентов. Это менеджерский слой (написанный на Node.js со встроенной базой PostgreSQL), который объединяет различные инструменты — Claude Code, OpenClaw, Codex и Cursor — в единую организационную структуру. Пользователь вводит глобальную бизнес-миссию, а система самостоятельно распределяет роли, формирует дерево задач (от «Цели проекта» до конкретного тикета) и назначает ботам бюджеты.

Создатели проекта формулируют суть своей архитектуры предельно просто:

«Если OpenClaw — это сотрудник, то Paperclip — это компания».

Взаимодействие происходит асинхронно: агенты «просыпаются» по заданному расписанию, выполняют свою часть кода или текста, передают результат по иерархии и снова засыпают. Проект распространяется по лицензии MIT и может быть развернут локально одной командой в терминале.

Бюрократия спасает от хаоса

Чтобы понять, почему за одну неделю Paperclip собрал 19 900 звезд на GitHub, нужно посмотреть на проблему глазами разработчика. Одиночным скриптом управлять легко. Но когда, как у предпринимателя Аарона Снида, круглосуточно работают 15 кастомных агентов-ассистентов, экономящих 20 часов в неделю, — вы начинаете тонуть в гонке состояний, двойной работе и сбоях сессий.

Создатели Paperclip сформулировали свой подход предельно жестко:

«Не чат-бот. У агентов есть работа, а не окна чата. Не фреймворк для агентов. Мы не говорим вам, как создавать агентов. Мы рассказываем, как управлять компанией, состоящей из них».

В основе платформы лежат несколько нетипичных для классического ИИ-инструментария механик.

Сердцебиение и персистентность. Агенты больше не висят в оперативной памяти постоянно. Они работают по системе «heartbeats» (сердцебиений). Например, агент-контентмейкер просыпается каждые 4 часа, проверяет свою очередь задач, пишет текст, отправляет его по иерархии выше и уходит в спящий режим. Если терминал закроется или компьютер перезагрузится, контекст не потеряется.

Атомарное выполнение. В традиционных системах два агента могут случайно взять в работу одну и ту же задачу, потратив в два раза больше токенов на вызовы API. Paperclip следит за агентами: когда агент бронирует задачу, она блокируется.

Дерево целей. Вместо того чтобы просто сказать боту «напиши обработчик WebSocket», система передает ему всю генеалогию: Миссия компании («Создать AI-приложение для заметок с выручкой $1M») → Цель проекта («Запустить функции коллаборации») → Цель агента («Реализовать синхронизацию в реальном времени») → Задача. Это решает главную проблему LLM — потерю бизнес-контекста при выполнении узкотехнических инструкций.

Адаптация новых «сотрудников» происходит на лету благодаря файлу SKILLS.md. Если вы подключаете нового агента к уже работающей системе, он просто считывает этот файл и мгновенно понимает внутренний протокол: как сдавать работу, как запрашивать помощь и кому подчиняться.

ИИ сам собирает себе команду

Ключевое отличие нового подхода заключается в смещении роли человека. Заявленная концепция «компании с нулевым участием людей» (Zero-Human Company) на практике оборачивается тем, что разработчик внезапно оказывается в кресле чиновника, непрерывно ставящего штампы на документах.

Независимый архитектор решений Кельвин Квонг, тестировавший Paperclip на реальных задачах, описывает свой опыт так:

«Система приняла кадровые решения, о которых я не просил, создала структуру проекта, которую я не проектировал, и теперь ждала, что я автоматически одобрю ее планы. Я стал советом директоров компании, которую не создавал».

Когда система сама формирует стратегию, декомпозирует ее на задачи и распределяет их между виртуальным «SEO-аналитиком» и «Backend-разработчиком», что остается человеку? Означает ли это, что высшая форма инженерии в 2026 году — это умение правильно утверждать бюджетные сметы для алгоритмов?

Бюджет как главный рубильник

Пожалуй, самым недооцененным прорывом стала примитивная, на первый взгляд, функция — жесткое бюджетирование. Разработчики регулярно сталкивались с ситуацией, когда ИИ-агент, застряв в цикле ошибок, мог за 45 минут сжечь 200 долларов на бесконечных API-запросах, прежде чем человек успевал это заметить.

В Paperclip каждому виртуальному сотруднику выделяется жесткий лимит (например, $50 в месяц). При расходе в 80% система отправляет мягкое предупреждение. При достижении 100% агент физически блокируется (auto-pauses) на уровне инфраструктуры. Никаких исключений, пока «Совет директоров» (вы) не согласует дополнительное финансирование. Это превращает абстрактный страх перед восстанием машин во вполне понятный корпоративный процесс: отдел разработки превысил смету и ждет транша.

Реальные кейсы и сценарии использования

Архитектура Paperclip не является сугубо академическим экспериментом — она тестируется энтузиастами в реальных, часто нестандартных условиях. Инструмент, созданный для решения личной проблемы одного разработчика, быстро оброс экосистемой микробизнесов и автономных конвейеров.

Управление хедж-фондом и хаос в терминале

Проект родился из банального человеческого отчаяния создателя фреймворка (разработчика под псевдонимом Agent Native). Он пытался автоматизировать рутину в собственном алгоритмическом хедж-фонде. В какой-то момент для поддержания работы у него было одновременно открыто двадцать вкладок с запущенным Claude Code. Разработчик признался, что физически перестал контролировать ситуацию: он не помнил, какой бот собирает финансовую аналитику, какой пишет код, а какой просто завис. Paperclip стал вынужденной мерой, чтобы превратить эти двадцать разрозненных вкладок в один слаженный отдел с четкой иерархией.

Автоматизация GitHub: программист, который нанял сам себя

На профильных площадках вроде Reddit активно обсуждается сценарий радикального делегирования разработки. Один из пользователей настроил Paperclip для полного цикла управления собственным кодом. Система работает так: первый агент непрерывно мониторит вкладку с ошибками (Issues) в репозитории. Обнаружив баг, он выступает в роли тимлида и назначает задачу виртуальному «программисту» (на базе Claude Code). Тот пишет исправление и формирует Pull Request, после чего другой агент-тестировщик прогоняет тесты и проверяет логику. Единственное, что делает в этой цепочке живой человек — раз в сутки заходит в систему, чтобы нажать кнопку «Merge» (слияние веток).

Агентство лидогенерации на автопилоте

В официальной документации и материалах на Substack описывается создание конвейерного B2B-агентства. Процесс разбит на строгие роли: агент-парсер круглосуточно собирает профили потенциальных клиентов в LinkedIn. Собранная база передается виртуальному SEO-аналитику, который сверяет компании с заданными критериями целевой аудитории. Финальный этап берет на себя агент-копирайтер, генерирующий глубоко персонализированные холодные письма. Весь ежемесячный бюджет (зарплатный фонд) на API-вызовы для такой команды составляет около 210 долларов, что несопоставимо со стоимостью найма даже одного стажера-человека.

Zero-Cost Agency: бесплатный штат на домашнем сервере

Для тех, кто не хочет платить корпорациям за токены, на GitHub зародилось целое движение. Энтузиасты начали скрещивать оркестрацию Paperclip с локальными языковыми моделями через систему Ollama. Это породило феномен «агентств с нулевой стоимостью» (Zero-Cost Agency). Виртуальная компания полностью разворачивается на домашнем сервере (например, на Mac Mini) и работает 24/7. Пользователь получает полноценный штат сотрудников, не платя за них ничего, кроме счетов за электричество и интернет.

Отзывы и впечатления: имитация бурной деятельности и шок фаундеров

Однако на практике жизнь автономных корпораций оказалась полна абсурдных инцидентов, в которых алгоритмы начали пугающе точно копировать худшие проявления человеческой корпоративной культуры.

Шок от потери контроля

Независимый разработчик Кельвин Квонг описал психологический дискомфорт, с которым сталкиваются фаундеры. Ранее человек привык писать промпт и получать готовый текст или код. В Paperclip паттерн меняется: человек ставит абстрактную задачу, а система сама проектирует структуру проекта, нанимает виртуальных сотрудников и выкатывает бюджетную смету, требуя от создателя ее утверждения. Пользователи жалуются на сюрреалистичное чувство: они превращаются в бюрократов, обслуживающих компанию, которую сами не проектировали.

Галлюцинации в иерархии и бесконечные совещания

Практики выявили фундаментальную проблему каскадного непонимания. Если CEO-агенту (верхнего уровня) ставится слишком размытая бизнес-цель, он передает такие же нечеткие инструкции своим подчиненным. Вместо того чтобы выдать ошибку, нижестоящие боты начинают бесконечно отправлять запросы друг другу, пытаясь уточнить детали. Визуально это выглядит так, словно ИИ-сотрудники заперлись в переговорке на бесконечное совещание: они имитируют бурную деятельность, перекидываются сообщениями и стремительно сжигают выделенный бюджет, не производя при этом ни строчки полезного кода.

Споры о пульсе: почему машинам нужны человеческие смены

Отдельной темой для дискуссий стала частота «сердцебиений» (heartbeats) — интервалов, через которые агенты просыпаются для работы. Изначально пользователи пытались выжать из ботов максимум, заставляя их проверять задачи каждые 10–15 минут. Это приводило к катастрофам. Создатель фреймворка признавался, что лично наблюдал, как агент сжег 200 долларов за 45 минут, просто застряв в цикле бесконечных повторных попыток (retry loop).

Опытным путем сообщество пришло к парадоксальному выводу: ботов нужно искусственно тормозить. Самыми стабильными оказались системы, где агенты просыпаются раз в четыре или восемь часов. Ирония очевидна: создавая ИИ для круглосуточной работы со скоростью света, разработчикам пришлось вернуть алгоритмы к классическому графику человеческих рабочих смен, чтобы они не сломали сами себя.

Иллюзия «нулевого присутствия»

Концепция «компания с нулевым участием людей» звучит масштабно. Однако при глубоком анализе документации и отзывов первых пользователей вскрываются фундаментальные вопросы, о которых система умалчивает.

Во-первых, ни один источник не объясняет, как именно Paperclip страхует пользователя от каскадных семантических ошибок (error propagation). Если агент-исследователь сгаллюцинировал неверные финансовые данные, а агент-копирайтер блестяще и без технических сбоев написал на их основе инвестиционный отчет, система воспримет задачу как успешно выполненную. Инструмент отслеживает только статус тикета и расход токенов, но не оценивает достоверность результата.

Во-вторых, остается открытым вопрос: на основе каких скрытых метрик система автоматически решает, сколько агентов нужно «нанять» для абстрактной миссии вроде «создать внутренний инструмент»? Кельвин Квонг прямо указывает на правило «мусор на входе — хаос на выходе». Если вы ставите размытую бизнес-цель, агенты начинают дробить ее на десятки бессмысленных подзадач, имитируя бурную деятельность и сжигая бюджет.

Кроме того, инструмент позиционируется как универсальный, однако требует уверенного владения средой Node.js, что создает определенный порог входа для инженеров, не знакомых с этой средой.

Эпоха алгоритмического менеджмента

Успех Paperclip, ровно как и параллельных проектов вроде платформы Pulsia (где запущено уже более 1500 автономных компаний) или фреймворка Symphony от OpenAI, фиксирует важный сдвиг. Бутылочное горлышко технологий окончательно сместилось от генерации контента к логистике процессов.

Тот факт, что для управления кодом нам понадобилось воссоздать бюрократический аппарат со сметами, должностными инструкциями и планерками, выглядит одновременно иронично и закономерно. Человечество пока не придумало лучшего способа справляться с хаосом, чем поместить его в таблицу с иерархией. Компании и одиночные разработчики, которые первыми научатся быть хладнокровным «Советом директоров» для машин, получат непропорциональное преимущество. Остальным придется и дальше закрывать по двадцать вкладок в терминале, надеясь, что на этот раз ИИ ничего не сломал.

Источники:

• Zero-Human Company with OpenClaw, Claude, and Codex: How to Build an Agent Organization — Medium. Авторы: Agent Native

• Paperclip — Open-source orchestration for zero-human companies — Paperclip.ing.

• I Became the “Board of Directors” for a Company of AI Agents — Medium. Авторы: Kelvin Kwong

• Paperclip: How to Run a One-Person Company with This Open Source Framework — Apidog. Авторы: Herve Kom

• Paperclip Discussions (Zero-Cost Agency & User Feedback) — GitHub.

• The Rise of the Agentic Manager (Lead Gen Agency Case) — Substack. Авторы: Agent Native

• paperclipai/paperclip: Open-source orchestration for zero-human companies — GitHub.