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

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

Код працює, але що саме відбувається всередині?

«Я інженер у Meta, і ще ніколи не почувався настільки некомфортно, виконуючи свою роботу», — написав Хаміє.

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

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

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

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

Хаміє поставив це питання іншим фахівцям: чи відчувають вони те саме?

«Це не проблема Meta — змінюється вся інженерія»

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

Після численних відповідей Хаміє написав окреме уточнення. За його словами, він не намагався описати специфічну проблему Meta: подібні відчуття виникають у нього і під час роботи над власними проєктами поза компанією.

«Це не проблема Meta. Це проблема інженерії», — наголосив він.

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

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

Три способи не втратити контроль над кодом, згенерованим ШІ

1. Більше уваги приділяти проєктуванню.

За словами Хаміє, робота починається ще до генерації коду — із запиту до ШІ та проєктування майбутньої системи. Розробник має зрозуміти, що саме модель повинна побудувати, які компоненти будуть у системі та як вони взаємодіятимуть.

2. Більше тестувати.

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

3. Просити ШІ пояснювати й візуалізувати систему.

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

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

Чи потрібно розробникам розуміти кожен рядок?

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

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

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

Хаміє погодився, що розуміння системи через діаграми й розмови з агентом допомагає, але наголосив: навіть за такого підходу дискомфорт нікуди не зникає. Важливий іще один рівень — перевірка результатів та наявність доказів того, що система справді працює.

Ризик — не лише помилки, а й втрата навичок

Інші коментатори звернули увагу на довгострокові наслідки переходу до генерації коду за допомогою ШІ.

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

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

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

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

«Токени коштують більше за інженерів»: в EPAM Ukraine розповіли, чому AI не замінить розробників

По темi

«Токени коштують більше за інженерів»: в EPAM Ukraine розповіли, чому AI не замінить розробників

Читайте головні IT-новини країни в нашому Telegram

По темi

Читайте головні IT-новини країни в нашому Telegram