Щоденник

Особисті нотатки, думки та статті про технології, роботу й ідеї.

2026-10-18•Yevhen Kim

techaie-commerceagentic commerce

Нова ера ШІ-покупців. Amazon не пускає агентів. Для малих продавців це хибна стратегія

ШІ-агенти вже купують для людей. Вони шукають товари, порівнюють ціни й терміни доставки, перевіряють наявність, а деякі навіть кладуть товар у кошик. Amazon і eBay відповіли тим, що зачинили двері. Для Amazon, на мою думку, це правильний хід. Для незалежного магазину це помилка, яку напрочуд легко повторити.

За даними Semafor, Amazon обмежує сторонніх агентів для покупок і створює власні ШІ-інструменти. eBay обмежує автоматизований доступ, щоб захистити свою торговельну екосистему. Shopify робить навпаки: компанія розробляє інтеграції, через які продавці підключають каталоги й покупки до сторонніх ШІ-платформ, зокрема ChatGPT і Copilot.

Маркетплейс тримається на контролі над покупцем, рекламними місцями й оформленням замовлення. Агент, який порівнює пропозиції, жодного разу не глянувши на банер, б'є саме по цьому. Тож захист Amazon не рефлекс, а розрахунок, і для Amazon він працює.

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

Що вже відбувається

Shopify повідомляє, що в першому кварталі 2026 року трафіку з ШІ-пошуку було вісім разів більше, ніж роком раніше, а замовлень майже у 13 разів більше. Нові клієнти з ШІ-каналів замовляють майже вдвічі частіше. База, імовірно, ще мала. Але канал, де замовлення ростуть швидше за трафік, не іграшка.

DataDome нарахував у серпні 12,5 мільйона запитів від браузерів-агентів, а у вересні 58,2 мільйона. CHEQ у своїй мережі спостереження побачив, як агентський трафік за 45 днів виріс у сто разів, а причиною стали нові споживчі агенти, як-от Meta Muse. Salesforce очікує, що близько 20% трафіку електронної комерції в святковий сезон 2026 року буде пов'язано з ШІ-агентами (помічники для покупок, автоматизовані процеси й моніторинг цін). До сезону лишилося кілька тижнів.

Блокування не є відповіддю

Агенти не лише читають. Серед запитів Meta Muse 8,9% стосувалися форм, входу, кошика, оплати й створення облікового запису. Із 29,1 мільйона запитів за перші дванадцять днів це, за підрахунком, трохи більше ніж 2,5 мільйона дій. Тут не працює жодна з простих відповідей. Заблокуєте все, і разом із усім заблокуєте агента, який саме збирається оформити замовлення для клієнта. Пропустите все, і відкриєте форми облікових записів та оплати для кожного бота.

Тож вашому магазину треба навчитися відрізняти авторизованих агентів-покупців від шкідливих ботів. Це рішення щодо продукту, а не лише завдання для ІТ: кому і що дозволено?

Що б я поставив у роадмап

CHEQ описує, що для цього потрібно магазину:

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

До цього додається другий фронт: власний ШІ-консультант у магазині, який допомагає клієнтам обрати. Хто готує каталог для сторонніх агентів, той для власного консультанта вже зробив половину роботи.

Human Commerce нікуди не зникає. Вашому магазину й далі потрібні гарний дизайн і оформлення замовлення, яке подобається людям. Але поруч виникає другий канал, і в нього інші читачі.

Amazon може дозволити собі не пускати агентів. Ви не можете дозволити собі бути невидимими. Цього тижня відкрийте десять найпопулярніших товарів і спитайте команду розробників, чи видно в логах, які звернення надходять від агентів. Якщо відповідь "ні", це ваше перше завдання перед святковим сезоном.

Джерела

2026-04-29•Yevhen Kim

techaidatabasesRAG

Сліпа пляма архітектора RAG: розглядання векторних баз даних як чорних ящиків

Ми повторюємо помилку баз даних 1990-х років. І це коштуватиме комусь аварійним простоєм.

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

Механізм відмови простий. HNSW - Hierarchical Navigable Small World, стандартний алгоритм у векторних базах - добре працює до 100K документів. Пошук швидкий і точний. Команди його пускають. При 1M документів recall крутіший падати. При 10M ви витягуєте документи, які не мають ніякого стосунку до запиту. Ваша LLM будує відповідь на сміттєвому контексті і звучить впевнено.

