Чому всі хейтять вайбкодинг? Ви просто не вмієте його готувати

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

Але давайте будемо чесними: ви хейтите це просто тому, що не вмієте цим користуватись.

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

Головне завдання розробника (і цілого відділу) — доставка працюючого «продукту» згідно з ТЗ. Бізнесу глибоко фіолетово, скільки літрів кави ви випили й чи набивали ви кожну дужку своїми «золотими ручками». Їм треба результат. Швидко. Якісно.

Ніхто ж не змушує обов’язково писати тисячі рядків коду руками, як у 90-х. Це тупо неефективно.

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

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

Мені вся ця ситуація з «олдовими» принципами нагадує той анекдот:

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

Підписуйтеся на Telegram-канал @gamedev_dou, щоб не пропустити найважливіші статті і новини про геймдев

👍ПодобаєтьсяСподобалось11
До обраногоВ обраному0
LinkedIn

Найкращі коментарі пропустити

Смішно те, що ця стаття теж написана ШІшкою (або як мінімум сильно підредагована нею) але якщо закрити на це очі, то вайбкодинг і використання в роботі ШІ це дві різні речі. Вайбкодинг це буквально все перекласти на ШІшку, і про ніяку якість тут і мови не може йти. Проте якщо 60-70% коду написані ШІ, і 30-40% вручну, це зазвичай норм. Бо зазвичай ШІ як раз бракує тих 30-40% щоб довести код до розуму, а не віддати сиру «каку». І навіть з часом сильно сумніваюсь що це відношення зміниться

Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Создатель Deno и NodeJS:

This has been said a thousand times before, but allow me to add my own voice: the era of humans writing code is over. Disturbing for those of us who identify as SWEs, but no less true. That’s not to say SWEs don’t have work to do, but writing syntax directly is not it.

fxtwitter.com/...​/2013280952370573666?s=20

но что он понимает вообще, куда ему до местной ДОУ-интеллегенции :)

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

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

writing syntax directly

".

открою секрет: даже сейчас активные пользователи agentic coding в большом количестве

пише напряму синтаксис«

ежедневно, несмотря на то что

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

возникает подозрение, что пан далек от программирования. заглядываем в профиль, а ведь так и есть!

Тестувальник, просвітник

а попросту живая иллюстрация: «Кто умеет — делает, кто не умеет — учит других»

просвітник, my ass....

Якщо ось це iread.com.ua що у вас у профілі є тією самою «стравою» яку ви готуєте через vibe coding — то налаштуйте розміри логотипа у хедері, бо в вас він поплив від примусової 150 ширини та 110 висоти.

Це не та страва, Читайлик це моя гордість що приносить користь ще з 2018.
Дякую, доберусь то гляну.

тисячі рядків коду руками, як у 90-х

Не знаю як ви, а я дійсно в 90-х вже писав код. Так от з мого досвіду:
По-перше: вже були різні Wizards, з використанням яких можна було створювати код для типових рішень.
По-друге: тисячі рядків коду руками — це поки немає напрацьованої кодової бази. Коли вона вже є, то copy-paste нічим не гірший за використання ШІ. В тому числі достатньо було один раз створити код за допомогою Wizards, а потім його просто копіювати.

Про таке важливо казати, адже ШІ-ентузіасти дещо закопуюсь самих себе, коли чомусь порівнюють генерацію коду «ШІ» з станом, коли кодер все пише руками, хоча це вже дуже давно не таке. Автокомпліт часто пише більше коду, ніж людина. Готові шаблони існують в тих же IDE. FastAPI автоматично створює OpenAPI документацію та Swagger до неї, взагалі нічого писати не треба. Django та інші фреймворки з «батарейки у комплекті» дають цілі структури, разом з архітектурними шаблонами та навіть GUI.

З нуля я написав для себе рулетки, що обирає питання для співбесіди за категоріями (для проєкту на ютубі), і користувався для цього ChatGPT, що ок. Воно доволі криво написано, але мені лише демонструвати екран з рулеткою треба, і для цього рішення достатньо гарне.

Просто дивовижно, як раптом «забули» той факт, що сучасний розробник майже не пише руками код, особливо, коли йдеться про так звану «рутину».

І я не проти міряти ефективність «ШІ»-генерації, бо вона точно багато де буде давати більшу швидкість. Ось лише порівнювати треба з реальними підходами, а не з вигаданими, де розробник пише код у notepad (навіть не у notepad++).

Візарди в дев’яностих? не пригадую жодних, це ж допотопні часі популярності паскаля та пізніше Делфі 5, С та С++ . З помічників хіба що скрепку у ворді згадаю.

Мабуть треба змінити аватарку щоб не вводити в оману, оце прикладаю підручник до болючих місць коли погода змінюється. Хоча правда раді — саме «дівелопером» не працював у своїй ІТ кар’єрі.

Візарди в дев’яностих? не пригадую жодних, це ж допотопні часі популярності паскаля та пізніше Делфі 5, С та С++

в Visual C++ 6 был уже Class Wizard, а это точно 90-е. ну в Дельфи с первых версий бойлерплейт генерировался. ставить в один ряд с современными AI кодогенераторами, конечно, глупо...

Але давайте будемо чесними: ви хейтите це просто тому, що не вмієте цим користуватись.

— так, давайте будемо чесними. Ви зараз навʼязуєте смачний ярлик без будь-якого сенсу

Ось ще один ракурс.

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

Якийсь Василь не обов’язково гарно вчився, а потім роками створював вебсайти для інтернет-магазинів (при всій повазі).

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

На що Петро каже, мовляв — ймовірно, твої сайти, Василю, цей інструмент і може створювати. У будь-якому разі я не заважаю тобі робити це. Але я краще знаю, чи цей інструмент достатньо професійний для моєї роботи. І наразі — ні, не достатньо. Можливо, в майбутньому. Але не зараз.

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

«Water if for toilets — drink Brawndo! It’s got electrolytes!» (з фільму «Ідіократія»). У фільмі всі вірили в те, що цей напій краще за воду, а отже краще й для поливу сільськогосподарських рослин, що призвело до втрати 100% врожаю. Але як проста вода може бути кращою за чудовий напій? З електролітами ж!

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

Але поки Петро каже, що інструмент не пасує для його роботи, чому всі (крім колег Петра) намагаються переконати його у зворотному? Бо «містить електроліти!»?

Якийсь Петро гарно вчився, а потім роками створював
Петро перекваліфікується, але визнає нову правду.

Петро отримував поточну кваліфікацію роками навчання + роками досвіду.
І зараз Петру 40+ років, його навички не потрібні. Не іза Василя, але іза іншого Петра, котрому тепер достатньо замість 10 Петрів у додаток — 10 Василів, а здатність перекваліфікуватися швидко — значно нижча, ніж 20 років тому.

Тут вже багато написали за останні дні.

І про різницю vibe coding та AI assistance.
І про те, що LLM зможе в контекст далеко не кожного проєкту, а до деяких проєктів їх взагалі заборонено підпускати за вимогами контракту, NDA чи іншого папірця.
І про різні метрики, методології та підрахунки.

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

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

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

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

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

Тому для мене це дійсно робочий інструмент, але треба добре розуміти весь стак — від бізнесу, цінностей, менеджменту вимог (бізнес та системний аналіз), апп дизайн і особливості мов програмування. Для досвідчених лінивих інженерів це мастхев!

довгі тире тут сам місцевий форматер ставить в постах, коментах ;)

довгі тире тут сам місцевий форматер ставить

Так, я в курсі. Але навіть якби цей коментар написала нейронка — я не бачу в цьому особливих проблем. Зрештою, це особиста справа.

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

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

доставка працюючого «продукту» згідно з ТЗ.

Таке вирішення задачі у лоб потім плавно перетікає у те, що у наступні ітерації 80% бюджету треба спрямувати на переписування Г-кода від low-iq розробників, які навіть базові речі для розширення у майбутньому не можуть передбачити (наприклад захардкодити список типів через константи замість динамічного списку — на етапі розробки-проектування це максимум плюс пара годин роботи, переробка цього виллєтся у 2+ тижнів кропіткої роботи пізніше усих залучених команд).

Вся проблема хейтерів — у відсутності скіла комунікації з нейронкою.

Проблема любителів г-в-кодити — відсутність будь яких стандартів написання коду. Для них все що хоча б якось запустилось та працює — це вже все збс можна виписувати премію.
low-iq персонаж у поєднанні з вайбкодінгом — це взагалі зло.

PS всюди є виключення.

вайбкодери нічого з цього не розуміють.
вони ж не професійні розробники :)

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

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

вони ж не професійні розробники :)

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

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

І так — прикро, що бізнес також не завжди копає в глибину.

Здається ви дуже глибоко копнули. Проблема на поверхні.
Тут геть відсутня маленька, але дуже важлива фраза.
Має бути:

доставка працюючого та підтримуваного «продукту» згідно з ТЗ.

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

было бы супер, если бы ты мог раскрыть такие вопросы, чтобы была лучше понятна ситуация:

в какой айкью брекет себя относишь? чем при этом руководствуешься?
приходилось ли тебе в принципе делегировать задачи? как обеспечивал отсутствие говнокода?
что мешает сделать фокус на проектировании?

спасибо!

1) 136 десь було у школі, тестування проходив у обласній психіатричній лікарні.
2) звичайно, зазвичай результати відносно плачевні, бо сіра маса не хоче працювати, вона прийшла у ойті за баблішком і результати їх мало цікавілять.
3) ручками забезпечував при перевірці ПР і тд і тп
4) шо заважає? Відсутність можливості клонування себе і виконання роботи не тільки за себе, а і за усих інших.

