підсвітити сліпі зони

Цікаво, чому акцент не на цьому, а на «зняти рутину». Адже якщо людина пул реквест дивиться все одно (і робить це якісно) ні про яку економію часу мова насправді не йде. Але якщо агентське рев’ю допомагає знизити кількість факапів які доповзли до прода (що до речі повинно бути нескладно виміряти) — це цілком собі цінність.

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

Все вірно, тільки навпаки :)

Код подивитись — це не кінцо подивитись. Ти зараз бачиш в коді патерни погані та корисні, у тебе зараз тригериться інтуіція («стоп, а це точно вірно?» чи «опа, а тут можуть бути дракони») тільки й виключно тому, що ти свого часу витратив десятки тисяч годин на колупання в цьому руками.

Перестанеш писати й дебажити руками — ти звісно не втратиш здатності читати код й _загалом_ розуміти що там відбувається, але твої ревью будуть все більш більш shallow. Спочатку ти перестанеш бачити тонкі нюанси (ну типу цей код на сі виглядає простим і зрозумілим, але оте UB яке ти вже не бачиш насправді перетворє його в сміття), а пізніше й нормальну архітектуру від рахітектури відрізнити не будеш в стані.

Але не буду тебе переконувати — сам побачиш.

наші агенти розрулють нетрівіальні кастомер кейси з саксес рейтом 80%

Він і без логів норм справляється.

віллі вонка мем жпг

либо вы научитесь, либо не сможете найти следующую работу

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

Я думаю це просто погане формулювання. Вони не логи забули прикрутити як такі, а тулінг щоб агенти що розгрібають сапорт реквести могли ці логи бачити у притомному вигляді.

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

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

LLMки додають новий вектор атаки. Читав нещодавно дослідження (Anthropic, Alan Turing Institute, якісь секьюріті лаби — поважна банда) яке показало що для «отруєння» моделі потрібно набагато меньше даних ніж вважалось раніше, і більше того — кількість потрібних отруєних семплів є майже константою незалежно від розміру моделі.

що ви не зовсім вірно зрозуміли сенс топіку.

Доволі цікава заява від людини, яка не є автором топіку. Якщо це свідомий маневр — знімаю капелюха, пан знається на маніпулятивних техніках.

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

не можемо рев’ювити все

ручного контролю кожного рядка

не поклавши при цьому прод

бачити, що метрики впали, сам відкочувати зміни

Це не про SDLC? А про що, вишивання хрестиком чи може лікування апендициту?

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

Я так розумію ви пропонуєте від обговорення початкового питання перейти до змагань зі схоластики?

В топіку йдеться про швидкість «генерування рішень», а це аж ніяк не те саме що генерування коду

В топіку йдеться про

AI генерує код чи рішення

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

сам бачити, що метрики впали, сам відкочувати зміни

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

Хіба хтось пише код заради коду?

Так я приблизно це й питаю вище, хіба що іншими словами :) Бо тема зводиться до «давайте приберемо man in the loop щоб не заважати агентам писати більше коду». Писати більше коду щоб що?

А нетскейп точно-точно програв через брак якихось фіч, а не через дистрібуцію та platform power вінди? :)

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

Мені цей дискурс невловимо нагадує XY problem.

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

Тож яку саме проблему ми намагаємось вирішити?

Інколи мені здається, що я така сама LLM-ка, є контекст, мій мозок генерує наступний токен.

Хто/що генерує наступний токен — питання другорядне. Ключове питання тут «хто пише промпт» :)

Такої теорії змови я ще не чув, цікаво :)

Junior-спеціалісти з ШI стали продуктивнішими: один розробник може генерувати вдвічі більше коду.

А навіщо вам вдвічі більше лайнокоду?

Глибина для Senior: RDBMS вимагають суворої нормалізації (аж до 3NF або форми Бойса-Кодда), щоб уникнути аномалій.

Це глибина не «сіньор», а «студент політеху». Від сіньора очікується розуміння того, що висока нормалізація, referential integrity і теде це не халявний ланч і іноді потрібні адекватні компроміси.

На поточний момент, проблема яка 100% маячить на горизонті це те що замість 10 інженерів потрібно буде 4. Потім 2, потім 1.

Ти ніколи не задавав собі питання чому ми багато років (до ШІ хайпу) систематично чули про великі лейофи в фаангах, але якщо подивитись на динаміку кількості голів за років 10-15, побачимо дуже й дуже значний зріст? Ажде якщо ви можете звільнити 10К й «стало тільки краще», то нафіга заново нагрібати?

А відповідь «дуже проста» — будь-яка бюрократія вміє тільки розширюватись. Вплив менеджера в будь-якій компанії пропорційний кількості його підлеглих, крапка. Тому оті всі віпі оф інжинірінг, сітіо і ішний технічний С-левел будуть першими хто буде заважати сценарію «було 10 кодерків став 1». Бо який ти нафіг віпі оф інжинірінг, якщо у тебе штат це півтора інваліда? :) Набрав людей під складний проект, зарелізив — ай умнічка, тримай бонус. Потім звільнив частину, оптимізував кости — ай умнічка, тримай бонус. Rinse, repeat.

Додай до цього проблему accountability — грубо кажучі «з кого питати в разі чого».

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

Реалії в великій компанії з mission critical кодом: stripe.dev/...​-end-to-end-coding-agents

Та читав я про ці реалії. Так само як читав вчорашній анонс Антропіків щодо Claude Code Review, як і багато чого іншого. Я хоча й скептик, але не ідіот щоб ігнорувати реалії :) Але якщо читати уважно, то буквально у всіх випадках, і Страйп не виключення, прямо чорним по білому пишуть про обов’язкове рев’ю шкіряними мішками і теде. Тобто наша дискусія певним чином заходить на друге коло, бо схоже що навіть бест ін класс тулінг та state of art агентський пайплайн не дозволяють виключити людину з процесу.

Зараз, достатньо подивитися саме shallow: воно або робить взагалі не те (буває), або те, й відразу нормально.

Я вважаю це все ж таки спрощення. Між «взагалі не те» й «те й відразу нормально» є безліч варіантів й немає жодних фундаментальних причин чому воно не може зробити «майже ідеально якби не оцей неприємний важкопомітний бажек».

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

Для дуже дуже простих функцій це теоретично можливо (запаралелили ненадійні функції й прикрутити якийсь консенсус, навіть тупу мажоріті голосувалку і тепе), але ж код це трохи інша історія ніж «годиться/не годиться». Що робити якщо агенти-ревьювери знаходять різні проблеми чи навіть протирічять одне одному? Прикрутити контролера над контролерами? (якого теж треба контролювати бо він же теж навіть в синтетичних бенчмарках тільки 90% задач віришив вірно).

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

Я розумію що з іношого боку «практики у яких це працює», але ми зараз в стадії коли що не видно довгострокових ефектів.