Найбільш небезпечне: ваш моніторинг це не ловить. Latency залишається зеленою. Без помилок, без винятків. Система виглядає здоровою. Вона просто повертає невірні результати.

Я спостерігав одну команду. Три тижні витратили на це. Їхня RAG система галюцинувала. Мали чудову інструментацію: latency, throughput, вартість. Але ніхто не вимірював, чи насправді пошук працює. Коли нарешті почали - LLM judge проти ground truth - побачили: recall впав з 0.82 до 0.54 за шість місяців. Latency той же. Релевантність вдвічі менше.

Це не проблема векторної бази. Це архітектура. Команди пропустили ту проектну роботу, яка зробила реляційні бази функціональними.

Коли реляційні бази стали виробничою інфраструктурою, команди навчилися індексувати, стежити за здоров'ям індексів, розуміти запити. Вимірювали, чи працюють індекси. Ці практики зникли з embeddings. Раптом векторний пошук став математикою, не інфраструктурою.

HNSW деградує, тому що embedding простір щільніє. Ієрархія, яка працювала коли документи були розпорошені, стає менш ефективною. Можна збільшити ef_search, але вартість гостра: ef=160 в 3 рази повільніше за ef=40. Команди не налаштовують. Приймають як є.

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

RAG у масштабі потребує того ж. Команди, які поставляють надійний RAG, не використовують чисту векторну схожість. Спочатку звужують пошук фільтрами метаданих - тип документа, домен, дата. Потім векторний пошук на меншому наборі. Деякі комбінують keyword search із семантичним. Розділяють вектори за доменом. Сприймають базу як інфраструктуру, яка потребує дизайну.

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

Зараз команди розгортають векторні бази ніби вони розв'язаний алгоритм. Шість місяців потім якість пошуку ненадійна. Вони здивовані, тому що це ніколи не вимірювали. Це сліпа пляма.

Джерела

2026-04-23•Yevhen Kim

techaiproductionRAGmultimodal RAG

Мультимодальний RAG не готовий до продакшену, і це в порядку

Ми трактуємо мультимодальний RAG так, ніби це неминуче. Це не так. Це гайп, що зустрічається з інфраструктурою, яка не готова, і де-небудь якійсь стартап робить ставку компанії на це.

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

Привабливість очевидна: витягувати документи, діаграми, зображення, відео одночасно. Медична система, яка показує рекомендації та знімки. Юридична команда, яка знаходить контракти і їхні блок-схеми поруч. Ідея чиста. Реалізація - жах.

Почніть з чисел. Мультимодальна модель embedding випускає 1024-2048 вимірні вектори на зображення. Візьміть типову корпоративну бібліотеку: 500K PDF, 3 зображення в кожному. Це 1,5 мільйона embeddings. 4KB на один embedding. 6 терабайт тільки для векторів. Це не проблема оптимізації. Це окремий клас інфраструктури.

Потім - затримка пошуку. Текстова система шукала 100K векторів за 50ms. Тепер 1,5 мільярда. Індекс, який був швидким, стає повільним. Квантизуєте - нижча точність - щоб прискорити. Пропускна спроможність в 10 разів більша. Якість пошуку гірша. Мультимодальна система тепер працює гірше, ніж тільки текст.

Потім fusion. Ви витягли 10 кращих текстових блоків, 10 кращих зображень. Як їх ранжувати разом? Немає стандартної відповіді. Можна use окремі rerankers для кожного типу, потім об'єднати оцінки - більше затримок, більше непевності. Або використати один мультимодальний модель для оцінки пар - повільніше, і він потребує інший embedding модель, ніж використовували для індексування. Нічого простого.

Дані ринку промовлять. Мультимодальний AI буде зростати на 32.7% до 2034. Звучить швидко. Але це $1.6 мільярда в 2024. Текстовий RAG вже $2.33 мільярда, зростає швидше. Більше грошей, більше розгортань, більше готових систем у простішу технологію.

Я бачив, як команди витрачали місяці на мультимодальний RAG. Вибирали моделі (CLIP або LLaVA - різні компроміси), налаштовували квантизацію (зберігання або точність), налагоджували, чому зображення знаходяться добре, але cross-modal ранжування ламалось. Побудували систему, що коштує в 3 рази більше інфраструктури, щоб вирішити те, що простіша система давно могла б обробити.

Насправді ці компанії не потребували мультимодального пошуку. Їм були потрібні OCR документів, індексування видобутого тексту, пошук. Мультимодальний RAG це не вирішує. Просто переміщує складність.