неироничное спасибо за подробности!

мне кажется ключевое тут:

ручками забезпечував при перевірці ПР і тд і тп

вот это «итд итп» — на самом деле очень весомая часть, если не основная. важно не просто отдать задачу, а проговорить/проверить какой-то основной план/идеи.
и тогда результат будет минимально отклоняться от ожидаемого результата, а потенциальные проблемы будут локальными, а не глобальными — а значит их легко будет исправить

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

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

За нею потрібен контроль постійний і валідація (хоча б на рівні розуміння) що воно робить.

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

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

Звичайно, якщо мова іде про формошльоперство — AI тут доволі потужний існтрумент, коли є готова архітектура і задача AI Тільки накидати вьюшки — тут він непогано справляється :)

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

признаюсь, я не сильно успеваю за 136 айсикью потоком мысли со всеми этими плагинами

что мешает анализировать плюсы и минусы до того как код написан вместо того чтобы сразу нажать аксепт олл чейнджез?

Автор плутає вайб кодінг і ші асістант. Вайб кодінг як раз таки передбачає «вимкнути мозок». Але загалом про це вже багато написали.

Г—а—р—н—а с—т—а—т—т—я

Оце людей тригеряд довгі тире. Вам контент чи форматування? ))
А існують жиж сервіси визначити чи це АІ генерований контент, іду перевірюсь

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

А методології тіпа spec driven development це не вайбкодінг. А як в одному докладі було — вбивця вайбкодінгу.

І от тут і з’ясовується, що ті що кажуть про вайбкодінг, зазвичай не розуміють про що саме вони кажуть :)
і вважають що Java та Javascript то одне й те ж саме.

Чекайте чекайте, а ви пробували в Cursor or Google Antigravity? Це ж і є spec driven development. Мабуть нові терміни треба Agent Driven Vibe Coding.

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

Чекайте чекайте, а ви пробували в Cursor or Google Antigravity? Це ж і є spec driven development.

SDD була задовго до agent_name; а от agent_name як раз гарно підходить для цієї методології як інструмент. І як будь-яка методологія, SDD має свої обмеження, плюси та недоліки.

А ви намагаєтесь змішати усе в купу. Тут підходить вираз (який мені особисто не подобається): «Коли в руках молоток — усе навколо здається гвоздем». Сам же вайбкодінг має мало спільного зі spec-driven.

В будь який період розвитку можна сказати «А от раніше було краще».

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

І благаю, не сприймайте наступне, як особисту образу. Я геть не бажав такого ефекту.
Проблему викликають адепти-вайбкодери, які:

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

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

---

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

Та які образи, все вірно. Дивімось у майбутнє, через рік-два буде ще більше (запамятайте цей твіт). А незабаром і в job requirements буде вміння користуватись АІ тулами і на інтервью показуй «як користуєшся».

Повторюсь зі статті:
>від цього нікуди не дітись. Це не хайп, це еволюція інструментарію.

До речі, в нас в матрицю компетенцій сініора на цей рік вписали AI

вірно вписали.
бо багато з того що треба для ефективного використання ШІ агентів — і була в матриці скілів сіньора до ШІ.

Прямо так і вписали парасольковий термін «ШІ», без жодної конкретизації?

Звісно ні. Там генерація кода, аналіз логів, діаграми і так далі

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

Та хз насправді. Якщо хочеш промо, треба щось написати 😁

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

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

Цікаво з професійного боку, бо синйор, я думаю, буде цікавитися — чому саме це рішення ми називаємо кращим? Чому не інше? Й всяке таке.

Де точно ця властивість моделей влучна — це там, де нам потрібно зробити несподіваний аналіз в несподіваному місці. Там, де об’єктивно не було можливості зробити краще рішення, а треба хоча б щось, але тут і зараз. Тут без моделей можна сидіти годинами з нульовим результатом. Проте, питання тут теж маю — про те, що це за випадки такі та наскільки вони очікувані в певному життєвому циклі ПЗ. Особливо, якщо тепер без цього мене не зможуть вважати синьйором.

Це гарне питання, на яке я не готовий відповісти повністю. Графана та алерти звісно є, вони нікуди не ділись. Сервіс не буде прийнятий у прод без налагодженого моніторингу.

Також коли приходе алерт, там є лінк на доку, що робити. Звісно вони не завжди гарної якості.

Чому саме? Менеджмент так вирішив на сьогоднішній день.

Дякую за змістовну мінідискусію, було корисно. Рідкість зараз, щоб емоційно не уходити в крайнощі через присутність в розмові літер «ШІ».

Я особисто не вірю в те, що за пару років агенти просунуться настільки, що їх можна буде вписати у вимоги до проєктів масово. За умови, що PM/PO не самодур, звісно.

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

за пару років агенти просунуться настільки

о, пару років з темпами змін — це вважайте як десять раніше.

сумуючи усякі прогнози — у GenAI є ще куди вдосконялюватись, пару років. Якщо не з’явиться нової архитектури — то розвиток впреться у стелю.
а у агентів теж — ще є куди. в самого ідей повно, хоч приєднуйся до opencode чи подібних.

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

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

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

о, пару років з темпами змін — це вважайте як десять раніше.

Я навіть сперечатись не стану. Зараз я програмую «набігами», коли співдають зірки та можливості, і можу сказати, що з кожним моїм поверненням до клавіатури — прогрес величезний. Але моя ставка як раз на те, що він кінечний, і з часом вже буде нікуди прогресувати далі — «упреться в стелю».
---
Якщо хтось спитає: «А що ж нам треба, щоб цього не сталось?»; відповім: «Я не знаю!»
Якби знав — я би вже у це активно інвестував, а потім сидів би на купі грошей; або хоча б в пакет «Нової пошти» їх складав.

Є відоме правило 80/20. Якщо перекласти на наш процес: 20% задач з’їдають 80% часу.

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

Подивіться на IDE. За 20 років там космос, але розробники у Vim з плагінами часів динозаврів непогано почуваються.

Подивіться на IDE. За 20 років там космос, але розробники у Vim з плагінами часів динозаврів непогано почуваються

А що за космос? З останнього суттєвого для «динозаврів» що дійсно зручно з *vim то lsp підтримка (і важливо що майже для всього що можливо і доволі швидко додається з того що з’являється нового)

З того, що на поверхні:
— інтегрований термінал (ага, колись це були різні речі; я знаю, що технічно воно так і лишилось, але ми не про це)
— статичний аналізатор у бекграунді
— підтримка тест ранерів

Там дійсно багато чого помінялось за дві декади. Треба визнати, що умовна ide_name має з коробки те, для чого я років так 5-ть збирав плагіни для Emacs.

Тому приклад доволі релевантний, я вважаю.

порівняємо з «динозаврами»

— інтегрований термінал

в принципі з *vim і працюють зазвичай в терміналі — організувати та розподілити на підвікна можна як у редакторі так і в самому терміналі (в залежності що саме треба) — тобто підтримкою термінала важко здивувати

— статичний аналізатор у бекграунді

це відпрацювання з lsp мається на увазі? так і нп з nvim відпрацьовує аналіз у бекграунді — з warnings/errors/hints/etc, і плюс що з lsp мабуть значно більше опцій (що є з тим що підтримується) — ніж в «студіях»

Оу... Мені здається ми не туди звернули.
Я просто перелічив, що додали в IDE за останні N років. І геть не збирався порівнювати якусь «студію» з vim чи схожим.

Як я сказав нижче: так можно майже про що завгодно сказати. Порівняйте спецефекти у фільмах, комп’ютерні ігри, і т.п. Майже будь що дуже сильно змінилось за 20-ть, 30-ть, N років.

ШІ також доволі сильно виріс від моменту його появи на загальній публіці.

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

я і запитав що за космос, бо таксамо і навпаки діє

Подивіться на nvim. За N років там космос, але розробники у IDE з плагінами часів динозаврів непогано почуваються

Здається ви занадто сильно зфокусували увагу на IDE та *vim.
Я сприйняв згадування IDE виключно як приклад.
Загалом, майже про що завгодно так можна сказати.

Подивіться на X. За N років там космос.

Так, як і «студії» так і термінальний нп nvim прогресують слідуючи за сучасними потребами (причому imho останній мабуть навіть і більш динамічно).

SDD була задовго до agent_name;

Звісно. Називалась ця методологія — waterfall

А ви намагаєтесь змішати усе в купу.

Навпаки. Якраз я бачу радикальну різницю між вайбкодінгом і різними видами SDD.

Сам же вайбкодінг має мало спільного зі spec-driven.

ну да.
про те й кажу — люди рухаються в бік spec-driven і чомусь кажуть про вайбкодінг :)

Звісно. Називалась ця методологія — waterfall

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

А ви намагаєтесь змішати усе в купу.

Навпаки. Якраз я бачу радикальну різницю між вайбкодінгом і різними видами SDD.

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

будь яка методологія має мало спільного з вайбкодінгом.

Нє, є одна.
На зараз — сама поширена:
Аджайл у імплементації — «хуяк ***к і в продакшн» :)

І прикол в тому що:
— з одного боку ШІ агенти надають таку можливість- аджайлити, хоча й поки швидко впираються в ліміти постачальників. (активний вайбкодер, з трьома моніторами, виїдає пакет CC Max у 100$ за тиждень)
— а з другого, щоб виходили пристойні рішення, «кодити» рулів, скілів, спек — доводиться чимало, тобто треба рухатись в бік «водоспаду». Оновленому звісно, бо ШІ дозволяє отримувати фідбек від імплементації набагато швидше, ніж раніше.

