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

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

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

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

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

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

Предположим я хочу написать расширение для DuckDB которое бы позволяло делать SQL запросы к метаданным и данным в WARC файлах напрямую. Это могло бы сильно облегчить аналитику на их основе. Но у меня нет оптимального решения как это сделать и я задаю параллельно вопрос 5-6 Deep Research инструментам запрос на гайдлайн и далее уже изучаю их и выбираю дизайн спецификацию которую можно загрузить в Cursor или Antigravity или в другой инструмент.

И это работает, результат неидеальный, но лучше чем если изучать самому с нуля или сразу засовывать задачу в ИИ ассистента.

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

P.S. Все это только пример рассуждений про DuckDB и WARC потому что в самом простом варианте такое расширение уже существует duckdb-warc, но оно малофункционально, откуда и взялась идея насколько хорошо можно сделать его альтернативу малой кровью.

#opensource #ai #warc

Актуальная научная статья на Arxive Buy versus Build an LLM: A Decision Framework for Governments о том покупать ли госорганам (правительствам) LLM или строить собственные. Авторы из разных институций связанных с ИИ, в первую очередь из сингапурских и поэтому, в первую очередь, приводят в пример сингапурский опыт создания государственных LLM, а ещё упоминают швейцарский проект Apertus, проекты LLM из ОАЭ для арабского языка и поддержку Mistral AI в Европе.

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

Почему это важно? Потому что консолидация ИИ инициатив внутри государств неизбежна и многие решения будут исключительно политическими. Например, если в Армении Пр-во захочет сделать ИИ ассистента для госслужащих или граждан то будет ли Пр-во создавать свою ИИ модель или будет разворачивать и инвестировать усилия в одну из существующих? Второй сценарий более вероятен и вот вопрос - какую LLM они используют: открытую китайскую? коммерческую из США? Mistral? российскую от Сбера или Яндекса?

Армения - это как пример страны у которой точно нет ресурсов на создание собственной фундаментальной LLM. Точно также можно рассмотреть Кыргызстан, Грузию, Азербайджан, Узбекистан. Может быть и Казахстан тоже. И это только если пройтись по постсоветским странам.

Вот видите, у меня тоже только вопросы и нет ответов.

#ai #government

Два свежих документа ОЭСР для внимательного чтения:
- The agentic AI landscape and its conceptual foundations систематизация терминологии, определений и основного понимания того что такое ИИ агенты, агентские ИИ и так далее. Не техническое, но концептуальное погружение в предметную область для регуляторов, руководителей и тд. Про технологии мало, про перевод с технологического профессионального на понятный язык - много. Полезно для всех кто ищет правильные определения и внутреннее понимание этих определений.
- Digital Government Index and Open, Useful and Re-usable Data Index. 2025 Results and Key Findings результаты оценки стран ОЭСР и кандидатов по индексам DGI и OURData за 2025, оценки там вполне ожидаемые, однако поражают крайне низкие оценки Турции по открытости данных и очень особенно низкие оценки в доступности данных в Турции. Из всех стран ОЭСР и кандидатов там ситуация хуже всего. В остальном мало что изменилось - Франция и Корея показывают наилучшие практики в открытости данных,

#readings #oecd #ai #opendata #data #government

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

Полезный инструмент для тех кто использует ИИ агентов для работы с кодом.

#opensource #ai #development