Kurgan-Telecom Ru | Информационные технологии

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

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

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

Так же известно, что от версии к версии в модели добавляются скрытые детерминированные механизмы (модель думает), улучшающие адекватность ответов. Соответственно,  чем «умнее» становятся модели, тем больше в них добавляется человеческого фактора. Хорошо это или плохо? Для коммерческого продвижения точно хорошо. В любом случае человеческая предвзятость может накладывать свой отпечаток на ответы ИИ.

Пищей для моделей служат различные источники, достоверность сведений из которых не гарантирована. С генерацией программного кода дело обстоит получше, но в любом случае ничего нового придумано ИИ не будет. Максимум, что может случиться, так это некоторое улучшение (вырождение) результатов, если обучение моделей будет выполняться на результатах других генераций признанных наиболее удачными.

В 2025–2026 годах компании массово переходят от простых чат-ботов к автономным ИИ-агентам. При этом агенты не просто отвечают, а выполняют реальные действия: работают с почтой, базами данных, API, кодом и даже запускают цепочки задач в мультиагентных системах.

Вместе с возможностями пришли новые риски. Классические средства защиты – WAF, DLP и даже первые поколения LLM Firewall оказались недостаточными. Появилось новое направление – Agent Runtime Security.

В этой статье разберём, почему так произошло, как эволюционировала защита ИИ систем и как с задачами справляется INFERA AI.Firewall, в котором уже реализованы ключевые элементы этой парадигмы.

В конце нулевых и начале десятых меня часто спрашивали о том, как это — иммигрировать в Европу. Именно, «как», а не «стоит ли». Абсолютное большинство наших соотечественников считало иммиграцию в страны Европы, Штаты, а иногда даже вообще почти в любую страну, несравненно лучшим выбором, нежели чем жизнь в России. Понятно, что недавние геополитические события сильно изменили тональность вопросов — причем в обе стороны, как «за», так и «против». Как для тех, так и для других сильно выросла страстность аргументации за собственную позицию.

TL;DR. Я выбирал Timeweb не из-за цены, а из-за «имени» и обещанной надёжности. За май–июнь 2026 года зона ams-1 (Амстердам, дата-центр Qupra) пережила шесть крупных аварий с суммарным окном недоступности около 46 часов — причём последняя авария на момент написания этих строк всё ещё не закрыта и идёт уже более 15 часов. Хостер на своём сайте обещает Tier III и аптайм 99,98 % — это 1 час 45 минут простоя в год. За два месяца факт превысил годовой лимит этого обещания примерно в 26 раз. Все цифры ниже — не мои домыслы и не «жалобы в чате», а сообщения из официального канала статусов самого Timeweb.

Я давно сознательно избегал трех бесячих тем: фронтир-моделей, автономных агентов ради самих агентов и разговоров про AI-native компании. Потому что вокруг них сейчас слишком много маркетинга и слишком мало инженерной конкретики.

Но после доклада AWS про команды в мире агентского ИИ стало понятно, что интересный вопрос тут не какая модель победит, а какая операционная модель переживет удешевление разработки и придумали ли уже что-то по делу. Статья перед тобой разбор тысяч публикаций про то что думают всяки MAANG о том какие команды в итоге получатся.

Асинхронность NIO и асинхронность Kotlin: попробуем разобраться какие идеи заложены и как совместно использовать то и другое.

Дисклеймер.
Пишу от своего имени свое непопулярное мнение. И да, возможно вы увидите здесь некую рекламу продукции. Конечно, я же в нее верю и вкладываю душу. Иначе бы работал над другим проектом.
Кто мы? Мы российский производитель автономных дронопортов «ЭРИ».

Кто я? Тот, кому этот продукт небезразличен. Тот кто готов рассказать про каждое его достижение, и каждое наше поражение.

Перейдем к самому интересному. Мы разработали принципиально новую станцию —Дронопорт Эри МИНИ 2.

40-60% времени современных QA-команд тратится на диагностику сбоев в тестах. Эта проблема настолько серьёзна, что сейчас активно разрабатываются практики сокращения размеров тестовых сюит, Майкрософт рекомендует при триаже не разбирать каждое падение по отдельности, а кое-кто советует «стохастический подход» к разбору ошибок, при котором команды не тратят время на разбор каждого падения.

Если всё больше голосов говорят нам о том, что разбирать падения вручную становится слишком дорого, стоит задуматься об автоматизации. В этой статье я возьму тестовую сюиту средних размеров, попробую вначале пройти по результатам руками, а потом применю простейшее средство автоматизации: группировку результатов.

«Сделайте нам AI-агента» — теперь это звучит как «сделайте кнопку». Проблема в том, что под одним словом скрываются три разные сущности: промпт, чат-бот и собственно агент. В статье — анатомия агента с кодом, пять способов сжечь бюджет и простой фильтр, чтобы понять, нужен ли вам агент вообще.

Привет Хабр! Мы команда бизнес‑анализа Группы MOEX, и сегодня хотим поделиться своим подходом как мы определяем эффективность нашей работы.

Показателями эффективности являются метрики.

Метрика — это число, которое показывает, как и кто работает. Это не описания, не мнения — только цифры, по которым можно понять: всё хорошо или нужно что‑то менять.

Для нашей команды, мы определили следующие критерии эффективности:

Когда сверху прилетает задачка запустить FinOps, чаще всего она звучит так, как будто речь идет про кнопку. Нажал - и косты порезались сами собой, инженеры в тот же миг стали гипер-ответственными, а финансы перестали дышать в затылок. Вот только никакой кнопки, само собой, нет. Есть только точка ноль - тот самый момент, когда ты сидишь с этой задачей и тупо не знаешь, с какой стороны вообще подходить к ее решению.

