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

Вдохновился идеей OpenAI Harness Engineering и проверил на большом легаси проекте: можно ли отдать агенту всю реализацию, а человеку - постановку, тесты и ревью. Сотни файлов, зелёные тесты и два бага, которые нашли только руками. Про «согласованные ошибки», разные мнения и почему финал эксперимента открытый.

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

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

ИИ уже вошёл в нашу будничную рутину. Кто-то использует его как быстрый справочник, кто-то как помощника в IDE, а кто-то уже собирает вокруг него весь рабочий процесс. Рынок меняется слишком быстро, чтобы игнорировать это на собеседованиях. Какой смысл проверять кандидата в искусственных условиях, если в реальной работе он всё равно использует ИИ каждый день? Логичнее сразу посмотреть, как он работает на самом деле. Мы не стали с этим бороться, а встроили в процесс.

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

В апреле у Инфостарта идет серия бесплатных вебинаров по автоматизации процессов в 1С. С фокусом на практические сценарии: производство, инфраструктура, аналитика, документооборот, финансы и эксплуатация.

Что еще впереди:

16 апреля, 15:00 (МСК)
Умное планирование производства в 1С на основе математической оптимизации
Поговорим о том, как уйти от Excel и ручных корректировок к расчету производственных графиков с учетом ограничений по оборудованию, людям и сырью.

17 апреля, 11:00 (МСК)
Postgres Pro Enterprise для 1С: максимум производительности на отечественной платформе
Разберем, как смотреть на переход с MS SQL на российскую СУБД в контуре 1С: что с производительностью, стабильностью и архитектурными ограничениями.

...

AI убивает Agile. Звучит провокационно, но, кажется, это буквально происходит прямо сейчас

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

Agile появился как способ справиться со сложной проблемой комплексного планирования систем и низкой скорости разработки, но с проникновением AI эти ограничения уже практически сняты, и вопрос только времени, когда они вообще исчезнут.

Есть интересная статья с критикой Agile «Agile Is Dead. AI Killed It. Welcome Back, Waterfall.»

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

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

Kent Beck (один из авторов Agile-манифеста) предполагает, что внедрение AI может столкнуться в организациях с противодействием, потому что не всегда люди заинтересованы в ускорении и удешевлении процессов. Это из разговора Kent Beck и Martin Fowler на Pragmatic Summit. Там же Kent Beck говорит о том, что возвращается тенденция к программистам-интровертам, которые не любят и не хотят частого общения, что было нормой до недавнего времени. Сейчас можно сфокусироваться на нескольких коллегах и нескольких агентах, а задачей компании становится создание безопасной позитивной атмосферы для функционирования таких производственных единиц.

Почему в нашей платформе роль API Gateway по-прежнему выполняет Apache APISIX, хотя альтернатив на рынке хватает?

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

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

Начну со случая, после которого исчезли последние иллюзии.

Меня зовут Кирилл, я IT-директор в Ви.Tech, IT-дочке ВсеИнструменты.ру. Недавно мы записывали подкаст с Сергеем Щербининым, CEO консалтинговой компании fcon tech, бывшим CTO/CIO. Мы не раз возвращались к теме performance review, потому что в какой-то момент стало понятно: проблема почти никогда не в форме, не в туле и не в названиях оценок. Обычно все ломается раньше, в точке, где компания пытается одним процессом одновременно раздать деньги, выровнять ожидания, найти слабые места, вырастить людей и еще убедить всех, что получилось справедливо. В какой‑то момент стало очевидно простое, но важное наблюдение: «золотого стандарта нет».

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

Здравствуйте, я – менеджер продукта в компании «СИБИНТЕК». В прошлом году самому известному и популярному фреймворку для команд, создающих функционально сложные продукты, исполнилось 30 лет. Да, вы правы, речь про Scrum. Несмотря на то, что Scrum про скорость, про разработку короткими итерациями с постоянной обратной связью, сам фреймворк почти не развивается. Мы до сих пор пользуемся гайдом пятилетней давности. И для новых адептов данного подхода может показаться, что Scrum был всегда таким, как он описан в Scrum Guide 2020. И многим даже не приходит в голову посмотреть эволюцию его развития. Например, проанализировать, а что поменялось с прошлого издания 2017 года и, главное, почему. А проследив эти изменения, можно понять ключевые моменты, на которые может быть стоит сфокусироваться современным Scrum-командам. Давайте попробуем это сделать.