Або візьміть роботу з юридичними контрактами. Команда шукає прецеденти. Текстовий RAG працює. Їм дійсно потрібна блок-схема з іншого контракту, щоб відповісти на питання? Іноді. Не досить часто, щоб виправдати інфраструктуру.

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

Для більшості компаній зараз відповідь: нікакие. Ще ні. Вартість інфраструктури і операційна складність перевищують все, що можуть дати текстові системи.

Мультимодальний RAG дозріє. Інженерія покращиться. Але це роки. Якщо оцінюєте, запитайте: чи проблема дійсно мультимодальна, чи я додаю складність, щоб виглядати інноваційно?

Джерела

2026-04-16•Yevhen Kim

techaiAI-Assisted Developmentpipeline

Чому ваш конвеєр розгортання стане вашою конкурентною перевагою

ШІ дійсно дає перевагу в швидкості. 41% коду, написаного в 2025 році, генерували AI-інструменти. Команди, які їх використовують, мерджать на 98% більше pull request'ів на рік. Це вимірено, це відбувається прямо зараз.

Але ось що чекає на вас: коли генерація коду прискорюється, весь потік не прискорюється однаково. Тиск накопичується на найповільнішій ланці. Для більшості команд це code review.

Візьмемо команду, яка відстежує власні цифри: обсяг PR збільшився на 98%. Час на один review залишився той же. Старший інженер перевіряє AI код стільки ж часу, скільки людський. Математика не сходиться. У вас 2x більше PR'ів та одна й та ж кількість людей. Review стає тим, що зупиняє поставки.

Дальше давить ще сильніше. Більше коду в production - більше треба тестувати. Більша площа для помилок. Veracode виявила, що 45% AI-коду містять OWASP уразливості. CodeRabbit показав: AI код ламається в 1,7 раза частіше, ніж людський. Якщо ваші тести це ловять, добре - є час виправити. Якщо ні, production це виловить.

DORA 2025 про це пишуть ясно: ШІ - це мультиплікатор. Не вирівнювач. Посилює те, що вже є. Сильні команди з нормальним тестуванням і швидким деплоєм стають ще сильнішими. Команди зі слабкою інфраструктурою ламаються видимо.

Чому конкуренти це виправляють зараз

Більшість tech lead'ів, з якими я говорив, дивилися на ШІ як на інструмент продуктивності. Видав ліцензії, люди пишуть швидше, виходить більше коду. Проблема швидкості вирішена.

Помилка. Проблема не вирішена, тільки перемістилась.

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

Коли код був вузьким місцем, тестування можна було дозволити собі не робити ідеально. Розгортання вручну - нормально. Review ловив помилки просто тому, що коду мало і він коштує дорого. Тепер коду багато. Все, що було бажаним, стало необхідним.

Конкурентна перевага не в інструменті. В інфраструктурі, яка насправді витримує навантаження.

Що робити

Подивіться на ваш конвеєр. Не в теорії. В реальних цифрах. Скільки часу запускається test suite? Які помилки дає ваше сканування безпеки? Як часто ви ловите bug'и до production?

Потім запитайте: що ламається, якщо коду стане вдвічі більше?

Якщо код review - перестаньте думати, що старші інженери більше переглянуть. Паралелізуйте, автоматизуйте рутину, залишьте людям архітектуру та логіку. Якщо тестування - ваш test suite раніше покривав мало, а тепер покриває ще менше. Треба паралельні тести, краща інструментація, інші стратегії. Більше інтеграційних, менше юніт-тестів деякою місцях.

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

Можете шукати людей по-іншому. Можуть знадобитися інженери інфраструктури, а не більше розробників. Можете вкласти в інструменти, які не видають features - ті, що валідують, тестують, розгортають.

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

Команди, які я знаю, виграють з ШІ прямо зараз? Не святкують швидкість генерування. Одержимі швидкістю розгортання. Зрозуміли: коли прискорюється вхід, все нижче по потоку стає видимим. Виправляють замість того, щоб терпіти.

Ось це конкурентна перевага. Не красивіший AI. Інфраструктура, яка працює.

Джерела

2026-04-14•Yevhen Kim

techaiAI-Assisted Development

AI у розробці більше не є доповненням - він стає базовим шаром

Кілька років AI у розробці можна було описати дуже просто: дописує код, підкидає шаблони, економить хвилини в редакторі, іноді дає корисну підказку.

Ця фаза закінчилася.

