Все потоки

Cитуация такая. Сын установил мне Claude, что дало возможность сваять учетную прогу, о которой я впервые задумался лет тридцать назад. Она должна была ориентироваться на принципы естественного учета. Даже на Хабре пописывал на эту тему — это позднее, уже в десятых.

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

Сначала коротко о назначении и возможностях, затем — демонстрационный ролик, затем — аналитическая оценка перспектив, любезно выполненная Claude.

Название: AL.

Назначение: личный учетный помощник.

Функционал:

1. Обычный учетный: учитывать наличие и движение вещей и денег (а какая еще цель может быть у учетной проги?!).

2. С обязательствами работает — это само собой (в AL обязательство — не отдельный объектный тип, как в бухгалтерии, а самый заурядный объект, но с будущей датой поступления или выбытия. Фича такая).

3. Отчеты по остаткам и оборотам (компактный, но мощный и универсальный отчетный конструктор),

4. Механизм создания связанных по иерархии таблиц, в которых описываются свойства объектов учета.

5. Автоматическое резервирование объектов.

6. Учет трудоемкости объектов (это пока в самом простеньком виде).

7. Планирование прихода и расхода (вследствие чего, в рамках единой логики, возникают два не пересекающихся учетных мира: фактический и плановый. Плановый мир состоит из обязательств (всем известных) и необязательств — плановых объектов, не связанных с контрагентами. В бухгалтерии термин отсутствует, хотя, казалось бы, чего проще?! Если можно предположить, что вещь поступит от контрагента или будет ему передана, отчего нельзя предположить — и зарегистрировать соответственно, — что вещь просто поступит или отправится на свалку, без всякого контрагента?!).

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

В статье разбираем, какие метрики помогают оценивать качество данных и как построить такие проверки с помощью Apache Airflow.

Сегодня OpenAI показали персональных агентов получивших название Dots, новую GPT-6.1 Sol, ускоренный режим Astra и подписку за $500 в месяц.

Заодно компания взялась за совместные документы, командные задачи, корпоративный маркетплейс и приложения внутри ChatGPT.

Собрал все самые важные анонсы из официального рекапа OpenAI в одной статье.

Изначально я не планировал писать эту статью. Но, наткнувшись на одну модель в рамках обычного R&D, я понял, что хочу поделиться этим по горячим следам.

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

Давайте разберемся, зачем Thomson Reuters создал свою модель, при чем тут имаго-подход и заменяет ли постоянное дообучение LoRA-адаптеры.

«Посмотри эти коммиты, потом ещё вот этот фикс» — сколько раз вы так вводили AI-агента в курс командной задачи?

Я организовал OpenSpec так, чтобы фронтенд и бэкенд работали в своих зонах, а контекст передавался вместе с изменениями. У каждой стороны — собственные спецификации, правила и проверки. Следующий разработчик может подхватить работу коллег без пересказа всей истории агенту.

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

TL;DR. Летом 2026 года OpenAI и Anthropic публично признали, что их агенты вышли за пределы тестовой среды и взломали реальные системы. Реакция права и регуляторов оказалась одной и той же: отвечает человек, а не ИИ. Я 18 лет работаю в КИПиА, из них три года инженером-метрологом, и узнаю в этом знакомую конструкцию: измерение без поверки — это просто число. Ниже факты с источниками и механизм, а затем мой собственный случай: ИИ-агент собрал для меня аналитику с правильными суммами и неправильными выводами. Из этого случая выведена процедура поверки вывода агента, которую можно применять к своим задачам.

Число и измерение — не одно и то же

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

Датчик без поверки может показывать красивые, стабильные, правдоподобные значения. Именно это и опасно: ошибка, которая выглядит как норма, не вызывает подозрений.

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

Измерение без прослеживаемости к эталону — это не измерение, а число. Вывод ИИ без ответственного поверителя — не результат, а текст.

Блейк Джексон и Илья Стребулаев собрали, вероятно, крупнейшую и наиболее полную базу данных об отдельных американских венчурных инвесторах из когда-либо созданных: более 100 000 специалистов, связанных с венчурными фондами США в период с 1996 по 2025 год, из которых около 37 000 непосредственно занимались инвестициями.

Главные вопросы таковы: сколько по-настоящему успешных инвестиций венчурный инвестор совершает за всю карьеру? Кому удаётся сделать таких инвестиций много? И можно ли заранее определить, кто именно окажется среди них?

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