PR утвердили за четыре минуты. Авторизация легла через три дня. 84% разработчиков используют AI-инструменты - 29% доверяют тому, что выкатывают в прод. Разницу между этими числами я назвал «галлюцинация продуктивности».

Всем привет! Меня зовут Константин Замков. Я главный менеджер в компании «СИБИНТЕК», сертифицированный специалист по управлению проектами PMI PMP, управлению портфелями проектов PMI PfMP и Scrum-мастер PSM-I. В своей работе я управляю сложными комплексными ИТ-проектами и регулярно занимаюсь разработкой и актуализацией календарных планов. В этой статье хочу поделиться практическим подходом, который сформировался у меня за годы работы.

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

В итоге собрал свой фреймворк агентной разработки и выложил его на Гитхаб. Это набор скиллов и команд для Claude Code, которые учат его уму-разуму.

Я не разработчик. Я учился кодить в школе и универе, но ни разу не писал код в настоящих проектах. Жизнь завела меня сначала в маркетинг, а потом в менеджмент.

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

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

Разбор 5-ти кластеров ИТ‑сред и тест на совместимость для тех, кто хочет построить карьеру, сохранив нервную систему.

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

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

Рынок IT гетерогенен и давно уже кристаллизовался в кластеры с мало‑пересекающимися правилами игры. Ошибка в выборе кластера стоит 2–3 лет жизни и куска нервной системы. Специалисты часто мечутся между средами, пытаясь играть по чужим правилам, и закономерно проигрывают.

Три пары функций. В каждой одна написана человеком, другая — ИИ. Сможете отличить? Мы не смогли. И наш ИИ-ревьюер тоже. Разбираем, почему синтетика проверяет синтетику — и что с этим делать.

Пока Claude Code думает, в терминале мелькают Noodling, Honking, Clauding — 56 слов-пасхалок, систему которых внутри Anthropic зовут Tengu. Но это только верхушка. Собрал всё, что можно настроить: spinnerVerbs, CLAUDE.md как память между сессиями, permissions для защиты .env, автоформатирование через хуки, LSP-навигация и три режима работы через Shift+Tab. Готовый конфиг для копипасты внутри.

Если вы пользуетесь ИИ с 2024 и знаете, что такое few‑shot — статью можно пропустить. Здесь про начальные принципы работы с текстовыми ИИ.

GPT-5.4 пишет лучше всех — 97 баллов из 100. Но $0.10 за вызов. При 10 000 генераций в месяц — $1000. А мы нашли модель, которая справляется на 91% и стоит $0.0008. Те же 10 000 генераций — $8. Разница — $992 каждый месяц.

Мы строим продукт, где LLM генерирует образовательный контент для клиентов. Публичные бенчмарки (MMLU, HumanEval, LMSYS) не помогают — они не тестируют генерацию длинных текстов на русском и не учитывают стоимость. Поэтому мы за свои $95 построили собственный battle test и прогнали через него 18 моделей.

Что обнаружили: 7 из 18 моделей вставляют китайские иероглифы в русский текст. Одна копирует инструкции из промпта прямо в заголовки. А LLM-судья поставил сам себе 127 баллов из 100.

В статье: полная методология, таблицы с результатами, формула value score (цена/качество), и открытый лидерборд.

Вы наверняка встречали задачки на логику: «Все кошки — животные. Это животное — кошка. Значит ли это, что все животные — кошки?» Нет. С тимлидами та же история: не каждый сильный разработчик становится сильным тимлидом. Но и обратное неверно.

Меня зовут Юлия Аравина, я психолог и коуч IT-руководителей, а также наставник на курсе «Управление командой» в Яндекс Практикуме PRO. В этой статье я разберу, в какие ловушки попадают сильные разработчики после повышения, как из них выйти, и как понять, что тимлидство не для вас (или всё же для вас).

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

Представьте: вы наняли идеального сотрудника. Он пишет код как senior, разбирается в архитектуре за минуты, работает 24/7 без выгорания. Но у него одна особенность - каждое утро он забывает абсолютно всё. Не помнит, что делал вчера. Не знает, почему в платёжном модуле реализован тот самый workaround. Не помнит, что его коллега уже разбирался с тем же багом и нашёл решение.

Эта особенность работы с ИИ-агентами в 2026 году до сих пор многим доставляет неудобства.