В этом цикле я хочу показать самую изнанку, самую мякотку как у вывернутого наружу ежика. Не теорию из методичек, а то, как оно выглядит изнутри: что надо делать, с кем встречаться, о чем и кого спрашивать, что собирать и почему первая же попытка посчитать косты скорее всего ни к чему толком не приведет. Но обо всем по порядку. 

Кстати, все это мы в свое время обсуждали (да и сейчас продолжаем) в канале Практики FinOps в Telegram. Там сидят те, кто проходил этот путь раньше, - иногда один вопрос в чате экономит неделю собственных экспериментов. Залетайте, если тоже на старте.

Я работаю в контекстной рекламе и аналитике пять лет. Когда популярное расширение xml-river перестало работать, у тысяч специалистов сломался привычный сбор семантики через KeyCollector. Я решила проблему локально: написала десктопную программу на PySide6, которая напрямую работала с новым официальным API Wordstat. Программа продавалась с пожизненной лицензией, а пользователи ходили в API под моим личным токеном. Всё работало отлично, пока клиентов не стало слишком много: общий лимит в 5000 запросов в сутки превратился в массовые ошибки 429 Too Many Requests. Стало ясно: модель с общим токеном доживает дни. В этом посте — технический разбор того, как я за одну неделю полностью переписала архитектуру, перевела парсер на SaaS-модель (FastAPI + SQLite) с независимыми квотами для каждого пользователя. С кодом, схемами и честной юнит-экономикой

Недавно мы с женой придумали небольшой совместный проект: она креативит, я прогаю. Сделав каркас в Codex, я завел чат на троих с Hermes Agent. Пошерил ему доступы и контекст, теперь моя пассия добавляет фичи и двигает пиксели голосовухами. Это сработало так круто, что я всунул Гермеса много куда — и не могу не поделиться этим с вами!

В этой статье я расскажу: что такое Hermes Agent, как я его использую и как сделать себе также.

Привет, Хабр! Меня зовут Ольга Турчина, я финансовый директор и руководитель продукта Аспро.Финансы. 10 лет помогаю собственникам разобраться в операционных финансах — нахожу, где деньги уходят внутри бизнеса.

За эти годы вижу один и тот же сценарий: выручка растет, прибыль в отчетах есть, а на счете пусто. Большинство ищут причины снаружи — падение спроса, курс, конкуренты. А деньги уходят внутри, в операционных процессах, которые никто не контролирует.

Разбираю пять таких мест.

В 2026-м собрать ПК с нуля – удовольствие на любителя: цены на память и комплектующие кусаются, и народ всё чаще поглядывает на вторичку. А там одни из самых ходовых позиций – Core i9-13900K, 14900K и их родня из i7. Ну, а что? Камни мощные, подешевевшие, так почему бы не взять? Вот только у этого поколения есть редкая для процессора беда: при штатной работе они умудрялись убивать себя сами – причем тем напряжением, которое по умолчанию сами же себе и запрашивали. И принести с Авито такой, уже наполовину деградировавший экземпляр, проще, чем кажется. Но обо всем по порядку.

Привет, Хабр! Меня зовут Никита Егоров, я продуктовый аналитик в Автозапчастях в Авито. Эта статья будет вовсе не про аналитику и не про большие массивы информации. Я расскажу о том, как, только придя в компанию, замотивировал коллег  на утренний забег, про покорение горных вершин и построение личного бренда внутри IT–гиганта.

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

Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.

← Четвёртая и пятая части

Это самый длинный пост всей серии, потому что он посвящён главной части этого проекта — всё вращается вокруг CPU.

Почему бы просто не взять готовый CPU?

Кто-то может заявить: зачем заморачиваться проектированием собственного CPU? Есть куча маленьких хорошо задокументированных процессоров и дешёвых микроконтроллеров, способных исполнять прошивку калькулятора. Zilog Z80 не так сложно реализовать на FPGA, и я в этом уже убедился (проект A-Z80, находящийся у меня на GitHub). Подойдёт и 6502. Маленький встраиваемый RISC тоже прекрасно справится с этой работой.

Отвечу честно: это было бы не так интересно, потому что подобное уже много раз делали. Но есть и другие (более удобные для меня) причины.

Наш калькулятор построен на BCD (двоично-десятичном коде),в котором каждый десятичный разряд хранится в отдельном 4-битном полубайте (ниббле). Это правильный выбор для калькулятора, и он определяет всё дальнейшее. Z80 (и другие стандартные CPU) работает на уровне байтов. Для индексации регистра мантиссы из 16 нибблов с ориентированным на байты процессором пришлось бы постоянно жонглировать сдвигами, масками и двумя нибблами на байт. На каждом шаге режимы адресации вступают в конфликт со схемой данных.

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

Представьте свою команду через пару лет после того, как все в ней дружно подсели на ИИ. CI зелёный. Покрытие почти сто процентов. Фичи выкатываются быстрее, чем раньше. А теперь подойдите к любому и попросите у доски объяснить, как вообще устроена система: где границы модулей, почему контракты именно такие, что рванёт, если потянуть вот за этот сервис. И окажется, что целиком этого не знает никто. Код есть, он работает, и его никто не понимает.

Самое удобное объяснение звучит так: значит, набрали слабых инженеров. Я хочу показать, что это объяснение неверное, и что за последние два года накопилось достаточно данных, чтобы говорить не про чьи-то личные провалы, а про свойство самой системы.

Демон cron знаком каждому, кто админит Linux. Он крутит бэкапы, чистит временные файлы и запускает скрипты, о которых все уже давно забыли. Однако многие не знают, что одна строка в crontab способна снести данные, забить диск, устроить форк-бомбу или открыть лазейку для хакера. Под катом я разберу, когда и как именно cron становится опасным, и какие команды помогут держать его в узде.