Множество предсказаний о журналистике в 2026 году https://www.niemanlab.org/collection/predictions-2026/ на сайте Nieman Lab

Многое про технологии и ИИ, есть даже про API для новостей. Для дата журналистов может быть полезным.

#thoughts #readings #journalism

Рассеянные мысли про разное:
1. В продолжение когнитивных искажений или искажений восприятия в наблюдениях последнего времени часто встречаю ещё два случая:
- декларативизация всего что возможно, иногда в форме YAML'ификации, когда декларативное описание (в сформе структурированного описания конфигурации) кажется панацеей для всего. Панацеей оно, конечно, не является и даже вызывает раздражение у многих разработчиков, но становится удобным при использовании ИИ агентов которые как раз такое декларативное описание понимают очень неплохо.
- маркдаунизация всего и вся, ловлю себя на том что стало неудобно писать тексты в Word'е, совсем неудобно, все время хочется использовать синтаксис маркдауна. Кроме того для скармливания объектов ИИ также часто преобразование в Markdown кажется более логичным чем во что-то другое.
2. По прежнему жизненно не хватает продвинутых инструментов управления контактами, такое ощущение что они вымирают и ни один из крупнейших сервисов не дает удобного API для их обогащения. Например, для управления контактами в Google нужно оттанцевать много с бубном чтобы добавить/изменить контакт автоматически. Когда у тебя пара сотен контактов - это не проблема, когда несколько тысяч - уже ощутимо.

#thoughts

В продолжение рефлексии про применение ИИ агентов в разработке. Мои личные ощущения от применения для различных задач.

Документирование. Почти на 100% закрывается с помощью ИИ агентов, при условии что сам код ясно написан и в коде документация присутствует (в Python это обязательные docstrings). Как простая документация так и сложная генерируется без излишних сложностей, но как и код её необходимо тестировать промптами в условном стиле "проверь что все примеры упомянутые в документации являются рабочими" (в реальной работе немного сложнее, но и так можно).

Тестирование. Около 90-100% тестов кода могут генерироваться автоматически, остальное с некоторой помощью. Закрывает практически все общепонятные ошибки связанные с особенностью языка и его стилистики. не закрывают какую-либо сложную логику работы с не самыми очевидными продуктами, устройствами, интеграцией и тд.

Исправление ошибок. По ощущениям эффективности уже в районе 50-80% (до 8 из 10 задач выполняются сразу правильно, без необходимости корректироки). Практически все задачи линтинга кода и большая часть задач исправления ошибок по итогам неудачных тестов. Наиболее часто несрабатывающие исправления касаются взаимодействия с другими сервисами, серверами, параллельно разрабатываемыми продуктами.

Генерация кода. Варьируется от 40% до 70% эффективности, чем более комплексная задача тем хуже результат в виде кода. Простые задачи умеют хорошо делать уже почти все ИИ агенты, сложные часто приводят к переусложненному коду. Например, в качестве теста я делал REST API поверх написанного на Python SDK. Cursor при его реализации начал ваять сложный промежуточный код для обработки данных и преобразования типов хотя все то же самое можно было бы сделать значительно проще простыми исправлениями в оригинальном SDK. Вот эта вот контекстность в решении проблем это особенность ИИ агентов. Они пока не предполагают что решения проблем могут быть за пределами рассматриваемой ими кодовой базы.

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

Разработка дата продуктов (декларативное создание баз данных). Это то что я рассказывал ранее про то что справочные данные можно создавать в виде множества YAML файлов которые расширять и собирать в наборы данных с помощью ИИ агентов. Здесь эффективность весьма вариативна. Чем больше гранулярности в задаче, тем она выше, но исправлять результаты и расширять их нужно практически всего. Однако и это снижает трудоемкость создания датасетов в десяток раз, не меньше.

#thoughts #ai

У меня есть довольно давняя отложенная нерабочая задача - это извлечь с каталога музейного фонда РФ (goskatalog.ru) материалы по армянскому культурному наследию для чего я когда-то выгружал с портала данных Минкультуры РФ битый датасет этого реестра и преобразовывал 88ГБ текстовый файл в 2.7ГБ файл Parquet с 31.7 записями о культурных объектах. А также есть примерно 100 регулярных выражений позволяющих найти записи в которых есть прямое или косвенное упоминание Армении или армянской культуры.

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

А теперь о подходах как такую задачу можно решить.

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

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