Це ж і є spec driven development ...

тобто вам треба пояснювати «різницю між Java і Javascript»?

Багато споречань через miscommunication, давайте визначимось, якщо я перестав писати стрічку коду у скрипт, то це як зветься?

то це як зветься?

дауншифтінг мабуть.

в мене Windsurf показував ще влітку минулого року 84% сгенерованого коду.
Думаю прибрехував трішки.

зараз на Copilot, і код практично не княпаю. думаю десь за 90% сгенерованого.

але, є ще куди.
бо руками я взагалі більш 30 років коду не писав.
Клавіатура писала!

а тут ще приходиться, то підправити рядочок, то приклад у скіл додати...

Це використання LLM як помічника при наборі.

Ага, особенно курсор, который блокирует после каждого запроса ide, чтобы ты не отклонял его изменения...

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

Оце вас бомбануло. Так, ШІ правив форматування та граматику, не приховую і нижче уже писав.

Та трішки розбираюсь, лізу. Вимбачте :)

Perfect code is an illusion. Daniel Irvine

— це я мінус написав

В нас на стільки здоровезний проект, що жодна ШІ не може нормально в його контекст, та і не треба, бо навіть те, що воно випльовує — це нереальне Г, коли в тебе багатомільонний проект.

От в інших чомусь можуть а у вас ні: claude code пише нові сервіси за тиждень, cursor вже без втручання переписує з одного стеку на іншій цілі проекти. Просто не треба пихади в одному вікні всю кодову базу

claude code пише нові сервіси за тиждень

LLM доволі сильні у greenfield, це дійсно правда.
Але я не думаю, що цей конкретний кейс про це.

cursor вже без втручання переписує з одного стеку на іншій цілі проекти

І тут погоджусь, LLM гарно роблять міграції A —> B, але у випадках, де правила явні.
Але я також не думаю, що цей кейс сюди підходить.

Claude Code/Cursor/ гарно пораються, якщо:
— контекст подається дозовано
— людина керує рамками задачі

LLM не тримає «живу» модель системи, як це робить senior/architect, який:
— пам’ятає чому щось зроблено дивно;
— знає, де не можна чіпати;
— відчуває ризики не з коду, а з контексту бізнесу.

Що я бажаю сказати:
Eugene каже з позиції відповідальності за наслідки
Bohdan — з позиції інструментальної ефективності
Правда, швидше за все, десь посередині.

---

От в інших чомусь можуть а у вас ні

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

claude code пише нові сервіси за тиждень

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

cursor вже без втручання переписує з одного стеку на іншій цілі проекти

а це ви де ви читали?

«цілі проекти» — це які саме?

От в інших чомусь можуть а у вас ні

ці інші зазвичай 314оли. от і весь секрет, чому вони можуть.

ви вже скільки сервісів написали і без втручання переписали курсором ціли проекти?

www.reddit.com/...​_100_of_new_cowork_wrote

cursor.com/blog/scaling-agents

Мій проект, написаний повністю вайбкодом: github.com/...​anbohdan/memory-mcp-1file

Зараз роблю мобільний додаток + фреймоворк (набір інстуркцій) для субагентної «one button» розробки: ресерч — спеки — субагентна розробка з усіма циклами

перші два лінки — не про вас.
Переказувати ЗМІ і пресрелізи всі можуть.

Про самопіар Cursor — я взагалі такє перестав розглядати.
Ще з новин коли ШІ почав брати топові місця на олімпіадах з математики і програмування.

про ваш проект — складність MCP серверів зазвичай невелика.

А головне — перевірити «написаний повністю вайбкодом» неможливо.

З тих випадків де хоч якось можна було з’ясувати, типова картина така
або проект глюкаве гівно
або там був не вайбкодінг, а мікс spec driven developmnet та assisted AI

А коли людина взагалі не розрізняє типи використання ШІ у розробці — то й розпитувати нема що.

І нагадаю, про що я вас питав:

ви вже скільки сервісів написали

ото ви одненький вже скільки пишите?

переписує з одного стеку на іншій цілі проекти

ви скільки переписали?
ніскільки.

До речі, я дивився якось доповідь, про переписування легасі проекту з маргінальної мови на Kotlin.
Але там — ніякого вайбкодінгу і близько не було.
А дуже круте, фахове використання ШІ і винайдений під нього процес розробки.

P.S.
про 100% коду написано — це взагалі не новина.
зараз в мене чергова фіча до проекту генерується.
І це вже я не перший місяць так працюю.
Коду практично не пишу.

Здається, відповідь на поверхні:
По-перше, купа людей роками вдосконалювала свою майстерність, навчаючись писати код — вивчаючи мови програмування, патерни, кращі практики і т.п. Тепер з кожної праски чутно, шо код нічого не вартий і навичка нічого не варта. Звісно після такого знецінення люди почувають, що значну частину життя змарнували, особливо коли їх тикають носом в те, що «він юніор, а задачі в QA-ready таскає зі швидкістю сініора, зверни увагу». Це важко прийняти.

По-друге, працедавці підливають олію у вогонь AI істерії і готові заміняти досвідчених людей початківцями з Copilot в руках.

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

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

Тепер з кожної праски чутно, шо код нічого не вартий і навичка нічого не варта.

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

Раніше, на підписці Claude Code закінчувалися токени деся за чотири години. То було ідеально: ти входив у поток, а потім без нього перформиш x3, бо в потоці та не відполікаєшся на пояснювання очевидного. А потім коли воня отямлювалася: диви що я зробив!

Ні в якому випадку не повчаю, проте ділюся власним досвідом.

Хоч я маю доволі малий досвід праці з LLM загалом, але я знайшов ідеальний для себе воркфлоу. Якщо проєкт більше 100 рядків, то я сідаю і змушую Claude зганерувати повний сет технічної документації — детальний опис фіч, спеки, гайди і т.п. Інколи навіть план реалізації накидуємо. Хитрість, якою користуюсь, це заборонити робити будь-які артефакти без прямого наказу, та ставити уточнюючі питання; потим драфт, вичитка і виправлення секція-за-секцією, та зрештою апрув на створення артефактів. А от ці артефакти вже згодовуються Claude Code.
Відвертого шлаку на порядок менше (хоча все ще достатньо), але нормально для того, щоб зібрати якийсь притомний ПР; потім рев’ю, правки і так по колу.

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

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

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

Колись дійде, але зараз ще не на тому рівні.
Але коли він дійде ваші програми вже нікому не будуть потрібні. Бо кожег сам собі буде робити свої програми і додатки.

Але коли він дійде ваші програми вже нікому не будуть потрібні. Бо кожег сам собі буде робити свої програми і додатки.

Цікавий тейк. От я зараз вмію програмувати, і навіть був у нещодавному минулому профейсійним програмістом та архітектом. І я маю купу пет-проєктів, які нікому окрім мене не потрібні. А послугами умовного DOU користуються тисячі людей.

Ви ж не бажаєте назвати клепання самопальних скриптів професійною розробкою?

Скоріше попросить LLM зробити те, що має зробити програма

Цікаво, автор зможе викласти свій рахунок за курсор і скільки токенів було витрачено ?

Користую Google Antigravity а не курсор, єдиний рахунок — підписка на Gemini, та користується уся сім’я ;)

А чому автор не покаже нам навайбкоджений репозиторій?

Не очікував що це зайде аж так далеко. Краще покажу продукт у стадії «раннього доступу», і признаюсь що навайбкоджений ну майже на 90%. Готовий отримати гору хейту і відповідальність понесу але раз заварив то й на горіхи отримувати мені :)

Продукт — дуже гейміфіковане вивчення англійської мови: Fading Lexicon, тут на форумі є декілька тем від самої ідеї до теперішнього стану. Середовище — Unity з серверною чатсиною як бекенд. Уже доступний на iOS/Android.

Буквально з останнього по Google Antigravity — аналіз безпеки та відповідності вимогам гугл плеймаркету.
Я лиш шкодую що на старті не достатньо користувався.

ось так всі вайбкодери і зливаються)))

статтю написати це не мішки тягати;)
репозиторій можна оцінити по декільком параметрам і в моєму випадку 100 відсотків вайбкодерів виявились пи*даболами (нічого особистого).
За пів року вайбкождингу не з’явилось жодного «нормального» продукту
Надалі готовий дискутувати тільки якщо надаєте репозиторій, це буде вже щось предметне

Вам шашечки чи їхати?
Бізнесу потрібен продукт а не репа, (особливо в паблік). А продукт можете вже спробувати своїми руками на своїму телефоні. Спробуйте: Fading Lexicon ;)

Ось прямо над вашим коментом, прочитайте будь ласка.
Але продублюю бо загубиться в подальших тредах:

Вам шашечки чи їхати?
Бізнесу потрібен продукт а не репа, (особливо в паблік). А продукт можете вже спробувати своїми руками на своїму телефоні. Спробуйте: Fading Lexicon ;)

Ясно, посилання не буде, звісно повіримо вам на слово )

Посилання на репу — звичайно не буде, не бачу сенсу.

Головне завдання розробника (і цілого відділу) — доставка працюючого «продукту» згідно з ТЗ. Бізнесу глибоко фіолетово, скільки літрів кави ви випили й чи набивали ви кожну дужку своїми «золотими ручками». Їм треба результат. Швидко. Якісно.