У 2026 році головна зміна не в тому, що AI швидше пише код. Написати код - це вже не кінець. Він збирає контекст, планує, редагує, перевіряє ризики й сам іде далі, аж до пайплайну підготовки до випуску.

Коли AI задіяний одразу на кількох етапах, він перестає бути зручним додатком. Він стає частиною того, як команда насправді працює.

GitHub зробив це видимим наприкінці 2025 року, описавши AI, агентів і типізовані мови як сили,

що спричиняють найбільші зміни в розробці програмного забезпечення за більш ніж десятиліття.

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

Приблизно тоді ж змінилася й система перевірки змін у Copilot. Від моделі, де AI залишає текстові коментарі, до гібридного підходу: аналіз LLM, виклики зовнішніх інструментів і перевірки за чіткими правилами, які щоразу дають однаковий результат. GitHub описує це як

поєднання виявлення проблем великою мовною моделлю, викликів зовнішніх інструментів і послідовних перевірок за правилами через такі засоби, як ESLint і CodeQL.

AI уже не пропонує текст. Він працює разом з інструментами, які команди давно використовують для перевірки коду.

Те саме стосується хмарного агента Copilot, який може дослідити репозиторій, скласти план реалізації, внести зміни в окремій гілці й підготувати їх до перевірки. GitHub називає його

автономним і асинхронним агентом розробки програмного забезпечення.

AI уже не чекає наступного промпту. Він бере задачу, самостійно проходить кілька кроків і повертає результат туди, де команда продовжує роботу. Це і є суть "агентних робочих процесів" - не нове слово для старого автодоповнення, а реальний перехід від разової реакції до участі в кількох пов'язаних кроках.

Коли це відбувається, змінюються й питання, які команди мають ставити.

"Чи варто використовувати AI?" перестало бути цікавим. У 2026 навіть "яку модель ми обираємо?" - вже не той рівень. Корисніше питання: наскільки добре AI вбудований у перевірку змін, тестування, підготовку до випуску, безпеку й контроль якості.

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

Без контролю AI просто пришвидшує шум.

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

Найсильніші актуальні дослідження не описують AI як щось, що автоматично робить інженерію зрілою. DORA у 2025 році сформулювала це одним словом:

підсилювач.

AI підсилює хороші системи й збільшує проблеми в слабких. Команди з реальною дисципліною доставки, нормальними тестами й зрозумілими стандартами отримують більше. Команди зі слабкими основами отримують не зрілість - вони отримують швидшу нестабільність.

Практичні наслідки конкретні.

Перевірка коду стає змішаною системою: AI маркує проблеми, перевірки за правилами підтверджують або відсівають їх, а люди вирішують, що справді ризиковано. Робота зміщується від перечитування всього до керування сигналом й ескалацією. CI/CD уже не може обмежуватися запуском збірки - якщо AI може створювати зміни, виправляти їх і передавати далі, пайплайн має перевіряти наміри, тестувати поведінку й ловити помилки, які модель упевнено пропустить. Якість репозиторію стає реальним вхідним параметром: чим кращі документація, межі архітектури й тести всередині проєкту, тим менше хаосу виникає, коли AI працює автономно.

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

GitHub описав напрям прямо:

Copilot раніше був інструментом для автодоповнення. Тепер це повноцінний AI-помічник, який може виконувати багатокрокові робочі процеси.

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

Питання, чи має AI бути в розробці, уже вирішене.

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

Джерела

2026-04-13•Yevhen Kim

techcreativity

Креативність у розробці - це не про натхнення, а про якість рішень

Про креативність у розробці програмного забезпечення часто говорять надто розмито. Ніби це насамперед про натхнення, незвичні ідеї або вміння «мислити поза рамками». Для інженерної роботи таке пояснення занадто слабке.

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

Тому креативність починається не з відповіді, а з того, як саме визначено проблему. Сильний інженер не просто шукає рішення в межах заданої рамки - спочатку він перевіряє, чи правильна сама рамка. Дослідження problem framing показують, що досвідчені фахівці частіше переосмислюють проблему, тоді як менш досвідчені частіше розв’язують її так, як вона була сформульована спочатку. У розробці програмного забезпечення саме це часто стає вирішальною різницею. Багато дорогих рішень народжуються тому, що надто рано було поставлено неправильне запитання.

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

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

