Інженерна майстерність і карʼєра / крок 10
Вайб-кодінг — частина 2 (стрим)
Про що це відео
Продовження стриму про вайб-кодинг системи гоночної телеметрії, яке переростає в насичену сесію запитань і відповідей. Спершу автор демонструє ранній proof of concept, який зібрав за пів дня на веб-компонентах Lit від Google: він завантажує CSV із GPS-телеметрією 25 Гц, малює кола на карті й дозволяє порівнювати коло з колом через графік дельти — автор експериментував із відновленням сигналу через лінійну інтерполяцію, сплайни та фільтр Калмана. Далі він вайб-кодить ендпоінти «гаража» (CRUD для автомобілів) у Claude Code за API-документацією, яку Claude згенерував у першій частині, — і чималу частину часу виловлює помилки AI: той продублював типи замість виведення типів через LIVR (автор власноруч пише приклад InferInterface<typeof validationRules>, щоб навчити модель), а ще видав неконсистентні поля status/success, бо сама документація була неконсистентною. Його теза: що краще структурований проєкт, то краще працює AI — після кількох тижнів ітеративного перенесення виправлень у CLAUDE.md кожна нова фіча «просто лягає як треба». Стрим завершується глибоким розбором design doc його валідатора LIVR у порівнянні із Zod і байками з бекендних часів до епохи хмар.
Головне
- AI — це джун, і масштабується він як джуни (ШІ та робочі місця): з одним джуном часто швидше зробити самому; коли джунів десять і щомісяця приходять нові — інвестуєш у стайлгайди, статичний аналіз і стандарти. З AI-агентами так само. На вірусний скриншот «Opus 4.5 за $200/міс економить $4000 на дизайнері та мідлі» він цитує відповідь: «купив мультиварку за $300, економлю $3000 на кухарі — мультиварки захоплюють кулінарію». Основним споживачем інструмента лишається розробник; «10 джунів без сеньйора нічого не зроблять», тож згенерований AI код не безкоштовний — хтось має прочитати його весь.
- AI переускладнює (Абстракції): вигадує непотрібні абстракції — наприклад, ієрархію класів brand-manager із
registerNewBrand()там, де вистачило б простого JSON-файлу з марками авто. Автор постійно каже «видали це, видали ту абстракцію». Це одна з ключових причин читати кожен рядок, як людський PR (Код-ревʼю) — «AI уже більше ревʼюїть PRи, ніж пише їх, але те, що лишилося, все одно ревʼюїть людина». - Поради щодо роботи з Claude Code:
/clearперед кожною задачею (він користується новішою опцією «clear context and accept edits», щоб затверджений план ставав свіжим промптом); запускати кілька Claude паралельно через git worktrees — один локальний репозиторій, багато робочих директорій, що радить і власна документація Anthropic; згодовувати документацію напряму (або через context7), коли знання моделі застаріли. Факт, який його тішить: Claude Code, Gemini CLI і Codex CLI усі написані на React. Cursor він спробував — «не робив те, що мені треба»; CLI, який можна запустити будь-де в його Quake-style терміналі, перемагає встановлення окремого редактора. - Промптити українською цілком нормально: він пояснює це через word2vec/ембединги — семантично близькі слова різних мов лежать поруч у спільному векторному просторі, тож у моделі одне багатомовне «ядро». (Локальні моделі через Cline, ≤14B параметрів, на цьому тлі були «сміттям».)
- Тестування в епоху AI (Автоматизоване тестування): юніт-тести живуть поруч із файлами, інтеграційні/API-тести окремо; тести, що ходять у базу, паралеляться так: піднімаєш один контейнер із 10–20 базами і мапиш ID тест-воркера → номер бази. Тести тепер дешеві, бо їх пише AI, — і AI вони потрібні (разом із TypeScript/статичним аналізом) як петля зворотного звʼязку, бо він не клацатиме по вашому UI. Чи варто тестувати фронтенд — «залежить»: у монорепозиторії Google спільний Angular може оновитися під тобою, тож тестувати треба все; Instagram, як відомо, шипив свій React-вебзастосунок узагалі без фронтенд-тестів.
- Глибокий розбір LIVR проти Zod: правила LIVR — це чисті дані (серіалізовні, трансформовні — їх можна скомпілювати в Zod, а навпаки ні), вони підтримують аліаси правил у дусі DDD (
required + positive_decimalпід аліасомvalid_priceіз власним кодом помилкиINVALID_PRICE) і не роблять кодогенерації (позиція з міркувань безпеки — валідатори в стилі eval він називає «виконанням JS»). «Прогріта» продуктивність порівнянна (Zod ~4 млн опс/с проти ~3,4 млн у LIVR), але на динамічно сконструйованих правилах Zod повільніший приблизно в 94 рази. - Продуктивність — це архітектура, і контекст тримає людина (Проєктування програмного забезпечення): він знає, що гоночних треків буде лише ~100–200 (кешувати в памʼяті назавжди, ніякої пагінації), а точок телеметрії — мільйони (ніколи не зберігати по ентіті на точку). AI цього не знає і «сам собі щось вирішить, що потім вилізе боком». Історії на підтримку: Figma з першого дня була одержима оптимізацією (модулі Rust→WASM), а редактор Monaco у VS Code свідомо відмовився від усіх веб-фреймворків на користь спеціалізованого рушія рендерингу тексту — тоді як Atom, який цього не зробив, програв.
- Плани: витягти бекенд, що вимальовується, в opinionated-бойлерплейт (його модулі
chista/chista-express— оновлення шестирічного стартер-кіта WebbyLab) із включенимиCLAUDE.mdі скілами, «щоб AI уже знав, як із ним працювати», — налаштування інфраструктури це саме та складна задача з купою рішень, яку джун/AI сам не потягне. А ще: завайб-кодити сайт для благодійного фонду WebbyLab (компанія віддає 50% прибутку) і, можливо, гру — йому дуже сподобалася простота Godot, а міні-шутер із видом згори на JS вони з сином уже завайб-кодили за пару годин. - Байка з минулого (Карʼєра і зростання): його перший фронтенд — Mail.ua, single-page app під IE6, — паралельно з Perl-бекендами на власному фреймворку, сховищем на ZFS і бездисковими фронтенд-серверами з PXE-бутом, які на кожному перезапуску тягнули образ Linux у RAM. «Усе, що зараз робить хмара, ми робили руками».