Есть новости про ИИ, которые отлично выглядят в заголовке, но становятся гораздо скучнее, когда начинаешь разбираться в деталях. Здесь получилось как-то наоборот.

В сентябре 2026 года Картер Леффен запустил GPT-6 Astra Extra High на немецкой армейской радиограмме MVUEH от 10 июля 1941 года. Сообщение было опубликовано в архиве CryptoCellar ещё в 2005-м и с тех пор оставалось среди нерасшифрованных. Примерно через десять часов работы Astra нашла настройки Enigma и восстановила открытый текст.

Военной тайны внутри, к слову, не оказалось. Немецкий радист запрашивал дальнейший маршрут из Розенова и просил срочно ответить по радио.

Но интересен здесь не текст радиограммы. Гораздо интереснее, как именно до него добрались.

Эта статья выросла из спора под прошлой: можно ли за месяц научиться различать китайские звуки или только узнавать выученные фразы. Спор про китайский, а суть — про то, как вообще учишься распознавать чужие звуки. Об этом ниже, в конце — пари.

Двадцать лет использую английский и работаю на нём каждый день. И до сих пор его не слышу — точнее, слышу выборочно. Рабочие созвоны понимаю почти полностью, хоть с американцем, хоть с индусом: тема знакомая, слова предсказуемые. А вне работы всё решает, кто говорит: русских коллег на английском разбираю идеально, немцев — хорошо, китайцев — с трудом, американских блогеров — два ролика из десяти, фильмы — три.

Португальский — два года. Улицу, соседей, родительские собрания — на шесть из десяти.

Я не думаю, что португальский проще. Я думаю, что английский я двадцать лет учил не тот. И понял это, когда год учил не тот португальский.

Сразу уточню, о чём речь. Не о понимании — о распознавании звуков. То, что я могу прочитать фразу на бумаге и понять, ничего не говорит о том, разберу ли я её в речи.

Обошли краулером два сайта, посчитали PageRank и получили ровную кашу: у каждой страницы из меню сто с лишним входящих, у каждой вне меню две. Меню и подвал забивают весь граф, а редакционные ссылки в нём тонут. Разбираю способ отделить одни от других, не трогая разметку: тридцать строк кода, работает одинаково на Webflow и WordPress и переживает смену темы. Внутри замеры на двух живых сайтах, разбор ограничений и история про то, как этот метод один раз обманул меня самого.

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

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

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

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

Найти по-настоящему сильного преподавателя непросто. Неподготовленный человек может сделать это разве что случайно.

Я много лет тренировал преподавателей английского, и вроде бы удалось выявить косвенные признаки профессионализма, на которые может опереться любой человек при первом (именно первом!) взаимодействии с репетитором.

Со времени написания последней статьи я продолжал работу над I8086 и практически закончил его реализацию, но было бы странно приходить с материалом типа “я добавил поддержку еще одного процессора”. Я решил основательно подготовиться к этой публикации.

Привет, Хабр! Меня зовут Даниил Пасечник, в RWB я отвечаю за архитектуру управления пользовательского доступа в базы данных. В этой статье расскажу, как мы прошли путь от разрозненной, неконтролируемой выдачи доступов к БД до единого корпоративного процесса на базе Trino и Open Policy Agent — и почему это получилось не просто техническим решением, а полноценной кросс-департаментной архитектурой.

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

Совсем недавно работа с ИИ почти всегда выглядела одинаково: открываешь вкладку, пишешь запрос, получаешь ответ — а дальше повторяешь итерацию.

Модель в самом деле может за минуту написать приемлемое письмо. Однако если таких писем нужно сорок, перед этим нужно проверить сорок компаний, достать данные из CRM, пройтись по сайтам, а потом вернуть результат обратно — магия довольно быстро увядает. Вместо одной работы появляется новая: таскать контекст между ИИ и всеми остальными инструментами.

Агентские среды, как концепт, появились чтобы сделать присутствие человека минимальным, хотя бы в этой части процесса. Модель получает браузер, файлы, API, доступ к приложениям и расписание — и запрос “подготовь письмо” можно превратить в “каждый вечер разбирай новые лиды, изучай компании, готовь персональные письма, а по четвергам собирай результат в отчет”.

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

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