Звідси й нерозривний зв’язок із компромісами. Не існує реальної системи, у якій можна одночасно отримати максимальну гнучкість, мінімальну вартість, ідеальну простоту і нульовий ризик підтримки. Зрілий підхід не намагається уникнути компромісів - він працює з ними точніше. Дослідження design trade-offs показують, що сильні практики не просто обирають найменш поганий варіант у фіксованому просторі рішень. Вони часто змінюють сам простір рішень - переозначують проблему так, що частина початкового конфлікту зникає.

Тому одна з найсильніших форм креативності в розробці - це спрощення. Прибрати шар, а не додати ще один. Обрати вузьке й точне рішення зараз, а не будувати «універсальність на майбутнє» за замовчуванням. Обрати форму, яка витримає реальну експлуатацію, а не вразить на схемі.

Слабка креативність продукує складність - вона любить конструкції, що виглядають розумно. Сильна продукує ясність: скорочує зайві сутності, залежності та винятки. Мета не в тому, щоб вразити конструкцією. Мета - підвищити якість системи.

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

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

Поширення генеративного ШІ робить це ще помітнішим. Чим дешевшою стає рутинна реалізація, тим ціннішим стає людське судження. Нові роботи про ШІ в розробці програмного забезпечення прямо стверджують: програмування - це не те саме, що software engineering, а людське судження, креативність і здатність адаптуватися залишаються центральними. Якщо чернетку реалізації можна отримати швидко, то вибір правильного напряму стає важливішим, а не менш важливим. Якщо код з’являється швидше, то швидше масштабується і ціна неправильної ідеї.

Слабка ідея тепер не просто повільно реалізується. Її можна швидко рознести по сервісах, процесах та інтерфейсах. Хибне архітектурне припущення може множитися з тією самою швидкістю, яка робить поставку продуктивною на вигляд. Погане формулювання проблеми може швидко перетворитися на великі обсяги переконливо написаного коду. ШІ не зменшує значення креативності. Він робить вимоги до неї жорсткішими.

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

У цьому сенсі креативність - не про натхнення.

Вона про якість рішень.

Про здатність побачити сильніший шлях до того, як система встигне обрости слабшим.

Джерела

2026-04-12•Yevhen Kim

techaisecurity

У добу AI безпеку треба вбудовувати в увесь шлях коду до релізу

Ще недавно про AI в розробці говорили переважно через швидкість: швидше написати функцію, швидше зібрати пробну версію, швидше закрити рутинну задачу.

У 2026 році питання звучить інакше: наскільки безпечним є те, що AI допомагає створювати - і наскільки захищеним є весь шлях, яким код, бібліотеки, зовнішні компоненти та інструменти потрапляють у продукт.

Ризик не вигаданий

Оновлений звіт Veracode показав неприємну картину: 45% перевірених зразків AI-коду не пройшли перевірки безпеки та містили небезпечні вразливості. І ще один важливий висновок: новіші й більші моделі самі по собі не дали приросту безпеки. (veracode.com)

Код, який допоміг написати AI, більше не можна оцінювати лише за двома критеріями: чи працює він і чи швидко його вдалося отримати. Потрібен третій: чи не вносить він ризик, який команда побачить занадто пізно.

Чому “кращий AI” це не вирішить

Може здаватися, що проблема тимчасова: наступна модель стане розумнішою й сама почне писати безпечніше. Але на практиці це не так.

AI будує найбільш імовірний варіант, а не найбільш обережний. Він не відповідає за продукт, не відчуває реальну ціну помилки в робочому середовищі й не несе відповідальності за наслідки. Вражаючі можливості моделі ще не означають вищу безпеку - дані Veracode це прямо підтверджують. (veracode.com)

AI може прискорити написання коду. Але він не скасовує потребу в недовірі, перевірці та безпековій дисципліні.

Чому питання безпеки одразу виходить за межі самого коду

У реальному продукті зміна майже ніколи не складається лише з “нового коду”. Разом із нею в систему заходять бібліотеки, зовнішні залежності, скрипти, інструменти збирання, автоматичні процеси перевірки, контейнери, сторонні сервіси та інші компоненти. OWASP прямо підкреслює: програмне забезпечення проходить через цілий ланцюг створення, збирання, перевірки та доставки, і помилка може з’явитися будь-де на цьому шляху. (owasp.org) (owasp.org)

Для AI це має три конкретні наслідки.

AI пришвидшує не тільки написання коду. З кожною змістовою зміною в продукт заходять нові бібліотеки, підключення, залежності. Команда, яка не бачить, що саме вона втягує, просто швидше доставляє ризик.

