Після цих двох опитувань — ось вам корисний відос на цю тему. Там розповідають про "AI-код: хайп vs реальність" і чому люди часто роблять криві висновки.

TL;DR:
- AI реально піднімає output (більше задач/PR’ів/коду)
- рев’ю + валідація стають вузьким горлом (інколи навіть гірше по часу)
- довіра і якість ростуть, коли є тести + quality рев'ю + нормальний контекст (а не "тримай, моделько, 2 файли і роби магію")

https://youtu.be/rgjF5o2Qjsc?si=9qYRkhUeJkF_9sA0

🚗 TRINITY — AI-агент на колесах від will.i.am

will.i.am (William James Adams Jr.) — американський музикант, продюсер, учасник Black Eyed Peas.
Але він також давно в tech-тусовці: інвестує в стартапи, співпрацює з компаніями типу Intel, і ось тепер показує власний AI-транспорт на CES.

На CES 2026 will.i.am показав дещо цікаве: одномісну трьохколісну капсулу-EV, де головний апгрейд — не мотор, а ШІ-агент всередині. Концепт називають “Human + Vehicle + Agent”, і це виглядає як vibe-coding, але в залізі.

⚡️ Що обіцяють:

• Розгін 0–60 менше 2 секунд
• Топ-швидкість до 120 mph (~193 км/г)
• Self-balancing (само-балансування)
• Weatherproof салон + студійний звук
• Перша партія ~500 штук, ціна до $30k

🧠 Найцікавіше — “мозок”

Всередині стоїть NVIDIA DGX Spark — компактний AI-суперкомп’ютер з 128GB unified memory і до 1 PFLOP FP4. Тобто великі моделі можуть працювати локально, без хмари. Ідея в тому, що ти не просто “керуєш машиною”, а розмовляєш з нею як з напарником, який веде контекст твоїх цілей і маршрутів.

Не з першого промпту але додав візуалізацію коли говориш)

В Селестії новий формат резюме історії чату, публікується кожний день)

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

🤖 Cursor виклали гайд по роботі з AI-агентами

Зібрали всі best practices в одну статтю. Більшість з цього я вже юзаю в Claude Code, але це дійсно непоганий гайд для тих хто досі не став ШІ євангелістом.

Головні інсайти:
• Shift+Tab — Plan Mode, агент спочатку планує, потім кодить. Плани зберігаються в .cursor/plans/
Від мене: Дуже важливо створювати план якщо очікувані зміни більше 100-200 рядків коду

• Довгі чати = втрата фокусу. Новий чат на кожну нову задачу

• Rules (.cursor/rules/) — статичний контекст для кожного чату. Skills (див. Claude agent skills)

• TDD з агентом працює найкраще — тести дають йому чітку ціль для ітерації

• Debug Mode — генерує гіпотези, додає логування, аналізує runtime. Для складних багів

• Можна запускати декілька моделей паралельно через worktrees і порівнювати результати

Цитата дня:

AI-generated code can look right while being subtly wrong

📎 https://cursor.com/blog/agent-best-practices

⚙️ Очікування vs Реальність вайбкодингу

Налаштовую собі cron job: щодня о 9:00 запускаються два sub-agents паралельно — один парсить GitHub Issues, інший лізе в ClickHouse аналізувати логи. Main Agent порівнює результати і кидає звіт в телеграм. Thinking: High. Краса!

Прокидаюсь, відкриваю телефон…

{"type":"error","message":"Overloaded"}

Ха-ха-ха прекрасно. Типовий Клод 🫠

Це все що вам треба знати про стабільність агентних систем. Розумний, вміє планувати, але коли треба працювати о 9 ранку — він теж не хоче

Вайбкодинг — це прекрасно, доки не впираєшся в ліміти API.

Фактично це клод код в телеграмі)

🧵 5 типів тредів в AI-інженерії — розбираємось як працювати з агентами ефективніше

Нещодавно натрапив на цікаву концепцію від IndyDevDan — Thread-based Engineering. По суті, це класифікація того, як ми взаємодіємо з ШІ-агентами. І знаєте що? Виявляється, я інтуїтивно вже використовував деякі з цих патернів, навіть не знаючи що вони так називаються!

1️⃣ Base Thread — базовий цикл

Класика жанру: промпт → агент працює → результат. Один запит — одна відповідь. Це те, з чого всі починають, і це фундамент для всього іншого.

2️⃣ P-Thread (Parallel) — паралельний

Тут вже цікавіше! Запускаєте кілька агентів *одночасно* на різні задачі:
• Один пише фронтенд
• Другий — бекенд
• Третій — тести

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

3️⃣ C-Thread (Chained) — ланцюговий

Розбиваєте складну задачу на фази з валідацією між ними:
• Phase 1: План → ✅ перевірили
• Phase 2: Код → ✅ перевірили
• Phase 3: Тести → фінальний результат

4️⃣ F-Thread (Fusion) — злиття

Моя улюблена тема — даєте *одну й ту саму* задачу різним агентам або моделям (Claude, GPT, Gemini) і порівнюєте результати. Часто одна модель бачить те, що інша пропустила. Fusion — це про якість, не про швидкість.

5️⃣ L-Thread (Long) — довгий

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


💡 Практичні поради:

• Для простих фіксів — Base Thread достатньо
• Для великих фіч — Chained з покроковою валідацією
• Для code review — Fusion (порівнюйте Claude vs GPT)
• Відчуваєте що агент “поплив”? — це L-Thread, час рестартити

🔄 Вже чули про Ralph technique?

Є така проблема: чим більше токенів в контексті, тим “тупішим” стає агент до кінця. Ralph technique — це рішення для амбітних планів, де контексту завжди буде забагато.

🔧 Як це працює:

• Агент працює в межах бюджету токенів (зазвичай ~80k)
• Коли ліміт досягнуто — агент “вмирає” і стартує новий з чистого аркуша
• Новий Ralph читає загальний план, визначає де зупинився попередній, продовжує роботу
• Прогрес зберігається між ітераціями, але контекст — ні

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

✅ Коли юзати:

• Великі амбітні плани де контексту точно не вистачить
• Довгі цикли розробки
• Коли compaction не дає потрібної якості

⚠️ Що важливо:

Щоб Ralph працював — кодова база має бути добре організована: маленькі файли, чітко розділені плани, легка навігація. Бо кожен новий Ralph “тупий” і має швидко зорієнтуватися де він і що робити далі. Також потрібен supervision — не можна просто запустити і забути.​​​​​​​​​​​​​​​​