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

В эпоху 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 не заменяет профессионального опыта.

Как определить, на чём сфокусироваться, если в компании множество вызовов: техдолг, неоптимальная архитектура и проблемы надёжности?

Привет, Хабр! Я — Иван Нещадин, работаю тимлидом в компании Авито. Сейчас я руковожу двумя командами Arch и Bridge. В этой статье по мотивам доклада для TeamLeadConf я расскажу, как в Авито мы создали SWAT-команду, которая быстро решает самые проблемные задачи и живёт между миров платформы и продукта. Также подробно опишу, как снижаем хаос в архитектуре и улучшаем надёжность.

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

Переход строительной отрасли на отечественные ТИМ/BIM-решения поставил перед застройщиками, техническими заказчиками и проектными организациями практический вопрос: способны ли российские программные продукты обеспечить полноценное информационное моделирование без использования зарубежного программного обеспечения и сохранить привычные процессы взаимодействия участников проекта?

В статье представлен практический опыт реализации одного из первых в России проектов по комплексной разработке всех основных разделов проектной документации многоквартирного жилого комплекса с использованием отечественной ТИМ/BIM-платформы nanoCAD BIM Строительство и nanoCAD Инженерный BIM¹ (далее – nanoCAD BIM). На момент подготовки статьи проект успешно прошел экспертизу и получил разрешение на строительство.

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

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

Так бы я и канителился, однако получилось так, что вайб‑кодинг, вместе с вайб‑планированием и вайб‑постановками задач в Jira, в нашей команде внедрили волевым решением. Никого не спрашивая, не выясняя, кто что умеет, кто как к этому относится и как это вообще повлияет на разработку.

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

Всё началось со странной потери скорости решения задач.

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

Насчёт лимитов я особо не переживал. Подход моей AI-команды позволяет параллельно работать над несколькими крупными проектами на подписке Claude Code стоимостью 100 долларов. Команда разделена на роли, у каждой роли собственная рабочая область, задачи декомпозируются, а большие исследования можно выносить в отдельные сессии. Система была рассчитана именно на то, чтобы не складывать весь проект в голову одному агенту.

Но затем мой AI-архитектор продукта дважды ушёл в сжатие контекста.

Он работал на Opus с контекстным окном в один миллион токенов.

Первый раз можно списать на случайность. Второй — уже закономерность.

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

Началось расследование.

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

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

Трудно представить начало сессии с ИИ, в которой модель легко и быстро понимает весь проект и необходимый контекст, чтобы принять от разработчика требования и качественно спроектировать внедрение, не сломав текущее стабильное состояние. Экспертиза инженера‑разработчика или системного аналитика несравненно качественнее — хотя бы потому, что он живёт с ней 24/7.

Бывало у вас такое: дел в голове так много, что забывать их начинаешь как только вышел с очередной встречи? Через несколько дней надо принять решение, на основании того, что мелькало перед тобой 3 секунды. Через время ловишь себя на мысли «У нас 21 век, агенты, скилы, почему строить связи между встречами, записями и мыслями должен я?». У меня — бывало, и тут как раз об этом.

Привет! Меня зовут Дима, и я работаю руководителем команды web-разработки AI‑продуктов в R&D Яндекса. А ещё — я учусь в вузе на 4 курсе, люблю куда‑нибудь слетать, пытаюсь следить за здоровьем: и всё это, как я думаю, легко бустится агентами.