AI може впевнено запропонувати слабке рішення. Проблема не лише в помилках - проблема в правдоподібності. Код може виглядати чистим і переконливим. Компілюється, проходить lint - і все одно містить слабку обробку даних, зайві права, небезпечні залежності. Він виглядає готовим, тому й іде далі, ніж мав би.

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

Одного AI-коментаря недостатньо

GitHub рухає перевірку коду в Copilot не в бік “ще одного розумного зауваження”, а в бік гібридної моделі. У 2025 році вони прямо написали: Copilot для перевірки коду тепер поєднує аналіз мовної моделі, виклик зовнішніх інструментів і перевірки за правилами через ESLint та CodeQL. (github.blog)

Це важливий сигнал: навіть один із головних гравців у цій сфері не вважає достатнім просто “дати AI прочитати код”. Перевірки за правилами, статичний аналіз, людський перегляд - це не додаткові шари, а база. Один AI-коментар, навіть переконливий, цього не замінює.

Що це означає для сайтів і веб-застосунків

Для вебу висновок простий і жорсткий: будь-який результат AI має проходити той самий повний шлях безпеки, що й код, написаний людиною. Не спрощений. Не “тому що це лише чернетка”. Не “потім перевіримо”.

Безпека в процесі, а не в кінці. Безпека проходить через увесь життєвий цикл розробки: від рішень і дизайну до реалізації, тестування та релізу. OWASP прямо наголошує на цьому. (owasp.org) Якщо безпека не вбудована в процес, швидкість AI просто швидше донесе ризик до продакшену.

Автоматичні перевірки - обов’язковий рівень. Статичний аналіз безпеки, лінтери, перевірки залежностей і технічні фільтри потрібні не як бонус. Саме тому GitHub будує перевірку навколо CodeQL та ESLint. (github.blog)

Залежності - одна з головних площин ризику. OWASP радить вести облік компонентів, мати політики для залежностей, перевіряти походження артефактів і підтримувати контрольований процес збирання. (owasp.org)

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

Безпека “потім” - це вже не просто наївність

DORA у звіті про AI в розробці описує AI як підсилювач: він посилює сильні системи й робить слабкі місця слабких ще помітнішими. Виграють не ті, хто просто вставив AI в процес, а ті, хто вбудував його в здорову інженерну систему з перевірками, тестами й контролем. (dora.dev)

AI не зменшує вимоги до безпеки. Він підвищує ціну їх ігнорування.

Як виглядає зріла позиція у 2026 році

Зріла команда сьогодні:

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

Висновок

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

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

Джерела

2026-04-11•Yevhen Kim

techai

AI не зменшує роль розробника. Він просто піднімає планку

Є доволі популярна думка, що AI робить розробника менш потрібним. Мовляв, якщо машина вже вміє писати код, то й сама цінність цієї роботи падає. Звучить логічно, але тільки якщо дивитися на розробку як на друкування коду. А це, чесно кажучи, дуже бідне уявлення про професію.

Розробка давно не зводиться до того, щоб просто набивати рядки у редакторі. У нормальній інженерній роботі важливіше інше: зрозуміти проблему, не втратити контекст, вибрати адекватний напрямок, зловити слабкі місця в рішенні ще до того, як вони роз'їдуться по системі. І от якраз тут AI нічого не "спрощує" в сенсі відповідальності. Швидше навпаки. Так, рутинного кодингу він справді знімає чимало. І добре. Бо давайте чесно: велика частина механічної роботи й раніше не була найціннішою частиною професії. Шаблонний код, типові обгортки, нудні переробки, шматки документації, тести за очевидним сценарієм. Усе це можна прискорити. Але з цього не випливає, що роль інженера зменшилась. Із цього випливає, що дешевшає саме рутина.

Складна частина роботи нікуди не поділася. Просто тепер її видно краще.

Що змінилося на практиці? По суті, центр ваги зсунувся. Якщо раніше слабкий інженер міг хоч якось триматися за рахунок акуратного, але повільного виконання, то тепер цього вже мало. Коли код можна отримати за хвилини, починає мати значення не швидкість набору, а якість постановки задачі. Наскільки добре ти розумієш, що саме будуєш. Наскільки точно можеш дати контекст. Наскільки швидко бачиш, що запропоноване рішення криве, хоч і виглядає переконливо.

І ось тут, як на мене, найбільше змінюється роль розробника.