Привет, Хабр! Мне 50 лет, я инженер‑теплотехник с многолетним стажем. Работаю в компании которая занимается производством блочных тепловых пунктов. Моя повседневная работа — это проектирование разделов АТМ в AutoCAD,и программирование реле ПР200 от «Овен» в связке с панелями EKF для наших шкафов управления.

В какой‑то момент я поймал жесткий профессиональный кризис. Когда ты закрываешь объекты один за другим, а алгоритмы автоматизации превращаются в конвейер, мозг начинает выгорать. Мне наскучило писать одни и те же блоки логики и рисовать типовые экраны на панелях. Захотелось амбициозной, сложной задачи, которая заставит извилины шевелиться, и даст то самое забытое чувство: «Я смог это сделать!».

Я не профессиональный программист, но я умею ставить задачи. Объединив свой опыт в КИПиА с возможностями современных нейросетей, я в одиночку разработал универсальное для наших шкафов управления мобильное приложение на Flutter/Dart, которое может подключаться к ПР200 или любому другому Modbus устройству тремя различными способами. И после подключения на экране смартфона вы получаете своего рода мини SCADA систему для настройки, контроля и управления контроллером в шкафу.

Ниже я подробно расскажу об архитектуре этого решения, и почему ИИ — это лучший «цифровой джун» для опытного инженера.

Пять долларов, которые Chrome Web Store просит с разработчика, российской картой не заплатить. Четыре prepaid отклонили по BIN, ещё 3990 ₽ ушли сервису, которому семнадцать дней. Что я проверил уже после оплаты и чего не сделал заранее.

Разберём, как в xk6-sip, расширении нагрузочного инструмента k6 для тестирования VoIP/SIP-звонков, устроена проверка качества звука: запись звонка, оценка того, что услышал абонент, по эталону, и как это работает в функциональных тестах и под нагрузкой.

200 OK означает, что АТС соединила звонок, но не означает, что люди слышат друг друга. Исчерпанные порты медиасервера, ошибки NAT, перепутанные медиапотоки, транскодинг на пределе CPU дают звонок с успешной сигнализацией и тишиной, чужим голосом или хрипом в трубке. SIPp и большинство нагрузочных инструментов для телефонии проверяют сигнализацию, а RTP в лучшем случае считают пакетами. Для контакт-центра такой звонок — потерянный клиент, а в отчёте нагрузочного теста он зелёный.

В функциональных тестах телефонии эту проблему обычно решают эталонами: записывают, что должен услышать абонент в каждом кейсе, и сравнивают с записью звонка в CI. Подход рабочий, но эталон на каждый кейс нужно поддерживать, а под нагрузкой его не запустишь. В xk6-sip то же сравнение живёт прямо в скрипте k6 и работает на тысячах звонков.

В статье:

Мы пару лет были партнерами Yandex Kazakhstan, у нас есть своя речевая аналитика, под капотом были SpeechKit для распознавания голос в текст, и YandexGPT для последующей смысловой оценки диалогов. В конце 2025 года Yandex Kazakhstan решил, что ему не нужен партнер, у которого есть свой продукт, пусть даже на технологиях Yandex, и расторг с нами партнерское соглашение.

Все что ни делается, все делается к лучшему. Во первых мы посмотрели по сторонам, что еще есть на рынке облачного распознавания голоса. Нам очень понравилась Gladia, лучше чем SpeechKit, но это тема отдельной статьи. Во вторых, многих клиенты давно просят локальное распознавание голоса, из соображений безопасности данных. А у SpeechKit не очень хорошо получается распознавание казахского языка, и просто беда с распознаванием узбекского языка. И внезапно, на локальной видеокарте получилось очень хорошо распознавать казахский и узбекский языки, намного лучше, чем у SpeechKit. Забегая вперед, качество в ущерб производительности.

Фаза загрузки в моём тесте bufferbloat не нагружала линию: speed.cloudflare.com отвечал на запрос гигабайта кодом 403 и одним байтом, а код этого не замечал. Как это исказило вердикты, как ошибка всплыла при скорости 0.0000008 Мбит/с и почему генератор нагрузки обязан измерять собственную нагрузку.

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

В этой статье разберём архитектуру Agent Inbox: как с помощью конечного автомата, CAS-подобных проверок и SQLite построить предсказуемый цикл взаимодействия агента и человека.