Управление разработкой *

Почему ИИ нельзя внедрить как ERP, нельзя раздать как Office, и что тогда остаётся

В ТЗ на «внедрение ИИ» перед самым конкурсом вписали маленький пункт: перевести перевод внутренних документов с ПРОМТа на нейросеть. Документы конфиденциальные, в облако нельзя, а то, что влезает в закрытый контур, испытаний не проходит — и контракт на десятки миллионов повис на одном абзаце. Разбираю, почему ИИ нельзя внедрить как ERP и нельзя просто раздать как Office, что реально влезает в контур (с ценами в рублях), и как мы вытащили задачу из клетки, которая не закрывается ничем.

Как выбрать лучшее средство для разработки приложений? Такой вопрос может возникнуть не только в IT компании, но и в учебном заведении. Автор попытался критически взглянуть на пройденный им путь по выбору low-code платформы для учебного процесса МЭИ.

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

«Какие планы на ближайшие несколько лет?»

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

Будущее кажется новым, но на самом деле это чаще всего слегка отредактированная версия настоящего.

Но самые интересные, асимметричные и неожиданные варианты будущего сегодня, скорее всего, вообще не видны. Для них еще не существует необходимого исходного материала.

Как тогда двигаться вперед, если будущее невозможно нормально спланировать?

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

Содержание статьи:

1. Где найти потенциал для развития компании.

2. Что такое полномочия и для чего они нужны.

3. Распределение полномочий – необходимое условие для осуществления эффективной деятельности компании.

4. Пример влияния распределения полномочий при осуществлении коммерческой работы на деятельность компании.

5. Делегирование полномочий. В чем отличия от распределения полномочий.

 1.  Где найти потенциал для развития компании.

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

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

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

В эпоху AI код становится дешевле, а качественное инженерное решение — ценнее.

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

Viaduct помогает превратить архитектурное проектирование в структурированный, проверяемый и доступный AI-агентам контекст — от модели системы до Change Set, по которому можно безопасно реализовать изменение.

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

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

Практические приёмы снижения копипасты и упрощения конфигурирования множества сходных проектов в TeamCity.

Привет, Хабр! Меня зовут Анастасия Трегубова, я архитектор продукта Platform V Synapse API Mesh в СберТехе. Хочу поделиться идеями по работе с агентскими инструментами и внедрением протокола МСР в корпоративном ландшафте. Расскажу, как мы обеспечиваем централизацию, но обходим узкие места, и как линейка продуктов платформы Synapse сокращает этот путь. Надеюсь, что вы сможете почерпнуть из статье идеи для решения аналогичных задач.

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

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

В 2026 году я провела 105 глубинных интервью с владельцами и руководителями студий и компаний разработки — от аутсорса до продуктовых команд, плюс часть диджитал‑агентств. Выборка — от 10 до 300+ сотрудников, география — вся Россия. Я искала не только статистику — сколько компаний падает, а сколько растет. Я искала ответ на вопрос, почему одни падают, а другие растут: что делают лидеры растущих компаний и не делают те, кто руководят падающим бизнесом

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

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

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

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

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

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

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

Рынок разработки ПО в России продолжает расти, а вот маржа у самих разработчиков тает на глазах. По оценке «Руссофта» на основе опроса более 300 участников индустрии, проведённого в марте — апреле 2026 года, совокупная выручка российских софтверных компаний по итогам 2026 года может вырасти на 17%, до 3,3 трлн рублей, но более 20% компаний рискуют закончить год со снижением выручки. При этом годом ранее снижение выручки прогнозировали 3,8% опрошенных, а фактически оно произошло почти у четверти компаний. Когда рынок находится в таком состоянии, ошибка в выборе модели ценообразования на одном проекте стоит дороже, чем несколько лет назад.

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

Как устроены обе модели

Фикс-прайс. Заказчик и подрядчик до старта фиксируют объём работ, цену и срок. Оценка делается один раз: если объём недооценили, это проблема исполнителя, а если что-то заложили с запасом и оно не понадобилось, переплачивает заказчик.

T&M (Time & Materials). Заказчик платит за фактически отработанные часы по согласованной ставке. Оценка изначально примерная и уточняется по ходу проекта, риск неопределённости в большей степени переходит на заказчика, зато исполнитель не расплачивается за собственную ошибку в оценке.

Жёсткой границы между моделями нет ни в законе, ни на практике. Большинство реальных договоров это комбинация фиксированной цены, оплаты по фактическим трудозатратам и различных механизмов ограничения риска. Сами термины «фикс-прайс» и «T&M» относятся скорее к деловой практике, чем к самостоятельным юридическим конструкциям.

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

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

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

Я решил проверить эту идею. Посмотрел исследования производительности разработчиков с AI, карьерные лестницы инженерных компаний и поговорил с Middle/Senior‑разработчиками, Team Lead'ами и Engineering Manager'ами.

Картина оказалась сложнее. AI действительно может сильно ускорять работу, но эффект зависит от задачи, опыта и контекста. Зелёные тесты не гарантируют готовность изменения к продакшену. А способность работать с неопределённостью сама по себе плохо объясняет разницу между Middle и Senior.

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

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

Около года два математика, Tristan Buckmaster, профессор математики в NYU, и Levent Alpöge, математик из Anthropic, работали над задачами вокруг уравнений Эйлера и Навье-Стокса (дальше НС). Это не было работой Anthropic, они занимались этим в свободное время, без каких-либо институциональных договорённостей. По словам Buckmaster, большую часть года прогресс шёл медленно, а сам результат появился 15 августа.

Они развивали направление Diego Córdoba и Luis Martínez-Zoroa и получили очень сильный результат: разрушение за конечное время для трёхмерных уравнений Эйлера с гладкой внешней силой (finite-time blowup for forced 3D Euler). В процессе они сами активно использовали AI, включая Claude и Codex, а доказательства формализовали в системе Lean. Terence Tao назвал их результат выдающимся достижением.

В X появляется вирусный пост о том, что Anthropic якобы близок к решению двух задач тысячелетия. Слух был неверным: Buckmaster и Alpöge не решали две задачи тысячелетия, и это вообще не было работой Anthropic. Но OpenAI сразу взяли это на вооружение. И вот это уже не обвинение Buckmaster, а буквально написано самой OpenAI.

28 августа OpenAI начала обучать новую внутреннюю модель с очень сильными результатами по математике. 1 сентября они услышали слух про две якобы решённые задачи и решили запустить новую модель на все оставшиеся задачи тысячелетия.

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