6 інсайтів з Code2Lead про те, як змінюються команди розробки

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Мене звати Ілля Казачковський, Head of Engineering в Dressly. Ми робимо fashion tech застосунок, який допомагає підібрати одяг та образи, такого собі ШІ-стиліста.

Нещодавно SKELAR провів технічну конференцію Code2Lead для senior інженерів у форматі телемосту Київ—Варшава. На події виступили інженери із Netflix, Google, SKELAR, Bolt, MacPaw, Preply та інших tech-компаній. Я був там не просто гостем, а модератором і спікером. Тому мав можливість почути розмови зсередини: про AI, архітектуру, технічний борг, лідерство й те, як змінюється роль інженера в продуктовому IT.

У цьому тексті зібрав найсильніші інсайти, які резонують з тим, як я бачу зміни на ринку. Рекомендую подумати про це всім лідерам технічних команд.

Якщо агент «тупить», це ви недопрацювали, а не він

Ціль, обмеження, приклади, критерії якості. Без цього агент працює на припущеннях і заводських налаштуваннях, і звинувачувати його в тупості немає сенсу.

Олександр Хникін, Backend Guild Master у TENTENS Tech, розібрав це на живому прикладі. Вам надходить тікет від продакт-менеджера: користувач натиснув кнопку «заблокувати», тож чат треба прибрати зі списку активних. Задача начебто елементарна, але якщо її так і поставити агенту, він напише простий метод, який може буквально видалити переписку з бази даних.

Код буде чистий, тести зелені, а разом із чатом зникне вся історія повідомлень. В Social Discovery-продукті історія переписки слугує доказом для розгляду скарг і модерації, тож зникнення діалогів дорівнює безпековому інциденту. І важко звинувачувати в цьому агента: він зробив рівно те, що йому сказали, рівно з тією кількістю контексту. Не більше, не менше.

До речі, про більше. Олександр показував дослідження, за яким автогенерований контекст (той, що агент сам собі дописує «про запас») у середньому підвищує вартість використання ШІ приблизно на 20% і при цьому не завжди покращує якість. Тобто інтуїтивне рішення «дамо агенту побільше контексту, хай сам розбереться» не працює.

Я особисто підготовку контексту вважаю повноцінною інженерною роботою, і поділяю в цьому плані візію Андрія Карпатого. У парадигмі Software 1.0 люди писали код руками. На етапі Software 2.0 люди створюють датасети, прописують цілі й тренують нейронні мережі, а програма зашивається у ваги моделі. Наступним етапом буде Software 3.0, де ми програмуватимемо LLM через промпти, контекст, тули, приклади й інструкції.

У Software 3.0 контекстне вікно стає головним важелем: LLM працює як інтерпретатор над контекстом, який ти йому дав.

Коли агент може працювати автономно

На тому ж виступі Олександра Хникіна почув гарний чеклист, який майже дослівно збігається з тим, як ми працюємо в нашій команді.

Агенту можна віддати задачу на повністю автономне виконання, якщо:

✅ всі задіяні межі й бізнес-правила вже описані;

✅ є тести, якими агент сам перевірить себе.

Зупинятись і кликати людину треба, якщо:

❌ з’являється новий інваріант;

❌ контекст неоднозначний;

❌ потрібна нова домовленість між командами;

❌ йдеться про безпеку, приватність чи гроші.

Той самий принцип працює і для банальнішого ризику: завеликих PR. На панельній дискусії після виступів почув два конкретні рішення від колег.

У Preply написали власний рев’ю-агент: $3,5–4 за перевірку проти $25 за готове рішення від Anthropic. Час до першого коментаря скоротився, а от час до мерджу неочікувано зріс. Фінальне рішення мерджити все одно залишається за людиною, і коли великий PR прилітає від колеги, якому довіряєш, його починають вичитувати по діагоналі. На масштабі команди пропущені проблеми випливають пізніше і сповільнюють усе ще більше.

У Growly пішли простіше: жорсткий ліміт 500 рядків на PR (без тестів) і правило «atomic, але deliverable». PR має бути одночасно маленьким і самодостатнім. Якщо PR — це hook, який ще ніде не використовується, він хоч і atomic, але не deliverable: просто шматок майбутньої фічі, який поки нічого не робить. Кожен інженер має право завернути PR, який не відповідає цій умові, і пояснити, як його краще розбити.

Гроші важливіші за обсяг коду чи токенів

MacPaw колись спалили 10 мільярдів токенів за 3 тижні і навіть отримали за це від OpenAI подарункові статуетки. А потім вони сіли й порахували ціну спалених токенів: за ці гроші компанія могла б найняти ще трьох людей.

Було цінно почути це від Йожефа Гісема, Solution Architect у MacPaw, і я погоджуюсь із ним: велика кількість коду, написаного за допомогою ШІ, скоріше тривожний сигнал, ніж досягнення.

Динаміка деплоїв у MacPaw взагалі показова. До ШІ команда деплоїла приблизно 10 разів на тиждень. Після впровадження ШІ без жодних правил стало 20: код генерувався швидше, але люди боялися заливати його в продакшн, бо не знали, чи є тести і чи взагалі все працює. Коли з’явилися guardrails, які автоматично ловлять 95% типових проблем, страх зник, і команда дійшла до 60 деплоїв на тиждень.

Відслідковую схожу динаміку у своїй команді і пишаюсь планкою, якою ми тепер міряємо успішний онбординг: новий інженер у нас деплоїть в прод у свій перший робочий день.

Технічний борг тепер має нову форму

Раніше технічний борг найчастіше з’являється там, де задачу треба було закрити швидко, а не ідеально. Тепер додався борг, який генерує ШІ. Він підступніший: код виглядає нормально, тести зелені, а всередині вже накопичується проблема.