Неэкономное продвинутое программирование. Обращаешь внимание что записи в данных не зависят друг от друга и находишь компьютер с большим объемом памяти и множеством ядер или арендуешь дорогой облачный сервер, разрезаешь оригинальный файл с данными на 100 по 370 тысяч записей каждый и запускаешь их обработку параллельно по числу доступных ядер

Экономное хардкорное программирование. Обращаешь внимание что регулярные выражения - это медленно почти всегда и на то что не все поля в оригинальных данных нужны. Оптимизируешь и пересобираешь оригинальный файл с данными так чтобы он содержал только id записи и поля с нужными текстами, переписываешь регулярные выражения на pyparsing или разворачиваешь их в текст для полного мэтчинга и, конечно, тоже разрезаешь файл с данными на 100 (или сколько нужно) и параллельно запускаешь обработку не обязательно на продвинутом железе. Думаешь о том не переписать ли все это на Rust

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

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

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

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

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

#thoughts #programming #dataengineering

В продолжение истории про документы выложенные Минюстом США и в которых замазанный текст легко распознается я скажу вам что совершенно не удивлен и косяков госорганов и корпоратов в работе с документами и данными я знаю много, хотя и рассказывать про большую часть не могу и не хочу потому что не чувствую своей принадлежности к рынкам инфобеза и OSINT. Расскажу лишь некоторые примеры не называя имен

1. Скрытые, но доступные данные в недокументированном API
Госорган создает общедоступный портал с некоторой информацией и портал построен по уже классической трехзвенной структуре: База данных -> Слой API -> Веб интерфейс. При этом все ограничения в доступе к данным делаются только на уровне веб интерфейса, а через API вполне можно собирать записи имеющие статус "удаленные" или "черновики". Ситуация вообще не редкая и возникает от недостатка квалификации постановщика задачи, разработчиков и недостаточного тестирования

2. Скрытые данные в общедоступных материалах
Многие форматы публикации текстов, таблиц и изображений имеют свои особенности позволяющие как скрывать часть содержания так и "раскрывать" его. Пример с закрашиванием PDF файлов всем хорошо известен, а есть, к примеру, случаи когда публикуются Excel файлы со скрытыми вкладками, частенько когда публикуют статистику ее рассчитывают на более детальных первичных данных в другой вкладке, а потом эту вкладку скрывают, а не удаляют. Так чувствительные данные внутри Excel файлов становятся общедоступными. Есть и другие случаи когда одни файлы MS Office погружают в другие, а когда запускают процесс удаления метаданных он вырезает метаданные из основного контейнера, но не удаляет их из внедренных файлов. И так далее, это только то что совсем на поверхности

3. Доступное API стандартизированного ПО
Организация выбирает стандартизированное ПО для сайта, а у этого стандартизированного ПО (CMS) есть какое-то количество опять же стандартно общедоступных API о которых они могут и не подозревать. Я привожу часто в пример WordPress у которого есть открытые эндпоинты дающие возможность находить документы ссылок на которые может не быть на сайте, но сами файлы остаются. Например, если кто-то загружает документ в WordPress и потом делиться на него с кем-то по прямой ссылке, то даже если на страницах сайта этого документа нет, то в API он доступен. WordPress - это пример, кроме него есть немало других CMS и веб фреймворков имеющих такую особенность
—
Насмотревшись всего этого в больших количествах я совершенно не удивляюсь когда вижу как в очередной раз кто-то попадается на такой лаже как "затереть текст в PDF файле", думаю что еще не раз такое будет.

А я про такое пишу пореже потому что лично мне открытые данные и дата инженерия куда интереснее, кроме того рассказывая какой-либо кейс с такими утечками данных всегда велика вероятность что канал утечки исчезнет;)

#thoughts #osint #data #privacy

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

Тем не менее, у ИИ в госзакупках есть множество применений, я обозначу лишь некоторые:

1. Автоматизация контроля по "красным флажкам"
Это самое очевидное и активно внедряется во многих странах, за последний месяц я читал о внедрениях такой практики в Чили и в Албании, но уверен что делают такое многие и много где. Можно провести быстрое исследование и систематизировать эту практику, однако в её основе вполне понятная система флажков по которым закупки/контракты определяются по степеням риска. ИИ тут малополезен в части классификации закупки потому что ничего сложного в "складывании флажков" и определении баллов риска нет. Но ИИ может помочь в автоматизации идентификации флагов когда признаки риска заложены внутри текстов документов. Собственно этот анализ текстов и есть главная возможность применения резко снижающая стоимость автоматизации контроля. Все органы внутреннего и внешнего аудита уже не могут говорить "мы же не можем проконтролировать всё". Теперь можете, этот аргумент более не релевантен. Едем дальше

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