Тому ділюсь продуктом:
play.google.com/...​ails?id=com.fadinglexicon
або
apps.apple.com/...​lexicon/id6755912344?l=uk

Влучно! Але боюсь маю контраргумент від нього ж. Особливо останнє ;)
github.com/...​414297b558cb46ddd3ce9d6b5

Merge branch ’antigravity’
This is Google Antigravity fixing up my visualization tool (which was
also generated with help from google, but of the normal kind).

It mostly went smoothly, although I had to figure out what the problem
with using the builtin rectangle select was. After telling antigravity
to just do a custom RectangleSelector, things went much better.

Is this much better than I could do by hand? Sure is.

От як би ви також код показали як Лінус, то була б друга розмова ))

Якщо вас один файл задовільнить, то будь ласка показую як є
: www.dropbox.com/...​dpesi58l&st=vghychja&dl=0

Генерує граф-мапу для проходження схожий на Slay the Spire.

Дякую, десь такий код я і очікував побачити -)

Та чисто пройшовся очима і знайшов пару багів та фігні, використання хардкорних магічних змінних, по типу:

node.IconName = «manual_chest»;

Чи змінні які ніде не використовуються

List iconNames = _iconCache.Keys.ToList();

Чи мертві умови які не куди не ведуть

if (layerIdx == 0)
{
// Do nothing, leaves IconName null -> Prefab default
}

наскільки цей код сейфовий і чи не можемо ми вийти за індекс?

int centerIndex = GetSmartTargetIndex(originNode, NodesPerLayer[originNode.LayerIndex], candidateLayer.Count);

Чи тут у вас є рандом
float roll = Random.value;

Воно ж може нарандомити 0 і що тоді ваша умова зробить?

cumulative += reward.Chance;
if (roll <= cumulative)

Та і взагалі ваш цикл майже завжди пропускає останню ітерацію коли буде більше 1

Наскільки безпечний цей код в принципі?
ось ваш сінглтон

private void Awake() {
Instance = this;
...
}

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

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

Але дякую що вказали проблеми АІ, все краще й краще!

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

в значительной степени уже умеют, особенно, если направить в нужном направлении. для работы с кодом нужно пользоваться современными средствами, Cursor, например. я 1,5 года просидел на Курсоре, но недавно перешел на Claude Code — это game changer для меня оказался.

Ой, я щось подібне писав у 15 років на BASIC на Yamaha MSX...

З усією повагою до Лінуса, але якщо

Is this much better than I could do by hand? Sure is

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

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

тобто усі ми президенти, усі керівники над ллмками, де будемо брати нових інженерів у професію, от що цікаво

проблема в том, что средний разраб вообще не отдупляет, сколько подготовительных работ по проектированию проводят другие люди, прежде чем у него в джире появится таска для кодирования. поэтому когда ему в руки попадает голый инструмент, то он начинает в нем скобочки расставлять и названия переменных менять, потому у него получается примерно нихрена.
а у тех, кто годами занимался тем, чтобы собирать контекст, декомпозировать и структурировать так, чтобы средний разраб сумел закодировать, внезапно получается регулярно и неплохо.

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

* Скіки було тут хейту барменів/таксистів що намагались «вайті вайті» пройшовши курси академії шах. А тепер виходить навіть курсів проходити не треба )))
* Дуже багато якогось токсичного балшит маркетингу. «клода за годину зробила те що комманда гугль (!) інженерів зв рік не змогла» — оце все.
* Постійне оце «якщо ти не вайбкодиш, то через місяць залишишся без роботи».
* Ну і загалом всі ці інструменти, моделі, агенти, іде ітд — якийсь суцільний «early access» якесь глючне, немтабільне г-но, як той фаллаут76 на старті, щотижня змінюється, патчується, ітд.

порог входа в профессию теперь повысится только

эйфория только у безруких. и у тех, кто не хочет учиться, а хочет сразу на все готовое.
так почитать — у них у всех есть доступ к каким-то волшебным инструментам, которые никто в глаза не видел.
потому что те, что видел я, не могут сделать корректно самые тривиальные вещи.
у меня вот прямо сейчас в соседнем окне Cursor не может правильно переименовать аргменты в функциях по указанной схеме.
пишет тебе «я сделяль». ты ему «блин, а ну-ка перепроверь вот этот файл».
«The changes look correct. One issue: p1 and p2 are used, but the requirement was to avoid p1, p2, p3. Checking for alternatives...»

Бо для перейменування краще використовувати нативні інструменти IDE і hot-key.

🤣 а для бізнес логіки — краще використовувати код?

лучше быть богатым и здоровым.
а когда тебе надо перейти для всего проекта на схему, которую тебе автоматом не сделает IDE, то почему бы не попробовать использовать для этого супер-пупер умный AI?

...который переменную по заданной схеме переименовать не может.

І якщо треба переіменувати 1000 аргументів, вона зробить одним кліком? Чи треба кожен ручками?

Є таке чудове оповідання Роберта Шеклі — «Ask a Foolish Question», і воно ставить всі крапки над «і». Справа в тім, що професія розробника зазвичай називається «інженер», але переважна більшість представників цієї професії — є техніками, а не інженерами. Тобто вони знаються на інструментах і правилах їх використання, а не на сутності того, що вони роблять. Тому ШІ для них — загроза, бо може їх замінити, і невідворотно це зробить. Це не означає що бути техніком просто, а для того, щоб стати кваліфікованим техніком, не треба мати здібності та прикладати зусилля. Просто ШІ зробить ту саму роботу ефективніше. Але це аж ніяк не знімає потребу у Інженері. Принаймні у осяжній прогнозованій перспективі. І так — інженер повинен мати кваліфікацію техніка, просто з ШІ не матиме потреби виконувати технічну роботу.

Роберт Шеклі — біг плус

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

---

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

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

ШІ для них — загроза, бо може їх замінити, і невідворотно це зробить

не станеться, принаймні в якійсь найближчій перспективі. Якщо кодер має вміння хоч трохи ліпші ніж потрапляти ложкою до рота з першого разу та не облизує стіни — така людина вже може писати промпти до ШІ агента. А хтось же має писати промпти? Я от ще жодної LLMки з власною волею не зустрічав (на щастя, або на жаль — я ще не визначився).

Про всяк випадок, якщо буде тейк про FAANG замінив 100500 девів на роботів, я скажу: «Так у FAANG операційний бюджет n-ярдів на рік. Вони можуть дозволити собі якісні та спеціалізовані моделі нейронок. А закриття проєктів, перетасовка кадрів та інші оптимізації витрат були домокловим мечем над головами девів задовго до усіх цих GPT.»

Середньої руки проєкт (якщо це не «Hello world!») просто не зможе дозволити собі нормальне використання LLM без контролю зі сторони шкіряних. Для того, щоб LLM правильно і бажано з першого разу усе зробила дуже бажано мати повну (ні, не так — ПОВНУ) документацію: з усіма спеками, гайдлайнами, описаними дефектами та рештою артефактів. І усе це бажано мати прямо у репозиторії, щоб агент міг туди достукатись. За свої 15+ років у професії я зустрів рівно 0 (нуль) таких проєктів. В усіх інших випадках середньої руки нейронка навіть преміум сегмента буде не набагато ефективніша за звичайного кодерка. Так, вона генерує лайнокод набагато швидше за мене, але що з того?

На своєму досвіді можу сказати тільки те, що нейронки показують гарний результат, коли просиш їх про точкові зміни. Я зазвичай швидше напишу код, ніж промпт з описом усіх едж-кейсів. А от нагенерувати щось схоже на правду — це прямо сильна сторона нейронок, тому майже уся документація та синтетичні дані для тестів (а іноді і самі тести) у моїх проєктах давно пише GPT.

---

Кому цікаво, уся суть «Ask a Foolish Question» — «Щоб поставити запитання, треба знати більшу частину відповіді.»

В 90-ті тисяч рядків ніхто не вбивав, тодішні вайбкодери писали на фокспро та Делфі, візуально і без усяких кодерських заморочок.

Я навайбокдив цілі проекти, на мовах які ніколи не знав і працюють вони чудово. Різні c++ бібліотеки для деяких пристроїв, Mac OS утиліти. Якщо ти нормальний інженер то маєш мислити структурно та послідовно для того щоб диктувати логіку системі яка виконує брудну роботу — пише код. Той кому подобається писати сам код — мої співчуття. Коли в мене в голові рішення вже повністю готове і цілісне — то далі писати код для цього це суцільне страждання, бо ти вже кайфанув від ідеї. Я розумію що є люди які кожен день пишуть елементарний фронтенд і їм це типу по кайфу шей код люблять писати, не буду глибоко копати не про них мова

а не дай Бог бы тебе понадобился кардиостимулятор и был бы выбор взять отот мерзкий, что руками тобой обсочувствованные программисты писали или навайбкоженый на языке который ловкий автор не знал. то ты бы какой выбрал? а все свои финансы бы доверил банку, который все свое ПО за ночь сгенерил без участия программистов?

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

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

я тут уже ниже писал что выиграли те кто не умел писать код или не любил, ты явно выиграл

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

генерация тестов существала до ии. а плотность измеряема покрывать надо на 100% в любом раскладе

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

та откуда вы взялись все, никто и мегабайт за месяц не набирал кода никогда

І так, я б вибрав кардіостимулятор, написаний разом з потужною llm.

ты умер scontent.fopo5-1.fna.fbcdn.net/...​v9uV9JyDnZlSQ&oe=6969FA23

Щось мені підказує, що якщо "

Іноді нєйронка знаходить такі каверзні баги

