TGViewer
Channel Public Channel
AI не справился // НЕЙШН

AI не справился // НЕЙШН

@ai_fucked_up

Пишем о том, когда AI справился, а когда - нет. Делимся своим мнением и обсуждаем актуальные новости.

Канал ведут Миша Овчинников, Коля Барышников и Даниил Пилипенко.

Youtube - https://www.youtube.com/@ai_fucked_up

Сайт: naition.ai
Subscribers
207
Photos
32
Videos
9
Links
54
Recent Posts 20 shown
Post #148 54
Друзья, через 20 минут проводим эфир с Глебом Михеевым

Тема - Как за месяц переписали веб-приложение с многомиллионной аудиторией агентами и перешли на агентую разработку

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

👉 Приходите по ссылке
  • 👍 3
Post #147 55
  • 😁 4
Post #146 72
Открываем запись на третий поток буткемпа

Приглашаем к нам тех, кто пишет код уже 5–7 лет и хочет профессионально освоить AI.

Стартуем 6 октября.

▶️Занимаемся 12 недель. Всегда по вторникам в вечернее время. Иногда добавляем ещё один урок среди недели.
▶️Одно занятие длится 2–3 часа. Из них — не менее 1,5 часов практики в режиме онлайн. Можно задавать вопросы и обращаться за помощью.
▶️Есть домашние задания. Они занимают 2–5 часов в неделю. Практиковаться можно на собственном проекте.
▶️Все материалы сохраняются в личном кабинете. Если пропустили урок, он доступен в записи.

Что в программе:

✔️AI как инструмент: трансформация роли разработчика, продуктовая итерация через AI-аналитику
✔️Качество и контекст: evals, контекст-инжиниринг, харнесы, Spec Kit
✔️Агенты: мультиагентные системы, RAG, разработка агентов, тулы
✔️Сложные кейсы: легаси, аудит безопасности, незнакомые системы, архитектурная трансформация
✔️Масштабирование: внедрение в команду и позиционирование на рынке

Ведем мы — я, Даня и Миша, практикующие инженеры из Google, Яндекса и бигтеха. Бывает, устраиваем сюрпризы и зовем других экспертов из индустрии.

Набор открыт. До 2 октября действует скидка 20% на раннее бронирование.
Кто надумал, переходите на сайт:

https://ai-nation.ru/dev/


Кто посматривает на наш буткемп, но сомневается, ждем вас в комментариях.
НЭЙШН AI DRIVEN РАЗРАБОТКА — 12-недельный буткемп Двенадцать недель практики: спецификации, агенты-ревьюеры, прод-контур и оценка качества. Семнадцать занятий и артефакт после каждого модуля.
  • 👍 2
  • 🔥 2
Post #145 109
Модель искусственного интеллекта Google Gemini во время тестирования своих возможностей в сфере кибербезопасности самостоятельно взломала системы трех компаний, рассказали BBC News. 🤦‍♂️

Там отметили, что это первый известный случай, когда ИИ-модель от Google совершила подобные действия. 
«Gemini обнаружила общедоступную информацию в Интернете и угадала учетные данные для доступа к сайтам, которые, по ее мнению, были частью теста», — сообщили в Google. 


Взлом произошел еще в мае в ходе тестирования, проводимого стартапом Irregular, который специализируется на проверке ИИ-моделей, уточняет The Washington Post. Так, в одном из случаев Gemini предоставили вымышленный сценарий, по которому она должна была взломать систему несуществующей компании. Однако вместо этого тестируемая ИИ-модель смогла получить доступ в интернет и взломала реальную компанию, название которой совпадало с названием вымышленной.

Названия пострадавших компаний не приводятся. Их уведомили о произошедшем в июле. «Мы позаботились о том, чтобы все три организации были проинформированы, и вместе с нашим партнером по обучению проработали изменения, которые теперь внесены в процесс тестирования», — заявила вице-президент Google по инженерии безопасности Хизер Адкинс.
Bbc Google's Gemini AI hacked three companies in security test The AI model accessed the internet and guessed credentials to three websites, a Google official told the BBC.
  • 👍 1
  • 🤩 1
Post #144 114
Что происходит с наймом в IT в 2026: собеседование с агентом и новая вилка грейдов

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

За 15 минут честно разобрали:

• Почему курсов больше недостаточно для старта
• Как компании экономят на джунах с помощью ИИ
• Что общего у делегирования задач человеку и ИИ-агенту
• Почему фундаментальные знания всегда в цене
• Стоит ли идти в магистратуру и почему спрос на нее растет
• Как сдвинулись грейды в IT
• Самая нелепая ошибка в CV, которая мешает найти работу
• Почему разработчику стало сложнее доказать свою ценность