Найпростіший приклад: той самий агент пише і імплементацію, і тести до неї. Пайплайн завжди буде зеленим, бо агент буквально пише тести під власний код.

Робоче рішення для таких випадків — розділяти агентів. Один пише код, другий, без доступу до контексту першого, пише тести на основі специфікації.

Інші приклади боргу через ШІ від Йожефа Гісема:

• дублювання логіки в різних репозиторіях замість перевикористання спільного модуля;
• копіювання legacy-стилю коду замість боротьби з ним;
• enterprise-абстракція там, де вона взагалі не потрібна;
• борг у самих промптах: один величезний промпт-моноліт починає ламатися від будь-якої нової правки, якщо на нього немає regression-тестів (про це окремо казав Костянтин Цимбал з Google).

До речі, про моноліти. Через ШІ вони накопичуються і в документації. Тут Йожеф підмітив, що в них ШІ-згенеровані solution-design документи роздулися з коротких текстів до 2–4 сторінок, і архітектор, який курує 12 команд, фізично не встигає їх вичитувати. Як рішення, стискати інформацію, вставляти sequence-діаграми і завести окремого ШІ-рев’юера документів, який перевіряє обсяг і наявність обов’язкових секцій.

Я теж наразі сильно відчуваю, що боттлнеком розробки стає кількість та якість людей, та швидкість найму. Парадокс ринку в тому, що роботи менше, кандидатів більше, а шукати їх доводиться довше. У нас пошук команди з трьох бекенд-інженерів зайняв 5 місяців, бо ми шукали end-to-end профайли: людей з фундаментальними знаннями в ширину, де бекендер розуміє і бекенд, і інфраструктуру, і, навіть, фронтенд. Код ШІ генерує швидко, і борг з нього ми вже вміємо чистити. Вузьким місцем стали люди, які цей код скеровують і рев’юять.

Адопція ШІ не стається одномоментно

В Netflix всередині активно використовують модель зрілості впровадження ШІ з п’яти щаблів: від хаотичного використання поодинокими ентузіастами до автоматизації процесів уже поза інженерією.

Стандартизація підходів, якою поділився Іван Лапа, Senior UI Engineer у Netflix, насправді вражає: «Коли стандарт використання ШІ формалізований, як code style, його застосовують приблизно 90 зі 100 розробників. Коли це просто побажання, лише 5 зі 100».

Живий приклад сходження схожою драбиною на панельній дискусії дала Анастасія Тілікіна, Frontend Lead у Growly.

На початку року Growly вивільнив час одного з інженерів і дав йому карт-бланш на дослідження ШІ-інструментів. Інші розробники долучалися добровільно, і зацікавлених ставало все більше. Так з’явилися конкретні практики, які через воркшопи розійшлися на решту команди.

Не все йшло гладко. Спробу повністю автоматизувати сетап A/B-тестів end-to-end довелося відкласти: тікети, описані ШІ, вимагали більше людських точок перевірки, ніж планувалося. Як на мене, це нормальна частина руху драбиною.

Наприклад, у нас для цього два окремі треки. Нетехнічні люди мають повну свободу вайбкодингу: ізольовані середовища, реальні рішення в проді й навіть власний Hall of Fame. Інженери працюють по validated-шляху, який ми називаємо human envelope: AI робить фікс, але автор апрувить його у своєму PR і відповідає за результат.

ШІ дає ілюзію всемогутності, і в цьому є ризики

Як команді не втрачати технічну глибину, коли ШІ бере на себе все більше рутини? Навіть senior-спеціалісти, які активно працюють з AI-інструментами, з часом можуть перестати тримати в голові дрібні деталі, менше питати «чому це працює саме так» і рідше помічати вузькі місця.

На мою думку, цінність технічних знань нікуди не зникла, вона змістилася. Те, що гуглиться чи генерується за 20 секунд, нічого не вартує. Вартують фундаментальні знання в ширину і реальний імпакт. Саме це ми оцінюємо на перфоманс-рев’ю, а не кількість написаного коду. А відчуття «я накидав робочий код на незнайомому стеку, отже, я його розумію» дає ту ілюзія всемогутності, про яку згадувала в рамках панельної дискусії Анастасія Тілікіна.

На її думку (яку я поділяю), якщо рев’ювер питає «чому ти так зробив», а людина відповідає «не знаю, це ШІ», це привід для окремої розмови.

Тому технічна глибина зараз цінна як ніколи, і цей майндсет має йти від хедів та лідів.

Показовий приклад розповів Михайло Іванов з Monobank.Продуктові й бізнес-аналітики почали використовувати агента як single point of truth: завантажували дані й просили пояснити, чому, наприклад, впала конверсія. На основі ШІ-висновків приймалися рішення на десятки тисяч доларів, а за місяць виявлялося, що агент помилився.

Висновок доволі очевидний: довіряй, але перевіряй.

Як це все виглядає в стартапі

Замість підсумку, короткий чеклист того, що з цього вже працює в нашій команді:

• Контекст для агентів пишуть і рев’юять люди; він мінімальний і лежить поруч із кодом.
• Human envelope для інженерів: AI робить фікс, автор апрувить у своєму PR. Для нетехнічних вайбкодинг в ізольованих середовищах.
• Код і тести пишуть різні агенти, на критичні промпти стоять regression-тести.
• Ефект ШІ міряємо грошима, lead time і change failure rate.
• Ліміт на розмір PR, кожен має право завернути завеликий.
• Стандарти використання ШІ формалізовані, як code style.
• Перший деплой в прод у перший робочий день для кожного нового інженера.
• Бізнес-висновки агента перевіряємо у своїй системі, перш ніж приймати рішення.

Якщо у вас є свої кейси чи заперечення, welcome в коментарі. Буду радий подискутувати.