"
, то це або рідкісний та малоймовірний edge case, який зазвичай помічається дуже низьким пріоритетом, або є питання до кваліфікації людини, для якої пріоритетний edge case виявився настільки неосяжним.

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

З цим можна працювати, якщо ставитися свідомо та не вважати «ШІ» чарівною кнопкою.

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

Так вайбкодинг це не про «напиши алгоритм кардіо стимулятора»

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

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

Я завжди щось не знаю, бо мої проєкти часто мають 4-5 мов програмування. Але мови програмування це дрібниця, складність більше в тому що кожен раз ти робиш щось концептуально нове. І це на рівні ідеї. Реалізація сама банальна річ, на чому б вона не була написана це просто хороший чи поганий вибір. Тому для мене такі інструменти це серйозна допомога, в першу чергу швидка перевірка концепції, але з мого досвіду створена концепція майже ніколи не переписувалась. Думаю колись буде, але з суто технічних причин.

Я завжди щось не знаю, бо мої проєкти часто мають 4-5 мов програмування.

Питання не в кількості. Якщо це C++, Java, Python та інший мейнстрим, то воно все однакове.

складність більше в тому що кожен раз ти робиш щось концептуально нове

Ніби-то не розробник це писав. Як на мене складність більше в реалізації. А у ширвжитку, як на мене, концепція одна — мова програмування Сі. Усе інше лише різні способи синтаксичного цукру, менеджменту пам’яті та обгорток навколо одних і тих самих принципів імперативного програмування.

Справді інша концепція це якийсь Haskell або навіть Agda чи VST. Але де це знайдеш в мейнстрімі?

Ну я думаю будь хто зі спільноти цієї розуміє різницю між алгоритмом, методом та проблемою. Більшість завдань в IT вирішуються алгоритмічно, лише окремі завдання потребують застосування методів (не плутати з алгоритмом на пайтоні який складається з купи готових методів), лише дуже невеликий відсоток потребує створення нових методів, і одиниці вирішують якусь проблему. Тому так реалізація більшості речей — це просто, для когось хто раніше цього не робив можливо складно. От побудова наприклад pbx для кол центру з 1000 агентів — це складно? Та ні скажу я, хтось погодиться, хтось ні. Хтось скаже Гугл аналітику на сайт додати не просто було, ну то шо всюди складність реалізації тепер? Цікаві задачі це рідкість, але в багатьох можна знайти щось, що принесе задоволення в процесі реалізації і зробить так чи інакше для розробника цю задачу цікавою. Це я вважаю показник спеціаліста досить високого рівня

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

Так вайбкодинг це не про «напиши алгоритм кардіо стимулятора» це делегація написання коду ШІ покроково. ШІ не приймає за тебе рішення по функціоналу він просто крок за кроком реалізує твій задум.

так можно только усложнить себе жизнь и пожертвовать качеством одновременно

А будь-яке медичного обладнання проходить ряд складних етапів тестувань

это может поменяться

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

а это меняется прямо сейчас, заказчику на качество плевать пока не появятся проблемы, галере на качество плевать всегда, только гребец хочет качества. а ии как раз убирает такого гребца. нужно не так много времени чтобы глобальное падение качества стало заметным

В цілому якість софту вже дно пробито, куди гірше, куди повільніше вже той apple music чи їхній старий itunes for subscriptions який передається ще походу з першого айфону я не знаю. Все і так на дні. Я коли аналізую те шо я написав під macOS, tvOS, watchOS причому я взагалі його вайбкодив, я просто не розумію як можна було створити на swift таке гавно яке деякі роблять.

Про галєри мовчу, там пофігу не тільки на все, а на саму суть існування свідомості

и поэтому ты считаешь что можно пробить и второе дно? но за ним уже центр Земли, дальше уже будет некуда

выбрал бы те, которые проходят аудит или сертификацию.
типа на будет такого, что стимулятор отказывает и человек такой: «фух, ну это не нейронка — это гребец завтыкал — ему простительно» или «ну, деньги украли, но ничего — ребята вон писали, старались!»

какая-то абсолютно странная метрика надежности кода — смотреть кем он был написан

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

если оба прошли — супер
если все куплено, то мне без разницы покупался аудит для вайб решения или не вайб решения — пользоваться им одинаково рисковано

вроде ж простые вещи говорю:
мне (как и любому пользователю) абсолютно все равно кто виноват в ошибке — человек или ии галлюцинация
риски ошибок — это не какой-то абсолютно новый концепт который появился вместе с ии
управление этими рисками и контроль качества всегда были частью процесса

в чем конкретно к ии претензия-то?

к ии претензии нет, претензия к оператору ии, его качество начало стремительно падать

так риск на уровне оператора был всегда: что на уровне оператора пк что на уровне оператора ии
все время индустрия принимала этот риск как данность и адаптировалась — выстраивала соответствующие процессы контроля качества и минимизации ущерба от рисков. коммерческое программирование — оно же буквально об этом: сама реализация не всегда даже самая сложная часть.

в этом плане же абсолютно ничего не поменялось с появлением ии.
но тут появляются ретрограды, которые пытаются обеспечить качество с помощью органик кода(забывая про тех же джунов которые как-то контрибьютят) откатывая индрустрию на годы назад. максимальный абсурд

Та це внук тих хто калькуляторам протести влаштовував, забий

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

Team Lead в MijnDev

MijnDev is a software development company founded in 2014 in Vinnytsia.

Developing and supporting web and mobile applications

ліл

Хочеш поміряємось знаннями на лайв стрімі?) я тобі покажу свої проекти, а ти мені покажеш свої. Подивимось шо ти за ліл такий

и чего ты выделываешься? он, объективно, на несколько порядков опережает тебя как программист

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

Є реальні проекти на яких я вайбкодю є на яких ні.

пользование ии никак тебя не характеризует, дело вообще не в этом

Я сказав мудаку давай він покаже свої проекти, я свої. Продемонструє як він круто пише код, по лайвкодимо на стрімі. Шо не так?

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

Судячи по тобі ти навіть українську мову не вивчив за все життя:) не те шо мову програмування хоч якусь.

мне не понравится что какой-то рагуль сможет потом на текст на украинском сказать что это накудахтано

не те шо мову програмування хоч якусь.

но на 1С же могу? там же все понятно — на русском

А шо в нього там таке круте в лінкедіні і де ти найшов його профіль?)))

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

Людину характеризують проєкти які вона реалізувала, скільки вона на них заробила, в мене є шо показати, і міл тек, мл, веб. Я код пишу з пятого класу школи. Тому так я впевнений в своїх знаннях.

А шо в нього там таке круте в лінкедіні і де ти найшов його профіль?)))

с этого все и началось, он тебе подсветил что у тебя не так, промотай вверх

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

ну смотри, в Киеве и Харькове даже сегодня через боль можно найти зп 10к+, в Виннице — нет. с деньгами разобрались. с проектами сложнее... много писать... не буду

Тому так я впевнений в своїх знаннях.

так я ж и написал про увереноость, я даже могу поверить что ты реально на 2 головы выше рядового синьора с Винницы. оно просто легко соревноваться когда соревноваться не с кем

У Вінниці ЗП в середньому вище ніж в Харкові. Зайди на доу вибери Software Engineer і поклацай Вінниця/Харків. Це по перше. По друге ніхто не зобовязаний мати одне джерело надходжень, одні проєкти ти контрактуєш закордоном інші виконуєш тут локально, деякі тобі приносять якісь додаткові кошти і ти над ними майже не працюєш. 10к$+ я вважаю взагалі немає сенсу рвати жопу шукати в Україні баригу, який сенс? 3 група фоп, контрактор в штатах, це нижній квартиль (це типу любий впевнений фронтенд який знайшов там роботу). Деякі позиції дозволяють працювати по 2 години в день, при середніх ринках, з іншим часом роби шо хочеш, хочеш працюй наповну, хочеш контрактуйся десь ще.

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

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

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

* Розробіть специфікацію того що і як програма має робити повністю, до того як писати\генерувати будьякий код. Ніяких «шось спершу напишемо, а потім розберомось».
* Після того як спека зроблена, розробіть технічний дизайн. Повністю. Де які фреімворки використовуються, де які класи що мають робити.
* Потім тест-план, як перевірити чи всі необхідні функції програми працюють, де можна обійтись юніт тестами, а де треба вручну перевірити. Розпишіть всі такі тест-кейси.
* Після того розробіть план імплементації — розбийте на задачі, підзадачі, де чітко вказано де які класи мають бути заімплементовані ітд.
* Як все реді віддавайте задачі джуну. По одній за раз. Робіть порядковий код рев’ю із тиканням джуна мордочкою де він якусь фігню зробив.
* Після завершення можна віддати тестерам на тестування.
* Profit

Тут може з’ясуватись що «джуна» можна ШІ замінити (замінюй мене повністю), да і для тестування можна залучити, да і до написання всіх ций специфікацій\планів.

Але реальність, що старий добрий ватерфолл з ші працює значно краще за еджайл.

Доки задачі типові. Якщо задачі нетипові, то він не може зробити жодного кроку.

любая нетиповая задача декомпозируется в последовательность типовых. skill issue.

Розробити алгоритм за допомогою якого доводиться що «люба нетипова задача декомпозується в послідовність типових»)

редукционизм да, заманчив.
только он плохо работает даже в таких точных и хорошо обмаметемаченых областях как физика.

Після того як її розвʼязали, напевно. Але в процесі ти пробуєш різні варіанти, отримуєш результати, корегуєш напрямок пошуку...

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