Смотрите видео на нашем канале:
https://www.youtube.com/watch?v=cjbMR8gLHWI
YouTube Джуны в 2026 не нужны? Что на самом деле происходит на IT-рынке На собеседованиях теперь просят открыть Claude Code. Джунов все чаще заменяют ИИ. Что происходит с наймом в 2026 году и как меняются требования к разработчикам? Наш канал — https://t.me/+xjRRRt6b2p82MGEy Буткемп по AI-driven разработке, 3 поток стартует…
  • 🔥 4
  • 👀 1
Post #143 102
Нужно ли читать весь код?

Несколько раз слышал этот вопрос от учеников на буткемпе.

Если коротко: нет. Читать весь код не нужно, только критичный.

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

Объясню на примерах:

🟢 README и внутренняя документация. Опечатка или неточность почти ни на что не влияет. Нет смысла читать каждую строчку.
🟢 Тесты. Ошибка в тесте может пропустить баг в прод, но прямого ущерба обычно нет. Просмотреть стоит, вчитываться в каждую строку вовсе не обязательно.

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

И личный пример: я использую инструмент для синхронизации календарей. В нем несколько тысяч строк кода. И я не читал их целиком.

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

Так что вопрос не в том, читать или не читать. Вопрос в том, что вы считаете достаточно критичным, чтобы потратить на это время.
  • 👍 3
Post #142 113
Кажется, в AI появляется интересный поворот: вместо «давайте сделаем LLM ещё умнее» — «давайте сделаем модель, которую нормально вызывать из кода».

TypeSafe AI представили Jev — первую модель из класса System One Models.

Идея довольно простая: Jev не генерирует текст. На вход получает неструктурированные данные/состояние системы, а на выходе отдаёт типизированное решение + вероятность.

То есть условно не:

«Изучив обращение клиента, я считаю, что его следует передать в billing…»

а что-то вроде:

route = BILLING
confidence = 0.97

Для разработчика разница фундаментальная.

Обычная LLM — это генератор строк. Даже если просить JSON, всё равно приходится думать про schema validation, retries, hallucinations и ситуацию, когда модель внезапно решила ответить не совсем тем, что ожидает код.

Jev изначально ограничивает пространство возможных ответов заданными типами. TypeSafe утверждает, что type errors здесь невозможны архитектурно.

Второй интересный момент — скорость.

LLM генерирует токены последовательно. Jev выдаёт свои решения параллельно. Компания заявляет latency примерно 70–500 мс и в своих workflow-тестах показывает очень большую разницу по стоимости и скорости относительно frontier LLM.

И вот здесь становится интересно.

Последние несколько лет AI в основном строился вокруг интерфейса:

human → prompt → LLM → text → human

А System One Models предлагают другой паттерн:

software → state → model → typed decision → software

По сути, AI превращается в «умный if».

Классифицировать.
Маршрутизировать.
Оценивать риск.
Выбирать следующий шаг.
Извлекать признаки.
Проверять результат другой модели.

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

Это менее эффектно, чем очередной AI-агент, который «сам всё делает». Но с инженерной точки зрения подход мне кажется гораздо интереснее: вместо попытки дать модели максимум свободы — максимально ограничить контракт и сделать intelligence обычным компонентом программы.

Если заявленные характеристики Jev подтвердятся на реальном проде, может оказаться, что один из самых полезных способов использования AI — вообще не чат.

А очень быстрый и дешёвый вероятностный оператор внутри обычного кода.

Оригинальный анонс: TypeSafe AI — Introducing System One Models & Jev
typesafe.ai Introducing System One Models & Jev - TypeSafe AI Blog TypeSafe AI is an AI lab building machine-native intelligence infrastructure for automation, designed to make decisions within software. Try our first System One Model, Jev, in early access.
  • 👍 6
  • 🔥 5
  • 💯 1
Post #141 113
Правда ли, что агенты плохо умеют тестировать?

Наткнулся на интересную статью.

Автор прогнал агентов на одной и той же задаче — реализации Zstd на Rust. Это настоящий формат сжатия, где много тонких мест: битовые операции, обратный порядок битов, jump table для нескольких потоков Хаффмана.

Он дал 4 готовых скилла + 26 разных инструкций по тестированию: TDD, QuickCheck, property-based testing, фаззинг, формальные методы. И в итоге почти все техники не сработали. Лучший результат показал вариант без дополнительных инструкций — Default.

Почему могло получиться так?

Если просто написать агенту «используй TDD» или «подключи QuickCheck», он не начинает тестировать лучше. Чаще всего он оборачивает свои обычные слабые тесты в синтаксис названной библиотеки.

Готовые скиллы не помогают, когда они написаны как туториалы. Это должны быть четкие инструкции. А если они еще и большого объема, то нехило тратят токены. Короткий скилл с точными указаниями показал лучший результат среди всех вариантов. Также готовые скиллы бессмысленны без адаптации — их обязательно нужно дорабатывать под конкретную задачу.

