«Время на задачу сократили в 2 раза». Компания помешалась на AI — айтишники жалуются
Согласно предсказанию CTO Flo Романа Бугаева, в 2026 году доля AI-сгенерированного кода вырастет с 20% до 30-40%. Как бы это кому-то не нравилось.
Согласно предсказанию CTO Flo Романа Бугаева, в 2026 году доля AI-сгенерированного кода вырастет с 20% до 30-40%. Как бы это кому-то не нравилось.
Мы попросили айтишников, чьи работодатели «помешаны на ИИ» (именно так это сформулировал участник нашего последнего ресёрча), рассказать, как их задолбал искусственный интеллект.
UX/UI дизайнер: «Это иллюзия экономии времени»
Я работаю UX/UI дизайнером в европейском стартапе с офисом в Польше. Компания разрабатывает мобильные и веб-приложения. Формально процессы есть: задачи ведутся в Jira, двухнедельные спринты, планирование, демо и ретро. Всё выглядит как нормальная продуктовая разработка. Проблемы начинаются не в процессах, а в том, как именно формулируются задачи и принимаются решения.
AI вместо нормальной постановки задач
Инициативы, как обычно, идут от руководства. Далее они попадают к продуктовым менеджерам, а затем к дизайнерам и разработчикам. На этом этапе почти всегда выясняется, что по задаче слишком много вопросов: не хватает контекста, логики, ограничений и понятного ожидаемого результата.
Задачи формально появляются в Jira, но по сути они часто выглядят как сгенерированный текст, без чёткой логики и понимания того, как фича должна работать. Далее начинается привычный процесс: обсуждение внутри команды, вопросы, возвращение к руководству, дополнительные созвоны.
И в какой-то момент коммуникация снова сводится к фразе: «Спросите у GPT, он вам ответит». В результате чат начинает выполнять роль посредника между руководством и командой, через которого объясняются идеи, решения и ожидания.
На первый взгляд кажется, что так проще и быстрее: не нужно долго формулировать мысль, можно сразу получить готовый текст. На практике происходит наоборот.
Сырое описание требует уточнений. Команда тратит время не на реализацию, а на интерпретацию того, что именно имелось в виду. Количество митингов растёт, а ясности больше не становится. Создаётся ощущение движения и контроля, но реальное понимание задачи постоянно ускользает. Это иллюзия экономии времени.
AI в дизайне: быстро, но неэффективно
Руководство активно генерирует иконки, иллюстрации и визуальные идеи, аргументируя это скоростью.
На практике такие материалы плохо подходят для работы в продукте: их сложно редактировать, масштабировать и поддерживать. В результате оказывается, что перерисовать элемент с нуля быстрее и качественнее, чем адаптировать сгенерированный результат. Но это сложно объяснить в логике «мы же уже получили готовое решение».
AI в продукте ради самого AI
AI также встраивается в сам продукт: в онбординг, профили, визуальные элементы. Даже там, где он не решает реальных пользовательских задач. Основная причина очевидна: наличие AI хорошо продаётся инвесторам.
В результате появляются функции, польза которых не очевидна, но которые усложняют продукт и логику, добавляют дополнительную нагрузку на команду.
AI полезный инструмент, если он используется как дополнение для работы: для идей, черновиков и ускорения рутинных задач. Проблемы начинаются тогда, когда он становится заменой нормального обсуждения, осмысленного принятия решений и фактически начинает выполнять роль product owner’а.
В таких случаях AI создает иллюзию простоты и скорости, но на практике делает процессы менее прозрачными и более деликатными. Этот опыт показал простую вещь: технология не может компенсировать отсутствие ясности в мышлении и коммуникации, она только маскирует эту проблему и снимает ответственность с людей, которые изначально должны её нести.
Как относятся коллеги
Не все коллеги согласны. Кому-то такой формат работы больше подходит. Можно ничего не делать, потому что непонятно, что делать, а они не являются частью первых этапов в разработке. Кто-то сильно ненавидит созвоны, поэтому такой оффлайн формат, когда всё через текст, им больше подходит.
Другая часть, более опытная, так сказать, понимает проблему. Они как будто не потеряли способность к анализу и пониманию того, что обсуждается.
Есть такой тип руководства, которые не слушают, что им говорят их специалисты. Если они хотят делать работу через AI, работа будет делаться через AI.
Тут нет смысла что-то доказывать, потому что проблема очевидна. Всё, что мы можем сделать, это отметить проблему, сравнить, как было и как стало. И тут либо руководство поймёт, либо нет.
Тимлид: «Начальство требует работать с AI всё быстрее и быстрее»
Engineering Team Lead и Co-founder ke-pasa.es Павел Зимогоров:
— Последний год я работаю на швейцарский консалтинг, который продаёт разработку AI-стратегии и поиск AI-продуктов, которые позволяют улучшить финансовые показатели компаний. В 100% случаев улучшение финансовых показателей означает сокращение штата.
Моя зона ответственности — разработка прототипа и помощь в валидации идей с технической стороны. За время этой работы мой способ работы с AI эволюционировал со «спросить у ChatGPT, как это сделать» до «написать эффективный промпт в Antigravity/Replit».
С одной стороны, скорость разработки значительно увеличилась. AI-агенты пишут код и тесты гораздо быстрее меня. Кусок кода на 200-300 строчек за одну минуту — запросто. 50 юнит-тестов — за пять минут. У меня появилась возможность контрибьютить в тех областях, в которые раньше даже заглядывать было страшно.
С другой стороны, это очень расслабляет. Когда искусственный интеллект раз, другой, пятый что-то успешно сделает за тебя, ты начинаешь ему доверять, менее тщательно проверять, и вот тут-то он и начинает «чудить».
К тому же начальство требует работать с AI всё быстрее и быстрее. Когда я пытаюсь поддержать ожидаемую скорость, страдают стандарты.
Ну и самое неприятное в том, что бизнес и продакт-менеджеры тоже хотят участвовать. Они же общаются с бизнесом и тоже умеют писать промпты. Но не смотрят, что генерируют AI-агенты. В итоге там получаются такие Содом и Гоморра.
В целом, AI мне кажется позитивной тенденцией. Скорость разработки значительно растёт, есть возможность увеличить покрытие, время выхода на рынок уменьшается. Осталось просто дождаться, когда индустрия переварит изменения и выработает новые стандарты работы.
Бэкендер: «Ты не пройдёшь, пока не зарезолвишь все комментарии от ИИ»
— Работаю в польской компании, которая нацелена на американские проекты. Год назад нам подключили Gemini Pro и Cursor для работы. После этого на проекте собирали специальные митинги, где обучали, как пользоваться ИИ, и этих митингов было много.
Кроме того, каждую неделю у нас проходят общие встречи, на которых нам рассказывают то же самое: как эффективно общаться с ИИшкой и что нужно писать MD-файлы.
ИИ у нас пытаются внедрить буквально во всё: есть ИИ для «тасок», есть ИИ-чат внутри IDE, также ИИ присутствует на код-ревью. Ты не пройдёшь дальше, пока не зарезолвишь все комментарии от ИИ. На митингах подключается ИИ-ассистент и т. д. Также наша компания создаёт свой собственный ИИ-агент — я даже не знаю для чего.
Удручает то, что время на выполнение задачи сократилось раз в пять (ладно, в два) и сотрудников буквально принуждают пользоваться ИИ.
Наверное, дело в том, что наши заказчики — американцы, которые любят внедрять ИИ буквально везде. Для них главное — успеть по срокам, неважно, какого качества код. Также замечаю, что с помощью ИИ уже написаны проекты, в которых становится тяжело копаться, ведь ИИ любит делать тот самый спагетти-код.
Для американцев это как будто нормально. Ревью на половине проектов проходит с помощью ИИ, заказчики комментарии не делают, им главное, чтобы работало плюс-минус нормально. Я сама сначала была в шоке от такого подхода. До этого работала в беларусском аутсорсе — там с ревью кода было строго. Или на проекте с разработчиками из СНГ: те всегда писали аккуратный код, давали дельные комментарии, старались что-то улучшить.
Но когда начала работать с американцами, привыкала к тому, что основы правильного написания кода, разные best practice, SOLID и другие стандарты им безразличны. Важно, чтобы было дешевле и быстрее.
Тем не менее нынешняя компания мне нравится, я чувствую себя в ней комфортно. Но ИИ и то, что некоторые решения со стороны заказчика — сущий ужас, конечно, раздражает.
Работы завались, джуны нужны. Как 2026 выглядит из разных пузырей — обсудили технические топы
Работы завались, джуны нужны. Как 2026 выглядит из разных пузырей — обсудили технические топы
«Профессий почти не останется». CEO советуют, чему учиться
«Профессий почти не останется». CEO советуют, чему учиться
Компании забили на джунов. Что будет, когда умрут все сеньоры?
Компании забили на джунов. Что будет, когда умрут все сеньоры?
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.
Такому работадателб просто нужно предлагать самому тогда спрашивать AI и делать. Он тогда все деньги получит. Win-win
Могу своей историей поделиться. Купила компания трешовый проект, который каким-то чудом смог собрать хорошие метрики. Команда 1.5 года жалуется, что с этим невозможно работать, фичи выкатываются с жутким скрипом, болью и руганью. Поверх этого еще сжатые сроки и требования по интеграции in-house SDK. А также давление, что вон гугл то уже 40-50% на АИ, значит и нам надо
Команда просит дать возможность все это отрефакторить и сделать нормально.
Но нет. Выходит гордый техдир и говорит что-то в духе - вы все не шарите, ретрограды, луддиты и вообще. Ща покажу, как надо. 2 месяца что-то вайб-кодит, АИшкой рефакторинги устраивает. Итог - полностью сломанная кодовая база, девелоперы в огне пытаются это исправить, тысячи долларов слиты на токены АИ (не считая зп самого техдира), релиз крупной фичи сдвигается на месяц. Виновата, ба-дум, тсс, - команда!
А на ближайшей townhall митке это продают как историю успеха.
Аминь.
Система контроля версий и бэкапы БД это, конечно, пережитки прошлого. Настоящие "про" вайбкодят код сразу в проде без свидетелей и логов
Если команда коммитнулась и ждет изменения, а фича зависит от них, то СКВ и бэкапы никак не помогут. Откатить = признать ошибку, остаться ни с чем, и начинать с начала. Что в случае любого более-менее крупного менеджера недопустимо. Только вперед.
считать любого менеджера техническим идиотом - большое заблуждение. Другое дело, что у хорошего менеджера, сознающего свои ограничения, во всем этом он упражнялся бы вместе с тим лидом разрабов с командой. Ну или новый тим лид, если старый не захотел бы.
Я не считаю каждого таким, хотя таких много. И конкретно в этом примере у менеджера огромный тех.бэкграунд. Что вообще никак не отменяет того, что он может не осознавать или недооценивать технические сложности или же сложности в процессах, в силу своего положения быть сильно оторванным от реальности, или попросту иметь большое эго.
если техдир не соответствует занимаемой должности, он найдет возможность как завалить работу, с ИИ или без него.
Скорость работы не растет. Просто срезаются всевозможные углы, а все недостатки заметаются под ковер и в упор игнорируются.
По поводу "выработает новые стандарты работы". Очередной булшит беливеров в АИ, что вот-вот, уже-уже, скоро-скоро, ну просто "осталось просто дождаться" и наступит общее блаженство. В чем должны заключаться новые стандарты? Как они помогут нерешаемым проблемам АИ? Какие наконец волшебные слова или промпты найдены, которые должны сделать все прекрасно? - Никто не знает, даже сами АИ-беливеры.
К сожалению, это так. По итогу в долгосрочной перспективе получается дороже и дольше, но кого это волнует? Годовые бонусы получены, а негативные последствия где-то там далеко и их можно будет на кого-нибудь или что-нибудь списать.
Ассиметрия поощрения по Талебу как никогда перекошена.
Оторванные пенсионеры от реальности в костюмах рассказывают мужикам с завода как надо точить болванку с помощью ИИ без регистрации и СМС смотреть онлайн
Пользователь отредактировал комментарий 3 февраля 2026, 13:36
у нас обычно происходит так - чуваки сверху которые в разработке тоже чутка участвуют сначала нагенерят всякой муйни, потом оказывается что проект слишком сложный и нагенеренная муйня не работает. Поэтому она передается обычному гребцу который колупается в этом AI гуане и пытается это пофиксить. Думаю что в итого по времени ни разу не быстрее получается, но начальству очки втерты, бонусы получены, а дальше никого не колупает
Тимлиду ке-паса лайк.
Для меня АИ топчик для прототипирования, для PoC, для документаций, для черновиков всего подряд. Но для продакшн-реди состояния всегда нужен человек чтобы довести до ума. Я отношусь к АИ как к бешеному джуну. Пишет очень быстро и очень много, но все надо объяснять и перепроверять 10 раз. И не верить ему.
Хорошая иллюстрация "как не надо делать" и как, к сожалению, не редко делают. Загенерив кучу воды текст\код совершенно не ревьювается и отдается "as is" дальше. Потом это полотно скармливается AI для summary потому что не читать же эту воду и генерируется новый AI который передается дальше...
Вся эта тема только развивается и все мы еще учимся как применять а как не применять. Сравнить ЛЛМЫ 2 года назад и сегодня это небо и земля. Потом деткам будем рассказывать как мы все были пионерами АИ волны)
вот странные люди. Если предложено "спросить гпт", то эту коммуникацию надо бережно сохранить и всегда иметь под рукой. Далее запустить пару агентов, которые нагенерят план действий прямо по заданию, отревьюят, внедрят, отревьюят внедрение, опишут как выполнен каждый пункт задания (с красивыми диаграммами, ага) и все это счастье запулить прямоу в джиру. Нехай всевозможные менеджеры и разбираются со всем этим слопом, там будет много и вкусно. И ИИ конечно прекрасно аргументирует, что все было сделано правильно.
пы.сы. "делайте как написано", а не все эти митинги для уточнений, разъяснений и т.п. совсем не вчера придумано. ИИ возможно выводит это на новый уровень, но проблема точно не в ИИ.
ШІ-oriented brains be like: карацей, слухай мяне! ідэя на міл'ён: убудаваць ШІ ў лядоўню! во гэта будзе бобма! я вам кажу, такога ніхто ніколі не рабіў! за гэтым будучыня!
Ну, если начальник - идиот, то это не проблема языковых моделей. Я пользуюсь регулярно и считаю модельки хорошим инструментом разработки, который позволяет выдавать результат быстрее. Качество результата зависит с большего от качества модели и качества промпта. Напишите свой промпт и попросите модель представить, что она промпт-инженер и должна улучшить - улучшит. Потом в режим планирования его. И дальше в режим написания. Если что-то повторяется между проектами - агента под эту тему с описанием бест практис с примером. А потом ревьювим и все будет гут. Другой вопрос, когда моделями начинают пользоваться криворукие манагеры и абсолютно бездумно лепить таски через модели, не зачищая галлюцинаций... Наверное, это лечится только созданием прозрачного механизма обратной связи в компании, но для этого, опять же, нужно хотя бы несколько адекватных людей в топ-менеджменте.
Пользователь отредактировал комментарий 3 февраля 2026, 21:19
у меня на одном проекте целый гайд по коуд стайл, какие библиотеки использовать, какие форматы, как делать ревью, какие инструменты подключать для проверки кода, подробная документация по связи между блоками кода, все функции с аннотациями и т.п. Что клод, что гпт простые таски лепят самостоятельно только в путь, прототипы и физибилити стади в более сложных - тоже отлично, и из логов на раз-два вытаскивают все, что нужно. В общем, мне нра.
А мне вот стало страшно, когда представил что там за 200-300 строк и 50 юнит тестов.
Блин, 2026 год на дворе, а люди до сих пор забывают что дополнительные строчки кода это liability а не asset, и платить за их количество - плохая идея
Пользователь отредактировал комментарий 4 февраля 2026, 02:36
Разработчики верят, что если попросить LLM нагенерить 100% покрытие куска кода (увеличив кодовую базу фичи в 4-5 раз), то количество сгенерированных "зелёных" тестов как-то уменьшит количество реальных багов в нём.
А лучше бы пользовались сильной типизацией, и 2/3 этих тестов заменяются обычным exhaustive паттерн матчингом. Но этому в школе не учат, поэтому имеем то что имеем
del
Пользователь отредактировал комментарий 4 февраля 2026, 02:37
закон Амдала: не параллелизуемые процессы не ускоряются
https://bodrovis.tech/posts/zakon_amdala/
"Вообще говоря, этот закон может применяться далеко не только в информационных системах. К примеру, водитель грузовика знает, что ему нужно проехать 2500 километров, а скорость будет составлять условные 100 км/ч. Значит, вся поездка займёт 25 часов без учёта остановок.
Тогда вопрос: если мы предположим, что на участке пути в 1500 километров можно ехать со скоростью в 150 км/ч, то насколько быстрее мы реально доедем? Ответить на этот вопрос несложно.
Участок в 1500 км из всей дороги в 2500 км — это 60%, то есть a = 0.6.
Если мы едем на этом участке 150 км/ч, то k = 1.5, то есть в полтора раза быстрее.
Следовательно, финальное S равно 1.25, иными словами, приедем мы на 5 часов раньше." или позже
Из моего опыта кодирование ни ни одном проекте не было bottleneck и занимало менее 30% времени разработчика. LLM может ускорить эти 30% раза в 2-3 и дать суммарный рост производительности в 15-20%.
Остальное - понимание контекста, анализ и декомпозиция требований, определение что и как делать, как релизить и деплоить, коммуникация и синхронизация между командами. Эти 70% очень тяжело ускорить за счёт LLM, так как скорость конвертации разговоров в промты по сути равна скорости разговоров.
Так, а зачем понимать контекст? Просто фигачишь всякую ерунду и спихиваешь в продакшн, а если кто-то потом не может понять что вообще происходит, то это просто значит они не достаточно аджайл и все такое.
А вы пробовали это? Попробуйте, может ЛЛМ вас удивит :)