Ну задача сіеьйора тепер і є про подумати і записати всі важливі технічні деталі заздалегіть.

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

Якщо на якомусь проекті немає вимог по якості і головне аби працювало. Якщо не потрібно конкурувати і ціна помилки це просто написання декількох звітів. Тоді можна говорити про ШІ

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

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

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

Якщо на якомусь проекті немає вимог по якості і головне аби працювало. Якщо не потрібно конкурувати і ціна помилки це просто написання декількох звітів. Тоді можна говорити про ШІ

Ви взагалі читали мій оригинальний коммент ? Якщо робити прискіпливе планування, і потім контрольоване повне код-рев’ю то якість буде, ви її як сеньйор гарантуєте.

от згадування про 10% потрібно додавати до усіх розповідей про ШІ. Кому потрібно більш якісно, тоді ШІ не вирішить задачу

Потрібно починати статті з речення: я працюю на проекті де 90% коду можна згенерувати. І тоді уже ніхто не буде критикувати

На рахунок оптимізації повністю згоден. На сьогоднішній день ШІ просто не здатен виконати навіть елементарну оптимізацію. Можливо якусь прям найпростішу так. Я думаю ця проблема з нами надовго

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

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

Чи це має зробити за людину «ШІ»? Питань тут багато, адже це поле гіпотез та часто навіть — фантазій.
У будь-якому разі констатуємо цікавий нюанс. Ми дійшли (я вважаю, еволюційно) до Agile, щоб уникнути недоліків водоспаду на тлі нових технологій та їх доступності масовому споживачу. А зараз, виходить, хочемо повернутися назад. Проте зауважу, що нові підходи до розробки давали нам не тільки швидкість, але й гнучкість у зміні вимог та у відповідних змінах у софті, чого не дає водостадо-подібні моделі.

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

Ми точно хочемо повернутися назад та знехтувати гнучкістю? Якою буде ціна постійного перероблення першої фази (там де, описуються детальні вимоги на різних рівнях)?

Не варто забувати історію розвитку розробки, щоб не втрапити у старі пастки.

П.С. Втім, навіть зараз водоспадні моделі працюють там, де мають. Але це вже зовсім інша історія.

agile и водопад будут прекрасно работать вместе, только на разных уровнях абстракции. agile был придуман, чтобы быстро реагировать на изменение бизнес-требований, итеративно создавать продукт, с быстрой петлей обратной связи.

внутри же итерации каждая фича должна быть подробно спроектирована, зафиксирована в спецификации и отдана на кодирование. это и есть водопад и он будет продолжать прекрасно работать. просто спецификация будет создаваться инженером с участием AI ассистента, в удобном для AI coding агента формате, который потом ее и закодирует. двухнедельный спринт реально уложить в 2 дня. это именно то, что нужно бизнесу — быстрый результат, быстрая проверка гипотез, быстрый пивот.

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

agile и водопад будут прекрасно работать вместе

Не, водопад это про неизменность требований. Ты не можешь спроектировать Бурж Халиф, согласовать ресурсы, сроки, подрядчиков и потом на середине строительства решить, а давайте сделаем через 3 этажа сбоку infinite poll и вертолётную площадку, что уже потребует перепроектирование фундамента, учёта парусности. В софте, конечно, всё проще менять в моменте, но это принципиальная разница между fixed price и time & material подходами.

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

а затем ты фичу демонстрируешь и в итоге требования меняются и на новый спринт уходят новые фичи. это и есть эджайл.

fixed price и time & material подходами.

это модели контрактования, они не имеют отношения к sdlc

Так в этом и противоречие — в водопаде ничего не меняется. По-этому его и не используют уже в разработке, он не учитывает обратную связь и изменение требований в процессе, иначе это уже не водопад.

методы небольших компаний и тем более индивидуалов не масштабируются на целые компании — по определению.

двухнедельный спринт реально уложить в 2 дня.

это уже почти год утверждают вайбкодеры.
но показать на деле — не могут.

а потихоньку статистика копится.
и она — в лучших случаях повышение продуктивности программистов 20-30%.

этот год, считаю, станет наконец годом испытания идеи «10 дней уложим в 2 дня», и прочих о x10 программисте.

а то как Карпаты ввел термин вайбкодиг — то с каждого утюга говорят о таком радикальном ускорении — разработки.
часть которой это программирование.
а часть программирования — кодинг.

то, что нужно бизнесу — быстрый результат, быстрая проверка гипотез, быстрый пивот.

я спеки писал и раньше.
и сейчас пишу. для ИИ. ничего быстрого в этом нет.
а в водопаде, хоть ты его spec driven development назови — тоже.

методы небольших компаний и тем более индивидуалов не масштабируются на целые компании

масштабируются, потому что это прежде всего индивидуальные методы работы. условно, это как один шахтер в забое кайлом орудует, а другой — пневматическим отбойным молотком. вроде бы оба заняты одним делом, а выхлоп отличается в разы. вот задача компаний: научить команды пользоваться отбойными молотками.

это уже почти год утверждают вайбкодеры.
но показать на деле — не могут.

уже все давно показали и доказали. кто хочет — видит и берет на вооружение. кто не хочет — как та обезьянка закрывает себе глаза и повторяет: «LLM — это случайный набор символов! AI не умеет писать код, как пишет его человек — он расставляет скобочки и табуляции без души!»

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

этот год, считаю, станет наконец годом испытания идеи «10 дней уложим в 2 дня», и прочих о x10 программисте.

в конце этого года для разработчика умение в AI assisted coding станет требованием наподобие знания английского — если ты не умеешь/не хочешь, то тебе не светит ничего больше мелкой шараги, которая не может себе позволить подписку на Cursor/Claude Code. запомните этот твит :)

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

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

Все, що ви написали више не спрацює

это УЖЕ работает. в моем нетворке я лично знаю многих людей и их становится все больше и больше тех, кто кратно увеличил производительность. на Западе продуктовые компании активно поощряют использование AI тулов в непосредственной ежедневной работе инженеров, я не понимаю просто, как этого можно не видеть, игнорировать и не осваивать в собственной работе.

может быть просто инженеру нужно меньше рассуждать

про стратегічне планування

, а больше думать про свою непосредственную работу?

это УЖЕ работает

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

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

может быть просто инженеру нужно меньше рассуждать
про стратегічне планування

, а больше думать про свою непосредственную работу?

Не кажіть що мені робити, і я не скажу куди вам ідти.

в моем нетворке я лично знаю многих людей

я уже больше полугода подписан на несколько каналов вайбкодеров.

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

исключения конечно есть — это вайбкодеры с бекграундом в ML, которые правда и не вайбкодят, а применяют ИИ в реальных проектах заказчиков.

кто кратно увеличил производительность. на Западе продуктовые компании

назовите эти компании, и дайте линки на их пресрелизы про — кратно.

не вы один такой грамотный следить «за новостями с Запада».
Я не встречал пока ни одной новости про кратно.

я уже больше полугода подписан на несколько каналов вайбкодеров.

это многое объясняет

назовите эти компании, и дайте линки на их пресрелизы про — кратно.

перечитайте еще раз написанное мною выше, вчитываясь в каждое слов. буквально, я написал что знаю многих людей, чья производительность с внедрением в использование agentic workflows выросла кратно, и что компании активно поощряют использование AI тулов в ежедневной работе.

с какого перепугу вы от меня требуете какие-то пресс-релизы и тд? что за примитивные манипуляции?

я могу дать подтверждение своих слов, вот совсем свежее письмо от фаундера Sentry — 3-миллиардного бизнеса
fxtwitter.com/...​/2009372836419248263?s=20

он там английским по белому пишет в первых же строках: «2026 is the year that we are asking everyone to get comfortable with using LLMs in their daily workflows»

EVERYONE

DAILY WORKFLOWS

не вы один такой грамотный следить «за новостями с Запада».

то, что следите — хорошо, конечно, только у вас в итоге получается «смотрю в книгу — вижу фигу».

skill issue.

с какого перепугу вы от меня требуете какие-то пресс-релизы и тд?

потому что вы балаболите слово в слово тоже самое что на каналах вайбкодеров.

от фаундера Sentry

о том что сео рассказывают — смеются еще с прошлого года.

и

3-миллиардного бизнеса

к поднятому вопросу отношения не имеет.
прибыльность бизнеса почти никогда не связана с характеристиками разработки.

только у вас в итоге получается «смотрю в книгу — вижу фигу».

я использую ИИ в разработке с 23 года.

и поэтому мне очень понятно о чем балаболят си лэвэл и вайбкодеры.

я использую ИИ в разработке с 23 года.

тебе это не очень помогло. судя по по твоему гитхабу — проблема в прокладке между стулом и клавиатурой.

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

масштабируются

не масштабируются.
можно начать с работы Коуза «Природа фирмы»

условно, это как один шахтер в забое кайлом

Хлопские аналогии не могут быть аргументами.

уже все давно показали и доказали.

Факты в студию.
Покажите их продукты, или команды. компании, которые успешно берут и выполняют заказы.
Треп на стримах вайбкодеров я и сам посматриваю. Бывает полезная техническая инфа.

я вижу что это работает у других

Что вы видите?
Расскажите, что вы увидели «работающего у других»?

я пишу тут текст, кто сможет — тот услышит.

Это обычная демагогия и манипуляция.
Годится для религиозного учителя, потому что мистические познания не передаются словами.
Но вы ж не мистик, верно?

в конце этого года для разработчика умение в AI assisted coding

