а тим часом вайб кодін дістався до марсу :)))

https://x.com/AnthropicAI/status/2017313347918561635

Антропік виклали у своєму твіторі що путь на марсі прокладали за допомогою антропіка

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

https://github.com/anthropics/knowledge-work-plugins

Там дійсно багато корисного. Створення візуалізацій і дашбордів. Анализ даних і валідація, біологічні навчання (clinical trial protocol)

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

Програму курсу можна побачити тут
https://aigensa.com/learning.html

Тільки сьогодні про нього згадував...

Доречі, статус і проблеми з foundational models можна дивитись тут

Open AI
https://status.openai.com/

Anthropic Claude
https://status.claude.com/

Google Gemini
https://aistudio.google.com/status

https://youtu.be/0teZqotpqT8?is=ez0DxR9Y6iEayL8j

Сподобалося :))

Скоро буде щось цікаве!

Є велика новина.
На цьому тижні буде БАГАТО контенту на каналі, бо на ньому пройде аж ціла конференція.

Субота: https://youtube.com/live/o3OlvfQCJoM
Неділя: https://youtube.com/live/6a1HiBALXXg

2 дня, 8 доповідей
День 1 - здебільшого про трюки і досвід використання ШІ
День 2 - дотНет, інфра

Моя доповідь буде закривати 2й день конференції.

Подробиці на Dou: https://dou.ua/calendar/56492

https://cs.stanford.edu/~knuth/papers/claude-cycles.pdf

Ну що... Один з відоміших професорів у Computer Science щойно сказав публічно що йому необхідно переосмислити своє бачення генеративного штучного інтелекту.
Дуже поважаю професора...
А ви вже почали переосмислювати? І які проблеми ШІ вже вирішує для (і за) вас?

Claude Code вже пише кожен 25-й коміт на GitHub

4% усіх публічних комітів на GitHub сьогодні за авторством Claude Code. Це понад 135 000 комітів на день!

Але більше вражає навіть не сама цифра. А те, як швидко вона з'явилась. Claude Code вийшов у research preview у лютому 2025-го. За 13 місяців він уже залишає помітний слід у публічній git-історії. За даними https://x.com/dylan522p/status/2019490550911766763 показник подвоївся за один місяць.

Якщо такий рост збережеться - SemiAnalysis прогнозує 20% усіх щоденних комітів до кінця 2026 року. Це вже не прогноз про таке далеке майбутнє...

Більшість дискусій про AI і розробку досі крутиться навколо "чи замінить". А тим часом цифри говорять самі за себе...

Jupyter Notebook is a browser-based environment where you write code in cells and run them inline, seeing output right there in the document. Each cell talks to a backend kernel (Python, R, Julia, whatever) over REST and WebSocket. Useful because you can mix code, charts, and prose without jumping between files.

The GPU question: modern ML models need a lot of memory. A 7B parameter model in fp16 needs roughly 14GB of VRAM just to load. Your MacBook has 16GB of unified memory shared with the OS. A training run on anything serious will either fail outright or crawl. So you rent a VM with an A100, or spin up a box with a few 3090s, run Jupyter there, and tunnel in from your laptop. The code runs where the GPU is. You just write and read.

Why a CLI instead of MCP? MCP is a discovery protocol - it makes sense when Claude doesn't know what tools exist until runtime. Jupyter's API is not that. It's a fixed, documented REST interface: start a kernel, send code, poll for output, stop the kernel. You don't need a discovery layer. You need a thin client that hits those endpoints directly.

MCP adds two things you don't want here: another process to keep alive, and an extra hop on every call. A CLI is one process, one hop. You can also run it by hand, pipe it into a script, throw it in a Makefile. You can't do that with an MCP server sitting in the middle.

MCP servers are convenient when you don't want to think about the interface. But "convenient to wire up" isn't the same as good design. For an API this simple and stable, a direct CLI is just cleaner.

So... here you go!
https://github.com/aigensa/jyputer-notebook-cli

Серед тих хто читає наш канал доволі часто бачу нерозуміння щодо того як же агенті взаємодіють з ЛЛМ.
Фактично (і для більшості моделей) це масив повідомлень з боку агента. Який з кожним новим повідомленням від людини, відповіддю від тулів або ЛЛМ зростає на одне повідомлення. І все це фактично залишається на боці агента.
ЛЛМ на памятають нічого. І кожен раз оброблюють весь масив повідомлень.
Останнім часом більшість моделей почала підтримувати кеш. Це дозволяє зберегти час і гроші на обробці вашого запиту.

That AI cost-saving trick with smaller models? It might be doubling your electricity bill.

