Галюцинації ≠ випадковість: без «IDK» модель змушена відповідати
Ваш агент впевнений на 99%? Перевірте: можливо, він 100% вигадав.
Галюцинації — це не баг, це очікуваний результат навчання. Якщо модель ніде не навчають відповідати «не знаю», вона відповідає будь‑що, аби не мовчати. 🤖
Мій агент упевнено «знайшов» статтю, якої не існує. Тон упевнений, посилання — вигадане. Причина проста: під час навчання моделі не були включені кейси в яких модель відповідала б "I don't know" і не отримувала за такі відповіді додаткових балів під час навчання.
Суть. Більшість моделей під час навчання не використовують «IDK» (I don't know) в даних і в метриках якості. Тому модель оптимізують за «відповідай краще», а не «визнай невпевненість». У результаті — надмірна впевненість і вигадки навіть там де це не очікується. Це добре узгоджується з висновками недавньої роботи на arXiv (https://www.arxiv.org/pdf/2509.04664). 🧠
Можливі опції що з цим робити сьогодні:
- очікуємо foundational model яка буде навчена з врахуванням «IDK»
- файн тюнимо свою модель на базі існуючих OSS / open weights models з «IDK» тестами
- загружаємо в контекст моделі необхідну інформацію і робимо grounding (базуємо відповідь лише на даних з контекста).
Під час використання foundational models використовуємо рекомендації щоб уникнути галюцинацій такі як наприклад від anthropic (https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-hallucinations#basic-hallucination-minimization-strategies).
А як ви зараз боретеся з галюцинаціями та чи доводиться вам з ними стикатися?
Ваш агент впевнений на 99%? Перевірте: можливо, він 100% вигадав.
Галюцинації — це не баг, це очікуваний результат навчання. Якщо модель ніде не навчають відповідати «не знаю», вона відповідає будь‑що, аби не мовчати. 🤖
Мій агент упевнено «знайшов» статтю, якої не існує. Тон упевнений, посилання — вигадане. Причина проста: під час навчання моделі не були включені кейси в яких модель відповідала б "I don't know" і не отримувала за такі відповіді додаткових балів під час навчання.
Суть. Більшість моделей під час навчання не використовують «IDK» (I don't know) в даних і в метриках якості. Тому модель оптимізують за «відповідай краще», а не «визнай невпевненість». У результаті — надмірна впевненість і вигадки навіть там де це не очікується. Це добре узгоджується з висновками недавньої роботи на arXiv (https://www.arxiv.org/pdf/2509.04664). 🧠
Можливі опції що з цим робити сьогодні:
- очікуємо foundational model яка буде навчена з врахуванням «IDK»
- файн тюнимо свою модель на базі існуючих OSS / open weights models з «IDK» тестами
- загружаємо в контекст моделі необхідну інформацію і робимо grounding (базуємо відповідь лише на даних з контекста).
Під час використання foundational models використовуємо рекомендації щоб уникнути галюцинацій такі як наприклад від anthropic (https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/reduce-hallucinations#basic-hallucination-minimization-strategies).
А як ви зараз боретеся з галюцинаціями та чи доводиться вам з ними стикатися?
🔥6👍2
Як я стискаю AI-новини за 15 хв і не вигораю
Мій рецепт економії часу для AI-апдейтів: простий ноутбук + 4 кроки.
AI-новин більше, ніж часу. Мій апдейт тепер займає ~15 хв замість цілого вечора. ⏱️Як я це роблю: завантажую в NotebookLM 10–20 останніх роликів з новинами на YouTube і прошу: “Виділи головне та як це вплине на розробку систем на горизонті 6–12 місяців.” Результат — короткі тези і “чому це важливо для девів”. ✅
Ось приклад ноутубука де можна також згенерувати аудіо, відео, майндмеп або ще щось (якщо немає часу дивитись і потрібен "подкаст") https://notebooklm.google.com/notebook/f58bd70a-79ad-4c76-bd51-712e6095c15b
Мінус: API для NotebookLM я не знайшов (можливо, його й справді немає).
Тож планую зробити свій фід: агрегую джерела → ранжую локальними ЛЛМ → роблю короткі брифінги. Локальні моделі майже безкоштовні й дають пристойну якість. 💻
Порада проти “галюцинацій”: NotebookLM “з коробки” галюцинує мінімально, а для інших моделей просіть позначати сумнівні місця, давати короткі цитати з джерел та окремо пояснювати “чому це важливо”.Краще зробити простий фактчек, ніж мати красивий, але такий, що не спирається на дані, дайджест.
Хештеги: #agents #AI #automation #vibecoding #productivity
Як ви зараз фільтруєте AI-новини: вручну, через RAG/агентів чи готові дайджести — і що болить найбільше?
Мій рецепт економії часу для AI-апдейтів: простий ноутбук + 4 кроки.
AI-новин більше, ніж часу. Мій апдейт тепер займає ~15 хв замість цілого вечора. ⏱️Як я це роблю: завантажую в NotebookLM 10–20 останніх роликів з новинами на YouTube і прошу: “Виділи головне та як це вплине на розробку систем на горизонті 6–12 місяців.” Результат — короткі тези і “чому це важливо для девів”. ✅
Ось приклад ноутубука де можна також згенерувати аудіо, відео, майндмеп або ще щось (якщо немає часу дивитись і потрібен "подкаст") https://notebooklm.google.com/notebook/f58bd70a-79ad-4c76-bd51-712e6095c15b
Мінус: API для NotebookLM я не знайшов (можливо, його й справді немає).
Тож планую зробити свій фід: агрегую джерела → ранжую локальними ЛЛМ → роблю короткі брифінги. Локальні моделі майже безкоштовні й дають пристойну якість. 💻
Порада проти “галюцинацій”: NotebookLM “з коробки” галюцинує мінімально, а для інших моделей просіть позначати сумнівні місця, давати короткі цитати з джерел та окремо пояснювати “чому це важливо”.Краще зробити простий фактчек, ніж мати красивий, але такий, що не спирається на дані, дайджест.
Хештеги: #agents #AI #automation #vibecoding #productivity
Як ви зараз фільтруєте AI-новини: вручну, через RAG/агентів чи готові дайджести — і що болить найбільше?
Google
Google NotebookLM | Your research and thinking partner, grounded in the information you trust
Use the power of AI for quick summarization and note taking, NotebookLM is your powerful virtual research assistant rooted in information you can trust.
❤8🔥1
Copilot CLI і нова хвиля “агентів у терміналі”
GitHub викотив новий Copilot CLI (публічний прев’ю) — це не просто “ще одна тулза”, а підтвердження тренду: vibe‑coding інструменти дедалі більше покривають сценарії без прямої участі програміста. (https://github.blog/changelog/2025-09-25-github-copilot-cli-is-now-in-public-preview?utm_source=openai)
Сьогодні рутину типу code review чи генерації тестів можна знімати стеками: Claude Code, Copilot CLI, Cursor, Codex CLI. І це не теорія — є живі конфіги для CI/CD і security‑рев’ю.
Приклади:
OpenAI Cookbook: Codex CLI в GitLab, що збирає CodeClimate‑репорт і навіть пропонує патчі.
(https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
Anthropic: /security‑review у Claude Code з GitHub Actions. (https://www.anthropic.com/news/automate-security-reviews-with-claude-code?utm_source=openai)
Але. Навіть якщо завтра Claude напише вам фронт і шмат бекенду — роль девелопера лишається: тримати рамки. Інакше ризик “архітектурного заносу”: з нізвідки підключився ClickHouse, або React тихо перетворився на Angular. 🙂
Обовязкові guardrails, щоб не злетіти з траси:
1 Задекларуйте дозволений стек включаючи бази в README / RULES / Claude.md
2 Обовязкові політики і рули в лінтері + обовязковий лінтер в CI (наприклад за допомогою https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-dependencies)
3 Агенти — тільки “diff‑first”: усе через PR із чітким описом змін
4 На всіх кінцях в обовязковому порядку прописані контракти (наприклад OpenAPI або https://www.asyncapi.com/) і валідація для JSON‑виводу і валідація (https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
5 Мінімальні патчі > “розумні” рефакторинги.
Ну і так... в мене поки що просто копілот CLI перманентно глючить...
https://github.com/github/copilot-cli %)
GitHub викотив новий Copilot CLI (публічний прев’ю) — це не просто “ще одна тулза”, а підтвердження тренду: vibe‑coding інструменти дедалі більше покривають сценарії без прямої участі програміста. (https://github.blog/changelog/2025-09-25-github-copilot-cli-is-now-in-public-preview?utm_source=openai)
Сьогодні рутину типу code review чи генерації тестів можна знімати стеками: Claude Code, Copilot CLI, Cursor, Codex CLI. І це не теорія — є живі конфіги для CI/CD і security‑рев’ю.
Приклади:
OpenAI Cookbook: Codex CLI в GitLab, що збирає CodeClimate‑репорт і навіть пропонує патчі.
(https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
Anthropic: /security‑review у Claude Code з GitHub Actions. (https://www.anthropic.com/news/automate-security-reviews-with-claude-code?utm_source=openai)
Але. Навіть якщо завтра Claude напише вам фронт і шмат бекенду — роль девелопера лишається: тримати рамки. Інакше ризик “архітектурного заносу”: з нізвідки підключився ClickHouse, або React тихо перетворився на Angular. 🙂
Обовязкові guardrails, щоб не злетіти з траси:
1 Задекларуйте дозволений стек включаючи бази в README / RULES / Claude.md
2 Обовязкові політики і рули в лінтері + обовязковий лінтер в CI (наприклад за допомогою https://npmpackagejsonlint.org/docs/rules/dependencies/no-restricted-dependencies)
3 Агенти — тільки “diff‑first”: усе через PR із чітким описом змін
4 На всіх кінцях в обовязковому порядку прописані контракти (наприклад OpenAPI або https://www.asyncapi.com/) і валідація для JSON‑виводу і валідація (https://cookbook.openai.com/examples/codex/secure_quality_gitlab?utm_source=openai)
5 Мінімальні патчі > “розумні” рефакторинги.
Ну і так... в мене поки що просто копілот CLI перманентно глючить...
https://github.com/github/copilot-cli %)
The GitHub Blog
GitHub Copilot CLI is now in public preview - GitHub Changelog
GitHub Copilot CLI is now in public preview We’re bringing the power of GitHub Copilot coding agent directly to your terminal. With GitHub Copilot CLI, you can work locally and…
👍2🔥2❤1
Anthropic щойно випустив підтримку для plugin marketplace у Claude Code.
Чому це важливо?
Бо кожен з розробників має свої підходи для розробки, свої хуки, агентів і т. ін.
Можливість використовувати маркетплейси дозволяє шерити всі ці частини SDLC в рамках команд та більш широкого загалу.
Оригінал новини тут:
https://docs.claude.com/en/docs/claude-code/plugin-marketplaces
Як і зазвичай це потенційне віконце до можливих проблем з безпекою, але також і можливість зробити ваш вайб кодінг workflow набагато більш продуктивним.
Враховуючи що сьогодні лише перший день коли функціональність може бути використана я знайшов лише одного автора який вже зробив marketplace.json доступним. Ось його репозиторій
щоб додати маркетплейс відкриваєте клод код, /plugin заходите в Add MarketPlace і вводите кординати до репозіторія. Після цього ви можете бачити у списку плагінів всіх сабагентів яких він пропонує. Впевнений що скоро там зявляться і його хуки.
А може й ваші 😉
Чому це важливо?
Бо кожен з розробників має свої підходи для розробки, свої хуки, агентів і т. ін.
Можливість використовувати маркетплейси дозволяє шерити всі ці частини SDLC в рамках команд та більш широкого загалу.
Оригінал новини тут:
https://docs.claude.com/en/docs/claude-code/plugin-marketplaces
Як і зазвичай це потенційне віконце до можливих проблем з безпекою, але також і можливість зробити ваш вайб кодінг workflow набагато більш продуктивним.
Враховуючи що сьогодні лише перший день коли функціональність може бути використана я знайшов лише одного автора який вже зробив marketplace.json доступним. Ось його репозиторій
щоб додати маркетплейс відкриваєте клод код, /plugin заходите в Add MarketPlace і вводите кординати до репозіторія. Після цього ви можете бачити у списку плагінів всіх сабагентів яких він пропонує. Впевнений що скоро там зявляться і його хуки.
А може й ваші 😉
👍3
доволі активно попрацювавши з BMAD v6 на цьому тижні можу сказати наступне:
він набагато краще фоловить воркфлоу. самостійно без нагадування апдейтить документи і повертається до процедури навіть якщо його "відволікли".
в цілому набагато більше сфокусований, при цьому не намагається додавати умовно кажучи редіс там де не просили і 10 баз там де не потрібно.
сам себе критикує, сам виправляє помилки і в результаті дуже гарно справляється з green field девелопментом.
коли робить апдейти документів - робить їх прям дуже спрямовано без зайвого шуму (одразу змінює саме те що необхідно змінити. без пошуку, відкривання "не тих файлів" і т.ін)
є конвенції типу FR (functional requirements), NFR (non-functional requirements). Все ще присутній процес ідеації. Але наразі це навіть порівнюючи з v4 набагато більш доречні пропозиції, і, звісно... результати.
додатково все ж таки з`явився PRD документ в якому фіксують ці самі реквайрменти і т.ін.
він набагато краще фоловить воркфлоу. самостійно без нагадування апдейтить документи і повертається до процедури навіть якщо його "відволікли".
в цілому набагато більше сфокусований, при цьому не намагається додавати умовно кажучи редіс там де не просили і 10 баз там де не потрібно.
сам себе критикує, сам виправляє помилки і в результаті дуже гарно справляється з green field девелопментом.
коли робить апдейти документів - робить їх прям дуже спрямовано без зайвого шуму (одразу змінює саме те що необхідно змінити. без пошуку, відкривання "не тих файлів" і т.ін)
є конвенції типу FR (functional requirements), NFR (non-functional requirements). Все ще присутній процес ідеації. Але наразі це навіть порівнюючи з v4 набагато більш доречні пропозиції, і, звісно... результати.
додатково все ж таки з`явився PRD документ в якому фіксують ці самі реквайрменти і т.ін.
❤6
Anthropic перший зрозумів що передача всіх відповідей від MCP тулів у LLM модель - доволі не ефективна історія. Поперше bandwidth моделі не резиновий і доволі часто є обмеженням у enterprise environments.
Наприклад ми стикалися з тим що AWS деяким клієнтам не бажав збільшувати цей самий bandwidth для Claude моделей. Звісно є і "кохані" клієнти яких всі люблять і там ці питання вирішуються швидко. Але...
По друге за кожен токен (мільйон токенів) необхідно сплачувати гроші. А проміжкові результати не завжди цікаві бізнесу і сплачувати за них компанії в цілому готові лише як за необхідне зло. І якщо можно цього не робити - то вони будуть тільки раді не сплачувати.
Також, для того щоб моделі почали використовувати тули необхідно щоб під час "створення агента" модель знала про наявність тулів, їх методів і т.ін. Для цього використовуються ті ж самі токени, які заповнюють контекстне вікно моделі (фактично це стає частиною вашого system prompt) і це призводить до того що кожен раз коли виконується запит до LLM ви платите грощі за "підтримку кожної тули".
Якщо в рамках нашого workflow використовуються складні структури даних або великі обсяги інформації - вірогідність помилок під час копіювання інформації збільшується.
Також велика кількість доступних тулів призводила до того що модель не могла зрозуміти які тули обирати, обсяг доступного вікна ставав дедалі меньшим і воно використовувалося не так ефективно як могло б.
Тож anthropic вигадав використовувати MCP сервери як API замість визовів тулів. Фактично це дає можливість реалізувати lazy loading замість того щоб на етапі проектування додавати всі моделі і одразу загружати інформацію про них в контекст.
Модель бере умовно кажучи заголовки і вичітує їх при потребі що (на прикладі Anthropic) зменьшило використання токенів з 150 000 до 2 000 за одну операцію. Це, доречі, час на виконання операції теж зменьшує суттєво.
Звісно виконання коду тягне з собою інші ризики, бо фактично цей код має рівень доступу на рівні моделі яка його виконує.
Оригінал тут:
https://www.anthropic.com/engineering/code-execution-with-mcp
PS: доречі, сьогодні спілкувався з хлопцем який мені підсвітив цікавий момент - не всі знають що таке MCP, токени і т.ін.
Тож на днях спробую розкрити тему і дати більше розуміння про всі ці страшні слова. Якщо у вас є такі (які ще не зрозумілі) - пишіть. Буду радий поділитися і поспілкуватися щодо того що це за звірятка.
Наприклад ми стикалися з тим що AWS деяким клієнтам не бажав збільшувати цей самий bandwidth для Claude моделей. Звісно є і "кохані" клієнти яких всі люблять і там ці питання вирішуються швидко. Але...
По друге за кожен токен (мільйон токенів) необхідно сплачувати гроші. А проміжкові результати не завжди цікаві бізнесу і сплачувати за них компанії в цілому готові лише як за необхідне зло. І якщо можно цього не робити - то вони будуть тільки раді не сплачувати.
Також, для того щоб моделі почали використовувати тули необхідно щоб під час "створення агента" модель знала про наявність тулів, їх методів і т.ін. Для цього використовуються ті ж самі токени, які заповнюють контекстне вікно моделі (фактично це стає частиною вашого system prompt) і це призводить до того що кожен раз коли виконується запит до LLM ви платите грощі за "підтримку кожної тули".
Якщо в рамках нашого workflow використовуються складні структури даних або великі обсяги інформації - вірогідність помилок під час копіювання інформації збільшується.
Також велика кількість доступних тулів призводила до того що модель не могла зрозуміти які тули обирати, обсяг доступного вікна ставав дедалі меньшим і воно використовувалося не так ефективно як могло б.
Тож anthropic вигадав використовувати MCP сервери як API замість визовів тулів. Фактично це дає можливість реалізувати lazy loading замість того щоб на етапі проектування додавати всі моделі і одразу загружати інформацію про них в контекст.
Модель бере умовно кажучи заголовки і вичітує їх при потребі що (на прикладі Anthropic) зменьшило використання токенів з 150 000 до 2 000 за одну операцію. Це, доречі, час на виконання операції теж зменьшує суттєво.
Звісно виконання коду тягне з собою інші ризики, бо фактично цей код має рівень доступу на рівні моделі яка його виконує.
Оригінал тут:
https://www.anthropic.com/engineering/code-execution-with-mcp
PS: доречі, сьогодні спілкувався з хлопцем який мені підсвітив цікавий момент - не всі знають що таке MCP, токени і т.ін.
Тож на днях спробую розкрити тему і дати більше розуміння про всі ці страшні слова. Якщо у вас є такі (які ще не зрозумілі) - пишіть. Буду радий поділитися і поспілкуватися щодо того що це за звірятка.
Anthropic
Code execution with MCP: building more efficient AI agents
Learn how code execution with the Model Context Protocol enables agents to handle more tools while using fewer tokens, reducing context overhead by up to 98.7%.
❤3
Agent Skills від Anthropic - це спроба дати агентам можливість виконувати конкретні інструкції для виконання конкретної задачі.
Навичка (skill) - це не монолітна інструкція, а набір знань і процедур, які не засмічують контекст кожної сесії. Для розробників, що практикують вайб‑кодінг і тісно спілкуються з моделлю під час роботи, ця ідея звучить практично: менше тягнути в промпт наперед, більше читати й виконувати по мірі потреби. Виходить прозоріше, дешевше, стабільніше. І це помітно вже з перших ітерацій.
Механіка використання проста: навичка живе у окремій папці зі SKILL.md, де на старті агент бачить лише назву і стислий опис. Цього достатньо, щоб модель пам’ятала, коли й навіщо звертатися до вмісту глибше, не витрачаючи контекст на «все й одразу». Коли з’являється завдання, агент дочитує повний файл і додаткові матеріали, тримаючи трафік токенів під контролем. Це і є «ліниве завантаження» знань.
Для девелопера це означає, що контекст використовується меньше і грошей витрачати теж будемо меньше.
Економія проявляється на всіх етапах. Кожен зайвий абзац у промпті - це токени, за які ви платите, і затримка, яку ви відчуваєте. Коли інструкції не тягнуться в кожен запит, а викликаються за потреби, латентність падає, а вартість епізоду обчислень стає передбачуванішою. У вайб‑кодінгу це особливо помітно: розробник швидко змінює напрямок і не тягне у кожну взаємодію величезний claude.md.
Ще одна корисна опція - описувати навички не обовʼязково текстом. Навички підтримують можливість виконуваний код, який агент викликає замість багатослівних описів кроків. Коли процес краще зловити функцією, а не абзацом, код дає надійність і повторюваність.
Але в який раз нагадую про те що ви дбаєте про свою безпеку самостійно. Обмеження мережевих викликів і прозоре логування операцій це база. Якщо додаєте сторонню навичку в свій процес вайб‑кодінгу, перевіряйте її так само уважно, як бібліотеку у продакшн‑сервісі. Тоді «ліниве завантаження» не перетвориться на «ліниву перевірку», і ви не отримаєте сюрпризів у найменш вдалий момент.
Оригінал можна подивитись тут: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Навичка (skill) - це не монолітна інструкція, а набір знань і процедур, які не засмічують контекст кожної сесії. Для розробників, що практикують вайб‑кодінг і тісно спілкуються з моделлю під час роботи, ця ідея звучить практично: менше тягнути в промпт наперед, більше читати й виконувати по мірі потреби. Виходить прозоріше, дешевше, стабільніше. І це помітно вже з перших ітерацій.
Механіка використання проста: навичка живе у окремій папці зі SKILL.md, де на старті агент бачить лише назву і стислий опис. Цього достатньо, щоб модель пам’ятала, коли й навіщо звертатися до вмісту глибше, не витрачаючи контекст на «все й одразу». Коли з’являється завдання, агент дочитує повний файл і додаткові матеріали, тримаючи трафік токенів під контролем. Це і є «ліниве завантаження» знань.
Для девелопера це означає, що контекст використовується меньше і грошей витрачати теж будемо меньше.
Економія проявляється на всіх етапах. Кожен зайвий абзац у промпті - це токени, за які ви платите, і затримка, яку ви відчуваєте. Коли інструкції не тягнуться в кожен запит, а викликаються за потреби, латентність падає, а вартість епізоду обчислень стає передбачуванішою. У вайб‑кодінгу це особливо помітно: розробник швидко змінює напрямок і не тягне у кожну взаємодію величезний claude.md.
Ще одна корисна опція - описувати навички не обовʼязково текстом. Навички підтримують можливість виконуваний код, який агент викликає замість багатослівних описів кроків. Коли процес краще зловити функцією, а не абзацом, код дає надійність і повторюваність.
Але в який раз нагадую про те що ви дбаєте про свою безпеку самостійно. Обмеження мережевих викликів і прозоре логування операцій це база. Якщо додаєте сторонню навичку в свій процес вайб‑кодінгу, перевіряйте її так само уважно, як бібліотеку у продакшн‑сервісі. Тоді «ліниве завантаження» не перетвориться на «ліниву перевірку», і ви не отримаєте сюрпризів у найменш вдалий момент.
Оригінал можна подивитись тут: https://www.anthropic.com/engineering/equipping-agents-for-the-real-world-with-agent-skills
Anthropic
Equipping agents for the real world with Agent Skills
Discover how Anthropic builds AI agents with practical capabilities through modular skills, enabling them to handle complex real-world tasks more effectively and reliably.
👍2
https://www.youtube.com/shorts/aIvHf8vsWBM
один з ярчайших людей у сучасному ШІ. Ілля Суцкевер. Про vibe coding і причини чому агенти пропонують фікс до однієї проблеми і в ньому повертаються до іншої.
https://www.youtube.com/watch?v=aR20FWCCjAs
повне інтервью тут і я вважаю що саме такі інтервʼю як і інші фундаментальні роботи якнайкраще заставляють замислитись щодо того які проблеми ми бачимо, куди рухається ШІ світ і де ми будемо за 3-5 років.
один з ярчайших людей у сучасному ШІ. Ілля Суцкевер. Про vibe coding і причини чому агенти пропонують фікс до однієї проблеми і в ньому повертаються до іншої.
https://www.youtube.com/watch?v=aR20FWCCjAs
повне інтервью тут і я вважаю що саме такі інтервʼю як і інші фундаментальні роботи якнайкраще заставляють замислитись щодо того які проблеми ми бачимо, куди рухається ШІ світ і де ми будемо за 3-5 років.
YouTube
Why Vibe Coding Fails - Ilya Sutskever
Enjoy the videos and music you love, upload original content, and share it all with friends, family, and the world on YouTube.
❤2
https://mistral.ai/news/mistral-3
а тим часом містраль все ж таки випустив нові моделі %)
тож прошу дивитись і насолоджуватись! %)
як на мене моделі дуже цікаві. enjoy! 😉
містраль намагається робити невеликі сфокусовані моделі які досягають дуже гарного cost / benefits співвідношення.
тож ви не отримаєте супер високої якості від аналітичних здібностей моделей, але для кодінгу воно працює дуже непогано
а тим часом містраль все ж таки випустив нові моделі %)
тож прошу дивитись і насолоджуватись! %)
як на мене моделі дуже цікаві. enjoy! 😉
містраль намагається робити невеликі сфокусовані моделі які досягають дуже гарного cost / benefits співвідношення.
тож ви не отримаєте супер високої якості від аналітичних здібностей моделей, але для кодінгу воно працює дуже непогано
Mistral AI
Introducing Mistral 3 | Mistral AI
The most powerful AI platform for enterprises. Customize, fine-tune, and deploy AI assistants, autonomous agents, and multimodal AI with open models.
А тим часом кодекс вже почав (поки що в експериментальному режимі) підтримувати скіли. Що це означає: меньше проблем з менеджментом контексту та більше токенів для контексту який ми самі створимо замість забитого MCP. Дешевші взаємодії з ллм. І меньше часу на генерацію відповідей.
https://share.google/A06J4BucP6BeEB5pV
Оригінал ідеї скілів тут
https://share.google/6y4UV7gIol3EqrkKo
https://share.google/A06J4BucP6BeEB5pV
Оригінал ідеї скілів тут
https://share.google/6y4UV7gIol3EqrkKo
OpenAI Developer Community
Skills for Codex: Experimental support starting today
I have seen this feature request for Codex quite a few times and now it’s actually coming: Here is a link to the rough documentation. And an explanation what skills are and why you may want to use them. Happy building and please remember that this is…
❤3
Здається і на нашій вулиці свято!
https://openrouter.ai/docs/guides/guides/claude-code-integration
У опенраутер занесли інтеграцію з Claude Code.
У великому відсотку випадків я все ще вважаю що це найкращий тул для агнетного кодінгу. Окрім випадків коли вам потрібно бачити або контролювати до останньої коми код який ви пишете.
https://openrouter.ai/docs/guides/guides/claude-code-integration
У опенраутер занесли інтеграцію з Claude Code.
У великому відсотку випадків я все ще вважаю що це найкращий тул для агнетного кодінгу. Окрім випадків коли вам потрібно бачити або контролювати до останньої коми код який ви пишете.
З цікавого в claude code нещодавна занесли LSP. Що це означає?
що пошук символів в CLI based тулах буде знаходити всі "entries" як це зараз робить ваша IDE. Це суттєво пришвидшить якість рефакторингу і покращить роботу з наприклад оверрайдами методів. Тож в наступному році нас чекає ще більше цікавих прикладів використання і все більше інструментів для написання коду який ми вже пишемо.
Якщо комусь цікаві новини вайб кодінгу - слідкуйте за
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
https://developers.openai.com/codex/changelog/
та
https://geminicli.com/docs/changelogs/
що пошук символів в CLI based тулах буде знаходити всі "entries" як це зараз робить ваша IDE. Це суттєво пришвидшить якість рефакторингу і покращить роботу з наприклад оверрайдами методів. Тож в наступному році нас чекає ще більше цікавих прикладів використання і все більше інструментів для написання коду який ми вже пишемо.
Якщо комусь цікаві новини вайб кодінгу - слідкуйте за
https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md
https://developers.openai.com/codex/changelog/
та
https://geminicli.com/docs/changelogs/
GitHub
claude-code/CHANGELOG.md at main · anthropics/claude-code
Claude Code is an agentic coding tool that lives in your terminal, understands your codebase, and helps you code faster by executing routine tasks, explaining complex code, and handling git workflo...
👍3🔥1