3. Прогнозирование результатов торгов
Это вам не прогнозирование инфляции или погоды на неделю, это оценка вероятности и суммы снижения цены потенциального победителя на торгах. Вообще это реалистично и без ИИ, но, как бы это объяснить не впадая в ересь... Прогнозирование результатов очень похоже и опирается на те же данные что и контроль "красных флажков" прото результаты развернуты в другую сторону. Этот механизм также определяет заточенность закупки под конкретного поставщика, только применение другое. Оно может применяться поставщиками для оценки своих шансов (и продумывания как эти шансы увеличить).

4. Оценка рисков поставщиков и их кредиторов
Это решение задач для юристов и специалистов по оценкам рисков, но через legaltech, что включает в себя совокупный анализ НПА, документов закупки, контракта, юридической практики и тд. Автоматизирует работу юристов поставщиков, их контрагентов и кредиторов которые оценивают свои риски рассматривать договора по контрактам.
—
Отдельная история во всем что касается антикоррупционного трека, я бы его рассматривал отдельно потому что он включает существенную работу по доступу ИИ агентов к закрытым источникам данных (реестры конечных бенефициаров, данные о счетах в других странах, чрезмерные траты госслужащих и тд.). В данном случае госзакупки лишь одна из областей возможой коррупции, но антикоррупционные ИИ - это более универсальный инструмент контроля.
—

Я предположу что многие из этих инструментов или их части будут постепенно появляться в ближайшие годы.

#thoughts #ai #procurement

По итогам могу сказать что если Google сменит ценовую политику для корпоративного применения Antigravity (сейчас она 183.6 евро за месяц) или если его конкуренты прокачают свои решения для ещё большей эффективности, то работу над кодом это ускорят не а 2-3 раза, а в 10-30 раз.

Разработка любого внутреннего инструмента или конечного приложения теперь должна быть устроена иначе. На начальной стадии обязательно нужно писать текст видения результата который должен включать:
1. Описание того что создается
2. Описание результатов включая критерии качества:
- измеряемые индикаторы качества (в данном случае FAR/FRR)
- сравнение результатов с существующими аналогами если они есть
3. Гипотезы
4. Правила управления зависимостями
5. Правила организации кода, репозитория и автоматического покрытия тестами и документирования

Частично это вписывается в логику руководства ИИ агента в AGENTS.md или GEMINI.md, но лишь частично, скорее всего всё это необходимо оформлять во внутренние руководства по организации разработки с использованием ИИ агентов.

#opensource #ai #aiagents #coding #thoughts #devnotes

(Часть вторая)

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

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

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

У меня есть живой пример подобного когда я давно откладывал задачу получения статистики из Статбанка Армении (statbank.armstat.am) из-за того что у них было поломано API и древняя версия ПО на котором он сделан. Развилка была в том чтобы:
a) Попросить у них данные (ждать пришлось бы долго и это не системное решение)
б) Заплатить фрилансеру написать парсер
в) Сделать парсер за пару часов с помощью ИИ агента

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

Условно зачем убеждать, к примеру, Пр-во Армении публиковать данные если мы и так их соберем и опубликуем на opendata.am ? Шутка, убеждать конечно же надо, но думаю что идея ясна.
—

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

#thoughts #openness #data #opendata #openaccess

Число вопросов в StackOverflow падает уже несколько лет и сократилось в несколько раз. В декабре 2024 года их было 18029, а в декабре 2025 года их всего лишь 3862 - итого сокращение в 4.6x раз

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

Можно сказать что проходит, возможно уже прошла, целая эпоха.

#ai #programming #thoughts

Обычно я подвожу личные итоги года не в под Новый год, а под 6-е января, в свой день рождения. Итоги эти практически все связаны с профессиональной работой, а не с чем-то личным, и в этом году они созвучны многому что я слышу от других в ИТ.

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

Похожим образом примерно 20 лет назад я уходил из роли технического архитектора в системном интеграторе в создание собственной компании через восстановления знаний в Python и создание первого стартапа используя самую раннюю версию Django и MySQL для анализа госзакупок. Фактически за год я тогда восстановил хард скиллы.