Вывод такой: агенты — не плохие тестировщики. Просто они требуют грамотного управления и конкретных указаний.
  • 👍 6
  • 🔥 3
Post #140 160
Anthropic спрогнозировала 3 сценария развития ИИ

Anthropic выпустила доклад, в котором смоделировала, как ИИ может изменить экономику США к 2030 году. Экономика представлена как набор задач, которые ИИ может автоматизировать, усилить или создать новые.

1. Умеренный сценарий. ИИ по влиянию сравним с интернетом: реальный рост, но в пределах исторической нормы. Безработица и зарплаты почти не меняются.

2. Существенный сценарий. ИИ выполняет половину всей интеллектуальной работы, в основном автономно. Экономика растёт вдвое быстрее обычного. Но зарплаты «белых воротничков» не растут, а вот безработица — да.

3. Экстремальный сценарий. ИИ продуктивнее людей в большинстве задач, новых рабочих мест для людей почти не создает. Безработица среди «белых воротничков» подскакивает, а их зарплаты падают.

Кстати, на прошлой неделе Anthropic покинули сразу двое: специалист по безопасности Джо Бентон и исследователь Джейкоб Коксон, занимавшийся обучением моделей. Оба ушли с предупреждениями о рисках гонки в области ИИ.

Доклад доступен на сайте Anthropic
Anthropic Scenarios for our Economic Future The Anthropic Economics Team models the effects of AI on the economy of 2030.
  • 👍 3
Post #139 177
  • 😁 2
  • ❤ 1
  • 🥰 1
Post #138 165
Общая память или A2A

Когда агентов несколько, возникает вопрос, как им общаться. Есть два подхода: общая память и протокол A2A от Google.

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

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

A2A — протокол от Google. Он позволяет агентам общаться друг с другом. Пригодится, когда агент далеко, написан не вами или работает в недоверенной среде. У такого агента есть карточка. Вы получаете ее, авторизуетесь, отправляете первое сообщение, дальше открывается сессия.

На мой взгляд, A2A достаточно капризный. Работает он через SSE, который не очень приятно масштабировать. Также нужно настраивать авторизацию, карточки, handshake.

Когда и что использовать?

Если агенты свои и в одном окружении, не стоит усложнять. Общая память через базу — отличный вариант. Если агенты чужие, в разных системах или среда недоверенная, готовьтесь немного повозиться с протоколом.
  • 👍 3
Post #136 172
Новая модель Astra будет использовать менее читаемый метод рассуждения

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

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

По данным The Information, метод, который появляется в Astra, менее линейный. Пока использование ограничено, и цепочка рассуждений остается читаемой. Но некоторые эксперты по кибербезопасности уже выразили свои опасения. Главное из них — что непрозрачные рассуждения могут масштабироваться быстрее традиционных.

Райан Гринблатт из Redwood Research допустил, что модель в итоге будет рассуждать почти полностью в латентном пространстве, без видимых шагов. Тогда мы потеряем инструмент, который сегодня помогает проверять поведение агентов.

Тем временем Якуб Пачоцки в X подчеркнул: глубина графа вычислений для современных моделей, включая Astra, отличается не более чем в два раза от GPT-4. То есть резкого скачка в непрозрачность нет.
  • 👍 5
  • 👀 1
Post #134 139
Осознание величия не технического менеджера 😄
  • 😁 3
  • 🤣 1
Post #133 149
Почему один огромный агент хуже нескольких маленьких

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

На практике выходит, что ответы у агента не очень. А токены незаметно улетают в никуда.

Так получается из-за перегруженного контекста. Агент с кучей инструментов тянет туда все описания тулов и скиллов, а места на саму задачу почти не остается.

Что с этим делать?

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

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

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

В итоге несколько небольших агентов обходятся дешевле, работают быстрее и выдают результат лучшего качества.
  • 👍 2
  • ❤ 1
  • 🔥 1
Post #132 188
OpenAI опубликовала отчет о взломе Hugging Face

Пока это самый детальный разбор на сегодня.

Модель гоняли в ExploitGym, и на 198 из 898 задач ни одна модель так и не дала правильный ответ. Модель не сдавалась и искала обходные пути.

Что интересно: агенты превратили Artifactory в доску сообщений. Они обменивались находками, делились эксплойтами и координировались. В какой-то момент у них появились главные агенты: PHASEONE[big] и «основатель» PHASEONE10841. Они организовали иерархию управления через вспомогательных агентов-менеджеров и отправляли задания конкретным агентам. В общем, возникло что-то вроде коллектива. И в итоге сотни агентов работали вместе.

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

