«Час на задачу скарацілі ў 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 часов раньше." или позже
В примере что вы привели нет закона Амдала.)
Корректный пример это если пустить вторую машину с противоположной стороны, что бы они встретились где то посредине. В таком случае закон Амдала будет показывать что параллелизм более N = 2, бессмысленный, т.е. более двух машин.
Из моего опыта кодирование ни ни одном проекте не было bottleneck и занимало менее 30% времени разработчика. LLM может ускорить эти 30% раза в 2-3 и дать суммарный рост производительности в 15-20%.
Остальное - понимание контекста, анализ и декомпозиция требований, определение что и как делать, как релизить и деплоить, коммуникация и синхронизация между командами. Эти 70% очень тяжело ускорить за счёт LLM, так как скорость конвертации разговоров в промты по сути равна скорости разговоров.
Так, а зачем понимать контекст? Просто фигачишь всякую ерунду и спихиваешь в продакшн, а если кто-то потом не может понять что вообще происходит, то это просто значит они не достаточно аджайл и все такое.
А вы пробовали это? Попробуйте, может ЛЛМ вас удивит :)
Большая часть работы это поиск информации - как сделать и в каких места кода нужны изменения. А это агенты тоже делают очень хорошо.
Но да с вами согласен программиста сейчас агенты не заменяют, они уменьшают время достижения конечного результата.