Зато что я могу сказать точно что наконец-то чувствую себя восстановившимся после COVID'а. Первые 2 года после него дались мне, честно говоря, довольно тяжело и только к 2024 я уже более менее нормально начал себя чувствовать, а в 2025 году уже чувствую себя достаточно живым чтобы ощущать что мир меняется слишком быстро чтобы позволить себе отставать.

#thoughts #personal

Хороший обзор Eight Software Markets AI That Will Transform Differently того как изменится рынок программного обеспечения в ближайшее время под воздействием развития ИИ инструментов. Из 8 ИТ рынка по настоящему радоваться могут исследователи, для них открывается бесконечный новый мир быстрого создания ПО и кода под свои задачи.

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

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

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

Можно представить, на выбор, укоренившихся вендоров ПО в некоторых отраслях и спокойно имевших свою долю рынка и неспешно на нем живших, а вдруг окажется что то что они делали пару десятилетий можно воспроизвести за 6 месяцев? за 3 месяца?

Некоторые крупные "столпы рынка" могут внезапно попадать, а суды вокруг воспроизведения API станут куда более массовыми чем сейчас.

#ai #thoughts #itmarket

Я довольно много писал про разные форматы файлов в дата инженерии и не только, с одной стороны это кажется очень внутренне-технической темой, неочевидной для тех кто не работает с данными постоянно, с другой стороны в обзоре от Andy Pavlov про СУБД за 2025 год активная конкуренция форматов явно упоминается. Потому что (внезапно!) оказалось что то как ты хранишь данные и то как хранят данные кто-то ещё и которые тебе необходимо использовать может быть как очень удобно и практично, так и создавать ничем не обоснованные дополнительные издержки.

Я привожу в пример как часто на порталах открытых данных публикуют CSV или XML файлы внутри ZIP архивов в формате: один файл - один архив. Но данные/файлы внутри ZIP архивов не приспособлены (без шаманства) для потоковой обработки. Их надо вначале распаковать куда-то как временные файлы, а потом уже обрабатывать и временные файлы удалять. Если файлы небольшие то и ладно, а если это десятки и сотни гигабайт и таких задач много, то возникает вопрос: А отчего же так? Это решается распространением датасетов не в виде ZIP архивов, а сжатием из GZip, LZMA, Zstandard, LZ4 и тд., способами и форматами сжатых данных изначально приспособленных под потоковую обработку. Собственно под такие форматы я делал iterabledata, библиотеку для Python. Она про то чтобы условно любой файл с таблицами или объектами можно было бы перебирать как это принято в Python в csv.DictReader. Последовательный перебор с возвращанием каждой записи как словаря (dict).

Но это лишь один уровень оптимизации, далее вопрос в выборочной обработке данных. Почему в какой-то момент так выстрелил довольно старый формат Parquet? Помимо хорошей компресии и возможности быстрого чтения данных он ещё и дает возможность выборочного чтения и фильтрации данных. К примеру, в отношении XML файлов это уже не работает, в отношении JSON, с большими ограничениями (для JSONl да, в остальных случаях нет) и так далее. А ещё есть огромное число форматов имеющих предметное и отраслевое применение где всё что можно - это, либо считывать их в память целиком, или перебирать содержание по каждой записи.

Вот примеры таких форматов: WARC (файлы веб архивов), PCAP (файлы перехвата сетевого трафика), SAS (файлы статпакета SAS), и еще много что: BSON, KML, GML, XLS, ODS и так далее. Реально огромное число форматов не поддаются фильтрации без загрузки в память или не через фильтрацию при тотальном переборе.

Поэтому когда доходит до их обработки, приходится преобразовывать их полностью или частично в parquet. К примеру, для WARC файлов я всегда их преобразую в один или несколько parquet файлов с метаданными, а оригинальные файлы рассматриваю как контейнеры для контента. И это я не сам придумал, а подсмотрел когда-то у Common Crawl, они поступают аналогично поскольку без этой процедуры собирать статистику сложно, надо перелопачивать каждый WARC файл, а это гигабайты-терабайты-петабайты.

Однако и сам формат Parquet'а неидеален и об этом регулярно пишут в разных местах и появляются такие форматы как Lance, Vortex, Nimble, Vortex, FastLanes и другие. Пока они довольно редки в открытом доступе, но постепенно проявляются. Впрочем parquet оказался достаточно эффективным чтобы эта замена длилась ещё какое-то количество леь