Перше: контекст. Моделі сильно залежать від того, що ти їм дав. Якщо контекст дірявий, суперечливий або просто слабкий, результат буде таким самим. Тому вміння зібрати правильну картину, відсікти шум і підсвітити важливе стає окремою сильною навичкою.
Друге: перевірка. AI дуже добре створює відчуття, що "все нормально". Код виглядає пристойно. Коментарі на місці. Тести іноді навіть проходять. Але це ще нічого не гарантує. Я думаю, майже кожен, хто активно користувався такими інструментами, вже ловив себе на цьому неприємному моменті: наче все виглядає правильно, а потім виявляється, що логіка зламана в самому центрі. І що більше швидкості дає інструмент, то дорожче коштує поверхнева довіра до результату.
Третє: архітектура. Робочий фрагмент коду зараз отримати відносно легко. А от побудувати систему, яка не розсиплеться через три місяці, усе ще складно. Можливо, навіть складніше, ніж раніше. Бо тепер погане рішення можна не просто повільно написати. Його можна дуже швидко згенерувати, розмазати по кількох сервісах, обкласти допоміжним кодом і ще й красиво зарев'ювати. Безлад теж масштабується.

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

Тому мені взагалі не дуже близька стара ідея, що цінність розробника визначається тим, скільки коду він може видати руками. Вона й до AI була сумнівною. Зараз вона просто остаточно розвалилася.

AI не робить сильного розробника менш цінним. Він робить слабкість помітнішою. Погане мислення, нечіткі рішення, відсутність смаку до архітектури, невміння перевіряти себе, звичка плутати "працює зараз" із "рішення хороше" - усе це тепер вилазить швидше. Тому питання вже не в тому, чи вміє AI писати код. Уміє. І буде вміти ще краще. Питання в іншому: хто здатен нормально з цим працювати? Хто вміє делегувати машині рутину, не делегуючи їй мислення? Хто може втримати якість, коли швидкість виросла в рази? Оце, власне, і є нова планка. І вона не нижча. Вона помітно вища.

Джерела

2026-04-10•Yevhen Kim

techcode

Чому сьогодні вже недостатньо просто добре писати код

Хороший код і далі важливий. Чиста реалізація, інженерна дисципліна, архітектурне судження - це все залишається фундаментом якісної роботи. Не зникло нікуди.

Але змінилося кое-що інше. Хороший код сам по собі більше не гарантує хороший результат. Команда може швидко й акуратно випустити фічу - і все одно вирішити не ту проблему. Може переускладнити продукт, витратити зусилля не туди або зібрати систему, яка виглядає добре на папері, але слабо допомагає насправді.

Планка для інженера змінилася не тому, що код став менш важливий. Змінилася тому, що ринок вже не винагороджує просто швидкість реалізації. Він винагороджує інженера, який допомагає команді ухвалювати точніші рішення. Де спростити, де поставити під сумнів бриф, де захистити архітектуру, де скоротити обсяг. І головне - де технічно красивий шлях просто не вартий своєї довгострокової ціни.

Це і є справжня зміна.

Довгий час широкий контекст сприймався як додаткова перевага. Якщо інженер розумів продукт і рано бачив компроміси, то це була серйозна конкурентна перевага. Щось на кшталт бонусу до основної компетентності.

Тепер це дедалі менше схоже на бонус. Це нормальне професійне очікування. Причина проста: програмне забезпечення майже ніколи не живе окремо від решти системи. Рішення в одній точці впливає на вартість майбутніх змін, на швидкість команди, на стійкість системи, на користувацький досвід. У такому середовищі хороший код необхідний, але недостатній.

Тому змінилася і оцінка. Сильних інженерів оцінюють за якістю реалізації, звісно. Але також за впливом, судженням і якістю рішень в умовах обмежень. Чи бачать вони, коли проблему поставлено невдало? Чи розуміють, коли фіча додає більше складності, ніж цінності? Чи помічають, коли команда переплутала активність з прогресом? Чи здатні заперечити до того, як дорогий імпульс перетвориться на зафіксовану дорожну карту?

У цьому проявляється інженерна зрілість.

Іноді вона видна в архітектурі. Іноді - в умінні прибрати шар замість того, щоб додати новий. Іноді - у відмові від елегантного рішення через занадто високу ціну підтримки. А іноді - просто у здатності побачити, що справжня проблема взагалі не в коді, а в тому, як сформульовано саму задачу.

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

AI робить цей зсув видимішим. Коли рутинна робота автоматизується, механічне написання коду втрачає унікальність як конкурентна перевага. Вона не зникає. Просто більше не визначає, хто сильний, а хто ні.

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