а-а-а, то есть вы не знаете радикальной разницы между вайбкодингом и AI assisted, но пишите малограмтные мистические тексты, которые «кто сможет тот услышит» :D

Хлопские аналогии не могут быть аргументами.

Я переймаюсь, що вас не зрозуміють. Я спробую пояснити інакше.

Якщо треба приклад з молотками — я маю такий. Колись я працював на будівництві після пар в універі (мабуть, нікого таким не здивуєш), і одного дня нам запропонували, замість простого столярного молотка використовувати автоматичний. Адже одну дошку можна приколити в 10-ро швидше. Наче все вірно.
Чому ми масово відмовились від цього нововведення після першого ж дня?
Бо виявилось, що потрібно приколити не одну, а сотню дошок. І таскати з собою молоток, який важить 300гр. і без проблем вішається на пояс легше, аніж кілограмову дуру та аккумулятори до неї.

Простими словами: швидко приколити дошку (реалізувати фічу), а дорівнює швидко зібрати сходи (зарелізити проєкт).

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

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

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

ты ошибаешься.

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

если ты не пробовал применить Agentic workflows в своей работе, а судишь по тому, что Рабинович напел по телефону — попробуй сам.

если пробовал, но не получилось — вопрос твоей квалификации.

не только я, здесь и в соседних топиках реальные практики писали — чем выше квалификация, тем больше буст от использования инструментов ты способен получить.

Реальні практики тут, і в сусідніх топіках також писали звортне.

З того, що я вже прочитав — я не побачив робочих підходів, що були б мені корисні. Я вже десь казав, але повторю тут: unit тести, синтетичні дані для тестів та документацію в моїх особистих проєктах вже давно пише LLM. Але усе це надає ~х0.5, що беззаперечно також дуже файно, але аж ніяк не х10, і навіть не х2. Єдине місце де я дійсно отримав х10 (а може навіть х100) — це написання коміт меседжів та дескріпшенів до ПРів, але... я б не сказав, що це колись було проблемою.

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

Простими словами: якщо своїми руками я реалізую фічу і відправлю її на рев’ю за годину; то з нейронкою я буду півгодини писати спеку, потім півгодини робити ревью, а потім півгодини вносити правки (бо я жодного разу ще не бачив, щоб мені LLM видала нормальний код з першого трая, якщо це не «hello world»).

практики постоянно меняются, улучшаются...

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

попробуй сам

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

Що стосується комерційних проєктів — дивиться вище.

если пробовал, но не получилось — вопрос твоей квалификации.

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

чем выше квалификация, тем больше буст от использования инструментов ты способен получить.

Про це окремо. От візьмемо для прикладу мене (а я вважаю себе середньої руки девом) де мене може прискорити LLM?
Набрати за мене функцію? Я швидко друкую, а з урахуванням того, що я буду писати код одразу як мені подобається, то можливо навіть швидше нейронки. Якщо ж я буду у всіх побробицях розписувати нейронці, що саме мені потрібно — то я взазагалі швидше сам зроблю усе, що треба.
Допомогти з новою технологією? Не бачу різниці між тим, щоб читати офіційну документацію, та її версію від нейронки. Окрім того, звісно, що офіційна дока гарантовано вірна.
Напише інтеграційні тести? Claude Code ледь-ледь тримає контекст окремої фічі з правилами, щоб не навернути суміжні. І то його доводиться раз-через-раз корегувати на «істиний шлях».
Перевірить усі edge cases? Так, це може. Але чомусь кожне повідомлення починається з фрази «дійсно, як гарно що ти це помітив» у різних варіаціях.
Зробить оптимізацію? Ох... Мені здається, що навіть найупертіші погодились, що оптимізація — не дуже сильна сторона AI.
Збере бібліотеку з існуючої кодової бази? Можливо. Але я б не сказав, що це колись займало багато часу.

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

PS: на цьому, пропоную завершити. Я все сказав.

Про це окремо. От візьмемо для прикладу мене (а я вважаю себе середньої руки девом) де мене може прискорити LLM?

а ты концепцию просто неправильно понял. это нормально, ее же маркетологи придумали. им же продавать надо пока покупают, а не технические детали рассказывать. ты ее рассматриваешь как: твоя производительность = X, а твоя производительность * llm = 10X. и выходит что тебя ускорили в 10 раз и не понятно вообще где эти 10X. так вот этого в концепте нет, это ты сам себе как и многие додумал, поэтому такой и хайп. «чем опытнее разработчик тем больше буст он получит» — это абсолютно верно. если нарисовать график где одна ось это скил разработчика, а вторая это время, то мы получим экспоненциальный спад. обусловлено это тем что чем больше скил, тем проще описать задачу и провалидировать.

а чтобы продать ускорение берем простой пример, нужно сделать приложение, которое интегрировано с платежными системами (5 штук), авторизация через сторонние сервисы (5 штук), в настройках номер счета. все приложение это кнопка, которая переводит 1 доллар с твоего счета на счет указанный в настройках. нужно сделать мобильные версии, веб версию и десктоп приложение. и сделать апи. ну и все в клауд, все тестами, все задокументировать, описать воркфлоу с диаграммами, блок-схемами и т.д. так как программирования в этом задаче нет, а в основном чтение, анализ, написание спек и интеграции с всратым апи, то без ии такая работа займет ну по-моему от пары месяцев до полугода в зависимости от конторы. а с ии это напишет почти кто угодно за пару вечеров. ускорение больше 10X

но если брать не маркетинг, а с практической точки зрения, то провели исследования полгода назад. результаты плохие. метр описывает замедление разработки у опытных программистов на 19%. майкрософт показывает ускорение появилось только в рутиных задачах. антропик показывает ускорение, но далеко не на всех задачах

=> вот то что ты выиграл на генерации тестов, данных к ним и документации это и есть обещанное 10X в чистом виде

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

исследований уже больше чем то, и более актуальных.

результат правда в целом такой же — явного буста не наблюдается.
но, это ж не хайповая тема, а вайбкодеры, которые по сути «вайти вайти 2.0» обычно такого не читают. а когда и читают — не поймут, как так: ИИ генерит за 10 минут столько строчек кода, которые программист писал бы полтора часа — и нет буста???

и нубу фик ты объяснишь, что тапание кода даже не программирование еще. не говоря о разработке в целом:
от «Хочу фичу» от заказчика, до — «Спасибо, работает, оплачиваю!
И, знаете, хочу еще вот такую фичу»

а потихоньку статистика копится.
и она — в лучших случаях повышение продуктивности программистов 20-30%.

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

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

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

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

Якщо ЛЛМ на декілька порядків зменшує фазу розробки (кодування-тестування) то має дуже великий сенс витрачати більше часу на фазу підготовки.

Ми точно хочемо повернутися назад та знехтувати гнучкістю? Якою буде ціна постійного перероблення першої фази (там де, описуються детальні вимоги на різних рівнях)?

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

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

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

Якщо ЛЛМ на декілька порядків зменшує фазу розробки (кодування-тестування) то має дуже великий сенс витрачати більше часу на фазу підготовки.

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

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

якщо ви послухаєте оптимістів ШІ — то вже почуєте те ж саме:
«У вас ШІ генерить мачню? Та то тому що ви у спеках, рулах, скілах погано прописали, не те і не так».

Тобто ми вже прийшли до тої ж самої проблеми.

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

Ну я не кажу що ватерфол це значно краща модель ніж аджайл в усіх випадках. Я кажу, що на данному етапі розвитку ШІ засобів, суб’єктивно, ватерфол це саме та модель якає дає можливість на 90-100 % відсодків генерувати код через ШІ забезпечцючт при цьому достойну якість.
Чи зміниться це за рік чи ні — спрогнозувати важко.

Самому цікаво, як воно буде.

з тих аналітичних доповідей що зустрічав
ватерфол для ШІ ще більш марудний чим був. Для, ШІ фактично треба ще й детальний «підручник» робити. Як для довб***ба, якого б і, на трейні не взяли.
Витрати на створення, не кажучи про підтримку у консистетному стані, навіть з «курсором» жахливі.

Тобто зникає сенс його використовувати, бо дешевше — пристойних мідлів донавчити assisted AI.

Бо тюнінг отого ШІ оточення нагадує створення DSL щоб вивести Hello world.
Якесь мистецтво заради мистецтва, але щоб токени палити!

з тих аналітичних доповідей що зустрічав

Зкиньте посилання на аналітичні доповіді.

ватерфол для ШІ ще більш марудний чим був. Для, ШІ фактично треба ще й детальний «підручник» робити. Як для довб***ба, якого б і, на трейні не взяли.

Це все дуже суб’єктивно. Я як людина що викатувала в прод аппу написану на 90% через ШІ із цим твердженням дещо не згоден.

Ой, отак сходу й не пригадаю.
Рекомендую канал AI engineer на ютьюбі, там у доповідях часто посилаються. Як не незалежні, так і власні дослідження, бо доповідачі часто від компаній які продають свої тулзи для, розробників, і збирають статистику.

І я не розумію що такє «написану на 90% ШІ»
Windsurf в мене вже в кінці 24,чи початку 25 показував 84%.

Зараз на Copilot. Чи пишу я код взагалі... Здається нє.

На «%% згенеровано ШІ» я вже давно кажу :
Тю, а я вже до ШІ давно код не пишу. Клавіатура пише!

тому й джуни стали не потрібні.

але й тому ШІ не прискорює радикально розробку, бо на всіх названих кроках він допомогає, але не змінив головного
«Design and programming are human activities; forget that and all is lost.»
Bjarne Stroustrup

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