А вот чтобы я бы предсказал так то что грядет тренд на parquet'изацию данных, когда просто сильно удобнее распространять их в структурированном подобным образом виде. Возможно через рассмотрения parquet файлов как контейнеры, а возможно как файлы-сателлиты с метаданным к файлам контейнерам. К примеру, можно вполне заменить VCF файлы (генетика) на Parquet или файлы LDIF (директории пользователей LDAP) на Parquet или файлы KML и GML (геоданные) и тд.

#thoughts #data #dataengineering #fileformats

Чем следователь (дознаватель) отличается от археолога ? Археолог копает чтобы поместить результаты в музей/архив, а следователь чтобы найти улики преступления. Но существенная часть их работы пересекается, оба копаются в земле, инвентаризируют и изучают результаты. Некоторые инструменты (лопаты, щётки) практически идентичные.

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

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

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

И там и там все сохраняется в базы с метаданными оформленным по своим правилам. Тоже пересекающиеся по логике и содержанию.

Удивительное дело, так почему не дознавателей не учат на архивистов, а архивистов на дознавателей? 🙈

Впрочем на цифровых архивистов вообще мало где учат, в России точно нет, вообще это только в ряде стран такая явная специализация есть. А цифровые дознаватели не везде сформировались как явная профессия и чаще совмещается или декларируется как киберследователь (ИТ-детектив) и в компаниях по кибербезопасности их больше чем в правоохранительных органах (а может быть и нет).

#thoughts

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

Важный акцент там на стадии планирования и вопросам к ассистенту до реализации фич или исправления багов.

А я бы добавил к этому следующее:
1. Планирование через OpenSpec или его аналоги. Очень хорошо структурирует процесс проектирования и коммуникации с ИИ агентом. Для сложного и унаследованного кода - это просто необходимо. В принципе разделять планирование и реализацию, на стадии планирования не меняется код, а результаты - спеки и планы.
2. Cursor и аналогичные инструменты (Antigravity, Copilot и тд.) могут выполнять роль инструментов исследовательской поддержки и аналитики. Например, формируz отчеты по конкурентам, проектируя инструменты бенчмарков с ними, подготовка аналитики по разным функциям, проектирование верхнеуровневой архитектуры и тд.
3. ИИ ассистент - это не только объект проверки (а не кривой ли код он написал?), но и сам является контуром контроля качества. Поэтому на каждой итерации внедрения фич необходим контур создания и проверки тестов, линтинга кода, обновления документации и тд. Это частично решается уже сейчас на стадиях планирования и спеков, но опыт показывает что явное указание этих обязательных проверок дает больше гарантии что код будет не поломан и документация будет актуальной.
4. Инструменты для разработки вполне способны не только писать код, но и писать документы. Подход такой же может быть как к репозиториям кода с использованием спецификаций, планирования и тд. Иначе говоря при проектировании больших ИТ продуктов можно создать отдельный репозиторий с архитектурой продуктов и от него создавать все остальные. Например, если надо условно с нуля сделать продукт у которого есть фронтэнд, бэкэнд, REST API, SDK, интеграционные модули и тд., то вместо того чтобы все засовывать в один репозиторий или сразу разбивать на множество, имеет смысл собрать архитектурный репозиторий с документами.

#ai #coding #thoughts #readings

Разные мысли вслух:
1. Термин "большие данные" в 2026 году выглядит анахронизмом, а экономика больших данных особенно. Когда слышу его от кого-либо то вот прямо таки ощущаю что человек находится вне контекста и, либо не понимает предметной области (увы), либо довольно долго был от нее оторван. Условно нет никакой "экономики больших данных", есть экономика данных, но и она, условно, слепляется с ИИ стартапами и ИИ экономикой. В этом есть странное смешение хайпа, реальности и страха потому что это гораздо большие изменения цифровых экосистем чем что-то ещё.
2. Евросоюз запустил публичное обсуждение стратегии импортозамещения и снижения зависимости от США стратегии открытой цифровой экосистемы которая должна помочь цифровому суверенитету ЕС и которая формируется из открытости кода, открытости данных и так далее. Мне такой подход нравится больше чем российское импортозамещение, но реалистичность реального цифрового суверенитета для ЕС, по моему, невелика. Однако если ВЫ резидент ЕС и работаете с открытым кодом и данными, то почему бы не поддержать такое хорошее дело?

#opendata #bigdata #thoughts #opensource #eu