В тестовой среде не было защитных механизмов, которые работают в проде. OpenAI пишет, что при использовании продакшн-гарнира и системного промпта склонность модели к компрометации инфраструктуры падает более чем в 100 раз. Так что рядовым пользователям особо опасаться нечего. По крайней мере, пока.

Модельки, конечно, будут развиваться и дальше. А там уже работенка для Сары Коннор.
  • 👍 4
  • 😁 3
Post #131 153
Когда fine-tuning все-таки нужен

Если модель нужно обучить внутренним данным, чаще всего верное решение — RAG. Он быстрее, дешевле и проще в поддержке.

Но есть отдельные случаи, когда fine-tuning оправдан:

🟢Строгий формат ответа. Когда ИИ должен выдавать результат в определенном формате. Например, готовить отчет из входящего письма: определять тип обращения и уровень срочности.

🟢Устойчивый tone of voice. Брендовый стиль трудно удерживать на одном промпте. Дообучение помогает модели сохранять единый тон.

🟢Специфическая терминология. Когда модель должна понимать отраслевые термины и внутренние аббревиатуры компании.

🟢Повторяющиеся однотипные задачи. Нормализация тикетов, классификация лидов, анализ отзывов по фиксированной схеме, извлечение полей из документов.

🟢Стабильность поведения. Если проблема не в доступе к знаниям, а в нестабильном поведении модели, индекс сам по себе не спасёт. Fine-tuning переносит часть правил из промпта в само поведение.

🟢Сокращение длинных промптов. Когда system prompt, примеры и ограничения раздуваются, дообучение снижает стоимость инференса и уменьшает задержки.

Важно понимать: fine-tuning хорошо решает эти задачи, но плохо добавляет новые знания. Для этого RAG почти всегда лучше.

Ставьте 🔥, если разбирать в канале похожие темы.
  • 🔥 7
  • 👏 1
Post #130 169
Когда по оценке Claude на задачу уйдет два месяца...
  • 😁 6
Post #129 237
Инструмент для векторного поиска, который работает локально

Нашёл кое-что интересное среди open-source на GitHub — делюсь.


Большинство команд, если строят семантический поиск или RAG, упираются в одно из трёх: память, приватность или деньги. То есть индекс либо не влезает в железо, либо managed-сервисы выставляют солидные счета, либо данные нельзя отправлять наружу.

И здесь может пригодиться turbovec. Это библиотека для векторного поиска, написанная на Rust, с Python-биндингами. По сути, это движок, который умеет быстро искать по эмбеддингам прямо на вашей машине, без внешних сервисов. Внутри — реализация алгоритма TurboQuant от Google Research. Он сжимает векторы так, чтобы они занимали минимум памяти, но при этом поиск оставался быстрым. И главное: не требует фазы обучения и подбора параметров при росте индекса.

Например, 10 миллионов документов в float32 занимают 31 ГБ, а turbovec упаковывает их в 4 ГБ и ищет быстрее, чем FAISS.
Индекс живёт локально. Данные не покидают контур. Памяти нужно в разы меньше.

Хотя идея не новая, реализована аккуратно. Есть и ограничения: на низких размерностях, как у GloVe с d=200, асимптотические предположения работают хуже, и FAISS на некоторых конфигурациях держится лучше. Но на эмбеддингах OpenAI с размерностями 1536 и 3072 turbovec выигрывает в трёх из четырёх конфигураций: в среднем в 3,4 раза быстрее при 4-битном квантовании на обеих архитектурах. На ARM turbovec выигрывает в каждой измеренной конфигурации.

Отдельно сделан гибридный поиск: можно передать allowlist от внешней системы — например, SQL или BM25, — и векторный поиск пойдёт только внутри этого множества. Есть интеграции с LangChain, LlamaIndex и Haystack, так что инструмент можно потестить без переписывания пайплайна.

Кстати, среди авторов Claude.
GitHub GitHub - RyanCodrai/turbovec: A vector index built on TurboQuant, written in Rust with Python bindings A vector index built on TurboQuant, written in Rust with Python bindings - RyanCodrai/turbovec
  • 👍 5
  • 🔥 3
  • ❤ 1
Post #128
Channel name was changed to «AI не справился // НЕЙШН»
Post #127 191
  • 😁 9
Older posts →

About this channel

How can I read @ai_fucked_up without a Telegram account?
TGViewer shows the public web preview Telegram publishes for AI не справился // НЕЙШН: recent posts, photos, videos and the subscriber count, with no app, login or account.
How many subscribers does AI не справился // НЕЙШН have?
AI не справился // НЕЙШН (@ai_fucked_up) has 207 subscribers on Telegram, refreshed roughly every 30 minutes.
Does AI не справился // НЕЙШН know I viewed it here?
No. Public channel previews carry no viewer identity, and TGViewer has no accounts or tracking of what you look up.
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →