Что такое ответственность за фичу

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

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

Ирония автоматизации

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

Из этой серии интервью в 1983 родилась статья "Ironies of Automation", которая ну до боли напоминает сегодняшние разговоры о нашей индустрии.

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

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

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

Короче говоря, убирая легкие части задачи, автоматизация делает трудные части еще труднее, при этом возможностей получать релевантный опыт и поддерживать актуальные знания у операторов становится меньше. Здравствуй, чудесный 2026 год!

Надо ли ревьюить код

Вообще, все споры про то, надо ли ревьюить весь AI-generated код, на мой взгляд, довольно бессмысленны. Разговор стоит вести на другом уровне абстракции – нужен ли в целом процесс code review, вне зависимости от того, кто этот код написал.

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

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

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

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

Как в Uber управляют экономикой AI

Uber выпустил интереснейший разбор всех деталей того, как AI используется во всех этапах их SDLC, как они выросли в нагрузке в 7 раз с февраля, при этом существенно сократив затраты на каждую отдельную сессию. Вот некоторые интересные инсайты:

👉Основные рычаги влияния на экономику AI: цена за токен, количество шагов в сессии, количество запросов к модели на каждый шаг, и количество токенов на каждый запрос.
👉Дефолтную модель меняют чуть ли не каждую неделю, постоянно гоняя их на собственных бенчмарках, и выбирая оптимальную по цене/качеству.
👉У всех инженеров форсится максимальный размер контекста в 400к токенов и medium reasoning – это помогает контролировать количество токенов в запросе.
👉Все MCP тулы находятся за единым гейтвеем, что и экономит токены, и позволяет навесить единые политики авторизации.
👉Собственный графовый движок помогает существенно ускорить поиск агентом нужного контекста (с 20 минут до 40 секунд для довольно типичной задачи).
👉Внутренний дэшборд подсвечивает каждому человеку антипаттерны в том, как он работает с AI.

Как измерить слоп

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

Есть несколько альтернативных количественных методов:

👉Просто смотреть на количество строк кода, но есть нюанс – если сделать эту метрику целевой и оптимизироваться под нее, то смысл она быстро потеряет.
👉Verbosity – количество продублированных или бесполезных строк (реализовано через ast-grep)
👉Erosion – насколько значимая часть кода сосредоточена в небольшом количестве больших и сложных функций. Считается через цикломатическую сложность.

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

Как дать фидбэк по итогам собеседования

В чем суть статьи – автор предлагает давать фидбэк по итогам проваленного собеседования не безличным письмом, а на отдельном звонке. У меня к этому довольно двоякое отношение.

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

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

Короче говоря, я бы в такие фоллоу-апы вкладывал время только для исключительных кандидатов.

Как быстрее проверять маркетинговые гипотезы с помощью ИИ

Например, в Greeneration почти 3 месяца вручную искали рабочий оффер для нового продукта — мини-цуккини и specialty-картофеля.

Делали разные лендинги, переписывали рассылки, собирали креативы, запускали и сравнивали результаты.

Сейчас тот же цикл, по оценке команды, можно было бы пройти за 1–2 недели, если встроить ИИ не только в генерацию текстов, а в сам процесс тестирования гипотез.

И это, кажется, гораздо более интересный сценарий применения ИИ в маркетинге, чем очередное «напишите 20 вариантов заголовка».

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

21 сентября AI Mindset запускает трёхнедельный практический спринт про маркетинг + ИИ

Участники приходят со своим действующим продуктом и конкретной маркетинговой задачей и вместе с командой выстраивают тот самый цикл:

идея → креатив → канал → сигнал → решение

То есть результатом должна стать не презентация про возможности AI, а реально запущенный тест + данные для решения, что проверять следующим.

Спринт идёт онлайн с 21 сентября по 10 октября.

Вся программа и детали — на сайте: marketing.aimindset.org

Регистрация — через бота: https://t.me/aimindset_lab_bot?start=874


Реклама. ООО «ВИНКАМ», ИНН 5408306756, erid:2SDnjcdN5qu

Универсальные отказы на интервью

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

Пара примеров из статьи:

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

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

Как агенты следуют разным техникам верификации

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

👉Результат, полученный без дополнительных инструкций, оказался выше, чем с любой из добавленных техник верификации.
👉Инструкция использовать TDD дала вдвое больше тестов, но результаты оказались хуже.
👉Формальные доказательства касались тривиальностей вместо корректности реализации.
👉Фаззинг активировался не всегда, инпуты генерировались бессмысленные, многократно проверялись ветки отказа.
👉Лучше всего работали очень конкретные инструкции – искать вероятные ошибки, выбирать граничные и асимметричные примеры, генерировать содержательные инпуты при фаззинге, но даже тогда следование инструкциям было не полным.

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

Стать резидентом Дубая теперь легче, чем когда-либо

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

Оформить визу на 2 года могут и те, кто приобрел жилье до вступления поправок в силу. Единственное ограничение — нельзя отсутствовать в стране более 180 дней подряд.

👉Если хотите познакомиться с рынком Эмиратов, забирайте уже готовую бесплатную подборку 5 самых ожидаемых стартов осени 2026

В каталоге — проекты от 199 тыс. $, условия рассрочек, особенности локации и ориентиры по потенциальному росту стоимости.

Важно: подбор и сопровождение сделки на первичном рынке бесплатны, их оплачивает застройщик.

Больше новостей и горячих предложений — в канале агентства.

Кроссплатформа теряет смысл

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

👉Агенты могут легко переносить готовые фичи из iOS в Android и обратно, так что преимущество от ускорения разработки сходит на нет.
👉Разработчики могут контрибьютить в обе кодовые базы, не испытывая проблем из-за незнания Swift или Kotlin, и это убивает преимущество от использования одного языка.
👉Feature Parity поддерживать стало дешевле из-за единых спек и тестов, так что косты в этом месте тоже упали.
👉Делать нативные приложения все еще лучше, так как ты находишься ближе к железу, используешь нативный тулинг, и тащишь меньше зависимостей.

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

Как писать с помощью LLM

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

Но это не значит, что LLM нельзя использовать, чтобы сделать человеческие тексты лучше. Начнем с того, чего делать нельзя:

👉Не нужно использовать никакие слова и обороты, которые LLM вам предлагает, именно они дают ощущение AI текста.
👉Не нужно обращать внимание на то, когда модель хвалит вас или ваши идеи.

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

Еще очень помогает направлять модель на конкретные проблемы – чтобы собрать себе нужный словарик и набить руку в статье советуют книгу Lessons in Clarity and Grace, я не читал, но в бэклог забрал.

🦺 Обучение по охране труда под ключ

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

В обучение входят:

- онлайн-теория на платформе Нетологии;
- очные практические занятия на базе партнёров в Москве, Санкт-Петербурге, Екатеринбурге или на территории вашей компании по - договорённости;
- оформление протоколов;
- внесение сведений в реестр Минтруда;
- бонусный курс по цифровой безопасности и работе с ИИ.

➡️ Оставить заявку

Реклама. ООО "Нетология" ОГРН 1207700135884 erid:2VSb5x8bQfC