Я про политику и макрополитику в особенности не пишу давно и особо писать об этом не планирую ибо слишком много срани неприличного там происходит повсеместно, но есть и то что затрагивает вопросы открытости. Например, свежая новость что США выходят из 66 международных организаций и международных групп включая 31 группу и структуру ООН включая UN Oceans, UN Population Fund, UN Water, UN Energy, Department of Economic and Social Affairs (DESA) и многих других.

Последствия могут быть весьма разнообразны, учитывая что выход США практически наверняка означает потерю существенного финансирования ООН, но не менее важно и то что многие структуры ООН создают и распространяют данные используемые по всему. миру. Например, DESA ведёт data.un.org портал официальной статистики.

Что будет со многими международными инициативами про данные на базе ООН в 2026 году? Я вот не знаю, похоже что надо отслеживать эту ситуацию.

Другой аспект в структурах из которых США пока формально не вышли, но перестали финансировать. Формально США всё еще участвуют в Open Government Partnership, а де факто с января 2025 года они перестали финансировать эту организацию и НКО внутри США ещё в марте 2025 года писали письмо в OGP о том чтобы провести ревизию обязательств Правительства США по открытости.

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

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

Хочется тут сделать какой-то хороший вывод или мораль, но ничего на ум не приходит. Мир меняется, может и не к лучшему, но к чему-то другому.

#opendata #opengov #thoughts #international #usa

Наблюдаю взлет сервисов автоматического документирования публичных (и не публичных) репозиториев кода. Помимо хорошо известного DeepWiki есть, как минимум, Zread.ai и os.ninja, DeepWiki-Open, OpenDeepWiki, GitSummarize, DeepDocs и другие.

Некоторые из них даже выглядят симпатично, но ИМХО, в генерации документации для открытых репозиториев есть минус в том что это будет хорошо пока Github не сделает это как часть их подписки и тогда у всех сервисов которые сейчас есть и создаются останется востребованность только для кода вне Github'а или же придется очень сильно конкурировать за качество итоговой документации.

В общем, выглядит это всё это как интересный тренд, но с непонятным итогом потому что неявным маркетмейкером тут является Github (Microsoft) который быстро может убить все эти попытки, ну или как минимум сильно обесценить.

Но сама идея интересная и самое её очевидное применение legaltech. Потому что понятное структурированное и логичное изложение НПА по отдельности и по блокам это то что нехватает очень сильно. Мне, правда, самому легалтех не очень интересен, ибо я много матом ругаться и коньяка пить начинаю когда читаю законы. Но общая идея, ИМХО, понятна - в областях где есть объекты требующие подробного понятного изложения и где нет подобных маркетмейкеров подход через автогенерацию документацию в стиле вики будет оправдан

#thoughts #ai #documentation

На днях мне понадобился полный дамп метаданных из европейского портала data.europa.eu для анализа. Там почти 2 миллиона наборов данных и он пока еще не проиндексирован Dateno поскольку работает на нестандартном ПО. Его было бы гораздо проще индексировать скачав полный дамп и индексировать метаданные из него.

Дамп я в итоге нашел, хотя и неочевидным образом, он нашелся только одним из Deep Research инструментом, а вот "гугление" не сработало и другие Depp Research агенты тоже как один предлагали написать скрипт по выкачке этих данных через API.

Однако что оказалось в дампе, в дампе оказались сотни файлов в формате TriG, это такой специальный формат для экспорта спецификации RDF используемой в продуктах Semantic Web/Linked Data. Никакими классическими инструментами аналитики или инженерии данных работать с ним не получится. Нужно писать конвертер по преобразованию этих дампов в какой-либо другой формат, скорее всего в JSON/JSON lines как самый очевидный.

Почему разработчики европейского портала публикуют данные в TriG формате? Потому что они считают это правильным. Связанные данные (Linked Data) это, в первую очередь, европейский концепт описания знаний. В Европе более чем где-либо существуют команды разработчиков разбирающихся в нем и связанных с академической среде где он более популярен.

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

Вот и в случае этого большого дампа с TriG файлами мне придется преобразовать их все, скорее всего в Parquet и это уменьших размер этих файлов во много раз, а может и пару десятков раз. И это правильно, и вот это правильно в виде использования современных форматов распространения данных и их компактное представление я считаю более правильным чем распространение файлов в одном из RDF форматов.

#opendata #europe #rdf #semanticweb #linkeddata #thoughts