Дослідження 2026 року це підтверджують. Microsoft показав, що розробники витрачають лише близько 10% дня на саме написання коду, хоча більшість AI-інструментів допоки спрямована саме на цю частину. Інше дослідження про GenAI у розробці показало найбільший ефект у дизайні, реалізації, тестуванні та документації - але центр цінності зміщується до якості специфікації та архітектурного мислення. Що швидше механіка, то видимішим стає судження.

Це важливо, тому що AI пришвидшує не тільки хорошу роботу. Він пришвидшує і поганих рішень. Слаба вимога тепер може швидше перетворитися на гладко оформлену реалізацію. Поверхнева ідея фічі може довше жити, бо прототипування стало дешевим. Команда може сплутати рух з прогресом, тому що output з'являється швидко й виглядає переконливо.

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

Не просто писати код. Розуміти, що варто будувати. Бачити, що слід прибрати. Розпізнавати, де складність не виправдана. Поєднувати технічну глибину з реальним результатом.

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

Хороший код залишається основою. Але він уже не закриває всього питання професійної цінності. Дедалі більше залежить від здатності бачити далі за власну ділянку реалізації: розуміти, що справді важливо, де потрібен компроміс, де варто сперечатися з постановкою, а де прибрати зайву складність - це буде сильнішим кроком.

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

Те, що раніше виразно виділяло інженера, дедалі більше стає базовим очікуванням.

Джерела

2025-11-02•Yevhen Kim

techai

Від виконавця задач до співавтора продукту

Довгий час розробка жила за простою моделлю: продукт формулює задачу, інженер реалізує.

У цій моделі не було нічого хибного. Швидкість, технічна глибина, надійність і якість виконання залишаються важливими. Це нікуди не зникло.

Змінилося інше: як повний опис того, де саме інженер сьогодні створює цінність, цієї моделі вже недостатньо.

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

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

Саме тому сильний інженер потрібен не тільки в точці реалізації. Він потрібен раніше - там, де команда ще може поставити під сумнів сам курс.

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

Саме в такому середовищі дуже швидко стає видно простку річ: якісна реалізація не рятує слабкий задум.

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

Щойно цілі зачиняються, задачі починають текти потоком. Швидкість постачання стає головним мірилом. Розробка легко перетворюється на якісне виконання сумнівного курсу.

Саме тут і змінюється роль інженера.

Різниця між виконавцем задач і співавтором продукту - не риторична. Вона практична.

Виконавець задач отримує формулювання й зосереджується на реалізації.

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

Це не підміна продуктової ролі. Це частина зрілої інженерної роботи.

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

Іншими словами, він допомагає не тільки правильно будувати. Він допомагає не побудувати дисципліновано те, що від початку не варто було будувати саме так.

Сучасна продуктова практика рухається саме в цей бік. Продуктова розробка стає більш кросфункціональною, сильніше зав'язаною на discovery і залежною від швидких циклів навчання між потребами користувача, бізнес-рішеннями та технічними обмеженнями.

У такому середовищі інженерія - це вже не просто отримувач вимог нижче за течією. Це одна з функцій, що допомагає визначати, які вимоги взагалі заслуговують на існування.

Зараз це особливо важливо, тому що AI стискає вартість механічної реалізації.

Прототипи можна зібрати швидше. Сценарії можна перевіряти раніше. Чернеткові реалізації з'являються швидше. Документація, boilerplate і типові перетворення вимагають менше зусиль, ніж раніше. Ця швидкість корисна - але вона змінює економіку поганих рішень.

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

Тому AI не робить інженера менш важливим для продуктового мислення. Він робить цей внесок важчим для ігнорування.

Якщо рутинна реалізація дешевшає, цінність зміщується до судження. Правильно зрозуміти проблему. Побачити обмеження до того, як вони стануть збоєм. Відрізнити сигнал від простої метушні. Обрати сильний компроміс. Вчасно помітити, коли видимий прогрес насправді є лише прискореним марнуванням ресурсу.

Саме тому старе уявлення про розробника як про висококваліфікованого отримувача задач стає занадто вузьким.

Не тому, що реалізація стала менш важливою. А тому, що сама реалізація вже не пояснює достатньо.

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

Цей зсув - не модна надбудова статусу. Це структурний наслідок сучасної розробки.

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

Саме так сьогодні виглядає зрілість ролі:

не просто добре будувати, а допомагати команді точніше будувати правильне.

Джерела