То що, теперь можна взяти любого бажаючого, посадити за AutoCAD або SolidWorks і намалює те що треба?

що старий добрий ватерфолл з ші працює значно краще за еджайл.

так, він працює значно краще за вайбкодінг (який є продовженням аджайлу) тому що
GenAI занадто «тупий», щоб аджайлити :)

То що, теперь можна взяти любого бажаючого, посадити за AutoCAD або SolidWorks і намалює те що треба?

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

PS: просто для справки.

Так я не розумію взагалі про шо ви. З Ші ви генеруєте код, а не рішення. Яка ціна помилки? Ви функція за функцією диктуєте шо зробити. Я не розумію як можна заплатити велику ціну за код який ви повністю усвідомили і продумали, і він працює. Ви модуль за модулем будуєте проєкт, хочете пишіть вручну тести, не хочете не пишіть. Це якись абсурд весь цей топік:))

ціна помилки тоді коли проект стосується здоровʼя і життя пацієнтів

Найгірше, що люди котрі використовують ШІ не соромляться говорити неправду

повністю усвідомили і продумали

І це при тому, що часто використовують інструменти про котрі знають лише поверхнево.

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

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

Так я працюю напряму з замовниками та їхніми продуктами постійно. За виключенням 1 року де я працював в EPAM, особисто мені там було прямо важко витримати корпоративну етику та необмежену кількість білоруських менеджерів:)
Кажу 5-6 мов, діло не в аутсорсингу, Просто проєкти складні, багато мікро сервісів, на різних мовах. Я не знаю як зараз ефективно створити систему використавши тільки 2 мови. Одну для фронт іншу для бек. Треба писати якісь плагіни які можуть бути на C#, якогось бота на python, шось на desktop. Цим всім займаються як правило різні люди, але коли проєкт новий і цей проєкт може поміститись в одну голову, зараз його може написати навіть людина яка не пише постійно на тій мові яку проєкт потребує. Ми не говоримо зараз про все і не вдаваймось в крайності, але так проєкти вайбокодяться і життя стає краще. Я не знаю всі кажуть про помилки в генерації коду, я користуюсь підпискою за 200 баксів і норм все, кодекс пише без помилок. Навіть складні c++ файли рефакторив і тести воно проходило. Чомусь відчувається сильна недовіра до інструмента. Прям як з тими калькуляторами колись😂😂

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

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

Вайбкодінг дав нам windows 11. І судячи по чуткам тільки зараз Майкрософт починає нормально виправляти код, який вони навайбкодили.

З виходу із бети не ловив жодних глюків

Оце так поворот, Лінус Торвальдс теж вайбкодить з Google Antigravity: github.com/torvalds/AudioNoise

Also note that the python visualizer tool has been basically written by vibe-coding. I know more about analog filters — and that’s not saying much — than I do about python. It started out as my typical “google and do the monkey-see-monkey-do” kind of programming, but then I cut out the middle-man — me — and just used Google Antigravity to do the audio sample visualizer.

тут несколько причин. первая и самая главная это то, что никогда не было проблемы со скоростью писания кода. вторая это внутренее возмущение «я программистом хотел быть, а не нанимался в тестировщики говнокода». третья, у каждого тут свои пропорции, но лично для меня если написание кода занимало условно час, то его проверка занимала 2 минуты, а с ии теперь генерация кода занимает 2 минуты, а час+ уйдет на вымучивание правильного результата

сильно выиграли только те, кто код писать не умел или не любил

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

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

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

Смішно те, що ця стаття теж написана ШІшкою (або як мінімум сильно підредагована нею) але якщо закрити на це очі, то вайбкодинг і використання в роботі ШІ це дві різні речі. Вайбкодинг це буквально все перекласти на ШІшку, і про ніяку якість тут і мови не може йти. Проте якщо 60-70% коду написані ШІ, і 30-40% вручну, це зазвичай норм. Бо зазвичай ШІ як раз бракує тих 30-40% щоб довести код до розуму, а не віддати сиру «каку». І навіть з часом сильно сумніваюсь що це відношення зміниться

Підредагована — так, але лише у плані граматики.
Загалом ми уже зараз у такому періоді розвитку що ШІ пише код кращий за більшість мідлів.

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

Це не так. Якщо мова йде про «напиши мені селект в скл» — дійсно справиться, але якщо мова «зроби сторінку авторизації та весь супутній код авторизації до неї» — не справиться. Та що там казати, я на днях попросив про DOTS розказати, в результаті пару разів переписував,бо в якийсь момент на дурні ловив ші і «ой, я просто почав із простішого коду, так, дійсно, в реальності це пишуть інакше».

І головне — ви забуваєте про вартість. Ші це дуже дорого, значно дорожче людей.

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

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

То ніхто не ігнорує, хоча оцінка навіть тут занадто оптимістична. Он зараз всі unit-тести пишуться нейронками. Окреме питання чи є в цьому вел’ю.

Без бази ви просто не зможете перевірити те, що видав ШІ

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

вже й архітектуру непогано накидує, якщо грамотний промпт скласти

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

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

Вся проблема хейтерів — у відсутності скіла комунікації з нейронкою.

Теж мені скіл, спілкуватися рідною мовою

Вони кидають тупий запит, отримують тупу відповідь

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

А треба вчитися керувати цим потоком.

Це нескладно. Просто треба розуміти, LLM це типові задачі, а як тільки з’являється щось кастомне, якість відразу дропається.

на рев’ю присутній елемент довіри: я цього хлопака знаю

по ідеї код має сам за себе говорити, а покладаючись на необ’єктивні складові (як персоналія автора нп) можна отримати відповідно необ’єктивне ревю/рецензію

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

це цікавіше, надаючи llm людську властивість зрозуміти щось самою, то як сприймати таку персоніфікацію — як якусь форму llm свідомості, чи то просто був такий рольовий вислів з «зрозуміти чому/сама»?

по ідеї код має сам за себе говорити, а покладаючись на необ’єктивні складові (як персоналія автора нп) можна отримати відповідно необ’єктивне ревю/рецензію

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

як якусь форму llm свідомості, чи то просто був такий рольовий вислів з «зрозуміти чому/сама»

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

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

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

Шкода від необ’єктивного рев’ю меньша ніж вартість витраченого часу

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

оцінка дуже важливі для людини, бо ми стадні тварини

а мова була про оцінювання-персоніфікацію LLM, не про оцінювання стадних божих творінь)

Це просто властивості нашого мислення ...

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

Посилання на першопринципи нерелевантне.

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

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

а мова була про оцінювання-персоніфікацію LLM, не про оцінювання стадних божих творінь)
ніяк не може бути підтвердженням що ШІ має якусь форму свідомості

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

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

і це може послужити виправданням можливо необ’єктивному рецензуванню з
«шкода від необ’єктивного рев’ю меньша ніж вартість витраченого часу»? — знову нагадує faulty reasoning

Бла-бла-бла... пустепорожнє. Мова йде виключенно про мене.

чому виключно, role playing з ШІ достатньо обговорювалося, і як сприймати в такому ракурсі персоніфікацію — то не так вже і бла-бла віртуально

і це може послужити виправданням можливо необ’єктивному рецензуванню з
«шкода від необ’єктивного рев’ю меньша ніж вартість витраченого часу»? — знову нагадує faulty reasoning

Абсолютної об’єктивності не існує, ні в код рев’ю, ні в житті взагалі. Коли ви читаєте Daily Telegraph vs Z-воєнкорів, у вас різне ставлення до джерела. Це нормально, бо репутація це ефективний механізм фільтрації, який економить час.

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

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

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

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

оцінка навіть тут занадто оптимістична

Занадто оптимістично сказати «занадто оптимістична», вибачаюсь за тавтологію.
На високу точність не претендую, але я буду просто щасливим, якщо нейронка прискорює мене хоча б вдвічі. За простими розрахунками у мене виходить щось в межах 50 — 60% приросту швидкості код делівері за умови прийнятної якості. Що також дуже гарно, але навіть не близько із заявленими 1000%. Про прискорити розробку «в 10 разів» — це якесь фентезі з єдинорогами.

вже й архітектуру непогано накидує, якщо грамотний промпт скласти

LLM завжди непогано з цим справлялися

Тут я не погоджусь. LLMка дуже гарно вміє тільки одну річ — швидко підбирати таку відповідь, яка з найбільшою вірогідністю сподобається її оператору. Тому тут вирішує тупо текст промптів. Більшість (я принаймні сподіваюсь), звісно, просто мовчки користуються інструментом і адекватно сприймає його сильні/слабкі сторони, та обмеження. Решта ділиться на два лагеря: ті до кого нейронка підібрала правильний підхід за час, поки не вичерпався ліміт терпіння; і ті — до кого не змогла. Перші пропагують «супер-пупер ШІ, який ось-ось усе зробить»; другі — хейтять «вайбкодінг».

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

То і архітектуру підбере, яка сподобається оператору.

Але оскільки більшість моїх реплік це «Ти дура!» «Брєд!», ... то якось з залицяннями погано... Ще раз, нейронка не може рахувати варіанти.

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

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

"

це те що більшість інженерів не можуть в архітектуру

" — може в фронтенді пошукаєш?)))

Інженер який не розумію структуру і чистий код, банально не може використовувати агентів ефективно

— 100%, вище писав про це ж

Навайбкодив «Водяну змію» Слабенька, але й вайбкодив забезкоштовно, просто для себе, для перевірки свого алгоритму трейдингу.

Підписатись на коментарі