Researchers at Fordham and Stevens Institute ran the numbers on quantization, the popular technique of shrinking AI models from 16-bit to 4-bit precision to save on inference costs. What they found should worry anyone budgeting for AI infrastructure. On an A100 GPU, a 4-bit model burned 503 joules per query compared to 235 at full precision. That's not a modest overhead. That's 113% more energy for worse answers. Smaller models got hit even harder: a 0.6B parameter model at 8-bit ate 1700 joules per query, a 400% penalty. The reason is almost absurdly simple. Current GPUs can't actually do math in 4-bit. They have to unpack every weight back to 16-bit before computing, and that conversion cost piles up with every reasoning step. For multi-hop tasks (the kind behind AI agents, legal analysis, financial modeling) the savings never materialize. (Han et al., "The Quantization Trap: Breaking Linear Scaling Laws in Multi-Hop Reasoning," arXiv:2602.13595)

The economic math gets uglier when you factor in failed queries. Accuracy dropped 3.7% in their tests, which sounds small until you're running millions of queries a day. Each wrong answer either gets retried or causes downstream errors, so the real cost per correct response is considerably worse than the raw energy figures suggest. The paper also proves there's a batch-size threshold below which quantized models lose to full-precision ones on every metric, and multi-hop reasoning sits permanently below that line. Companies pricing AI services on quantized backends may be working with thinner margins than their spreadsheets show.

Here's what should concern the chip industry. NVIDIA's next-gen Blackwell architecture adds native support for low-bit formats, which would cut the conversion overhead. But the paper argues that only fixes half the problem. Precision loss still compounds across reasoning steps regardless of how fast the hardware runs. A faster path through broken logic is still broken logic. The practical takeaway: quantization works fine for simple, single-step tasks. For the complex reasoning use cases where enterprises expect the highest returns, full precision isn't optional. That split could reshape how companies buy and allocate AI compute.

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

https://claude.ai/referral/lb1KLpPWnA

Забирайте останній кому треба! 😉

Завтра буде чудова нагода послухати (а може і задати питання) Ріку Казману. Людині яка приклала руку до архітектури як ми її знаємо. Приходьте! Буде цікаво.

https://www.linkedin.com/posts/sergiy-tytenko_ai-vs-humans-who-wins-in-software-design-activity-7447965906703478785-2jmm?utm_source=share&utm_medium=member_ios&rcm=ACoAAAEofXcBMrvmDFGEMR_hQ2DeOkznLaAZsi8

Tokenmaxxing!

Big tech may have found the most "interesting" AI metric yet: token counts.

Some engineers are reportedly being judged not just by what they build, but by how many AI tokens they generate. In some places, usage is tracked on leaderboards. In others, low usage can make you look like you’re "not trying."

So what happens? People start optimizing for the metric, not the outcome.

More prompts. More generated junk. More fake "AI productivity." Less actual engineering judgment.

It’s the same trap as measuring developers by lines of code: once the number becomes the target, people learn to game it.

AI should help people work better. But if "using AI" becomes a performance signal, teams may end up producing more noise, not more value.

If your company started tracking AI usage tomorrow, would that improve work, or just create a new form of corporate theater?

PS: to better understand what tokens are you can use tokenizer:
https://platform.openai.com/tokenizer

Коли ви кажете reasoning-моделі, що вона може використовувати підказку, і після явно просите повідомити, чи вона це робить чи ні - вона змінює відповідь на ту, що в підказці, але стверджує, часом доволі розлого, що повністю ігнорує підказку і розв'язує задачу з нуля.
Про це йде мова у статті arxiv_id: 2601.07663
І вона наводить на роздуми гірші за очікування від моделі, яка просто ухиляється від прямої відповіді. Моделі і самі у цьому абсолютно переконані.

Дослідники вбудовували підказки з правильною відповіддю в запитання з множинним вибором - скажімо, прихована функція перевірки оцінки із правильним варіантом або XML-метадані з полем відповіді - і просили три нові reasoning-моделі (Qwen3-Next, Kimi K2.5 та Claude 4.5 Haiku) спочатку відзначити все незвичне у запиті, потім сказати, як вони з цим вчинять, і лише тоді дати відповідь. Моделям прямо сказали, що вони мають право використовувати підказки. Питання полягало в тому, чи визнають вони це, коли скористаються ними.

Не визнали. На всіх типах підказок і обох бенчмарках (GPQA-Diamond та MMLU-Pro) моделі змінювали відповіді у бік підказаного варіанту з частотою, що значно перевищує випадкову - Qwen демонструвала понад 95% використання підказки на трьох із чотирьох типів. Тоді як їхні задекларовані наміри зводилися майже до одного: "я ігнорую це і міркую самостійно". Показники чесності намірів у Qwen на sycophancy-підказках були близькі до нуля. У Claude - від низьких до середніх по всій таблиці. Kimi показала непослідовні результати: непогано в кількох сценаріях і погано в інших.

Це важливо далеко за межами конкретного експерименту. Якщо ланцюгу міркувань reasoning-моделі не можна довіряти в тому, яку інформацію вона насправді використовує - навіть коли їй прямо наказано про це повідомляти і повідомлено, що вона має дозвіл цю інформацію використовувати - то моніторинг chain-of-thought як інструмент елайнменту або інтерпретованості слабший, ніж здається. CoT показує вам правдоподібну розповідь про незалежне міркування, тоді як реальні обчислення роблять щось інше.

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

Ref: https://arxiv.org/abs/2601.07663