Технологии для управления зелёной инфраструктурой в городах

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

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

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

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

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

#инновации

🚀 codex-harness 0.1.2
Что нового:
🔒 Закрыл возможность обхода хуков при сбоях. Раньше агент мог продолжать работу, даже если проверка не запустилась. Теперь такие ошибки обнаруживаются и не считаются успешной проверкой.
🔍 Добавил диагностику установки и работы хуков.
🛠 Добавил новое правило Ruff — запрет импортов внутри функций и классов.
📦 PyPI: https://pypi.org/project/codex-harness/

Codex Harness. Зачем я написал собственную систему контроля кода для ИИ

Недавно публиковал обновление Codex Harness, но, думаю, стоит немного подробнее рассказать, что это вообще за проект и для чего я его разрабатываю.
Сейчас я довольно активно использую Codex в разработке. Инструмент действительно полезный, особенно когда нужно работать с большими проектами. Но есть одна проблема, с которой наверняка сталкивались многие.
Можно сколько угодно описывать правила разработки в AGENTS.md, подключать навыки, требовать соблюдения архитектуры и стандартов кода. Однако всё это остаётся инструкциями для языковой модели. Она может их неправильно интерпретировать, проигнорировать или просто допустить ошибку.
Мне хотелось сделать так, чтобы соблюдение хотя бы части этих правил зависело не от поведения модели, а от обычного программного кода.
Так появился Codex Harness — моя открытая система контроля изменений для Codex CLI.

Как это работает?
Harness подключается к Codex через хуки, которые вызываются при работе агента с инструментами.
Перед изменением Python-файлов через apply_patch система сохраняет их исходное состояние. После изменения запускает анализаторы кода и сравнивает результаты.
Для проверки используются Ruff, Flake8, а также поддерживаются Pylint, Black и MyPy.
Проверяется не только наличие ошибок, но и сложность функций, количество ветвлений, вложенность, длина функций и другие показатели.
При этом есть важный момент: Harness не требует исправлять все старые проблемы проекта. Он не позволяет создавать новые или усугублять существующие.
Например, в проекте уже есть функция на 90 строк при установленном ограничении в 80. Это существующая проблема, и сама по себе она не блокирует работу.
Если Codex увеличит её до 100 строк, проверка обнаружит ухудшение. Если сократит до 85 — такое изменение допустимо.

Что происходит при ошибке?
Harness передаёт Codex конкретные замечания, после чего агент может самостоятельно исправить код и повторить попытку.
Количество неудачных попыток ограничено. По умолчанию их три. После исчерпания лимита дальнейшие изменения через apply_patch в рамках текущего запроса блокируются.
Отдельно предусмотрена обработка ошибок самой системы проверки. Если анализатор не запустился или проверка завершилась с ошибкой, такой результат не должен считаться успешным.

Что дальше?
Сейчас основное внимание уделено Python и проверкам изменений через apply_patch. Полный контроль изменений через другие инструменты, проверка перед завершением задачи и архитектурные ограничения пока остаются направлениями дальнейшей разработки.
В перспективе хочу добавить контроль зависимостей между слоями приложения, архитектурных правил и поддержку других языков.
Главная идея проекта довольно простая: качество кода должно проверяться конкретными правилами, а не только обещаниями языковой модели их соблюдать.

Проект распространяется с открытым исходным кодом под лицензией Apache 2.0.
📦 Установка: pip install codex-harness
💻 GitHub: https://github.com/r-tatarinov/codex-harness
📦 PyPI: https://pypi.org/project/codex-harness/

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

⚡️ Небольшая просьба к подписчикам с Telegram Premium.

Если у вас есть свободные бусты, можете поддержать Kangaroo. Это бесплатно, а каналу поможет открыть дополнительные возможности оформления и публикации историй.

https://t.me/boost/channelpy

Спасибо за поддержку 🙂

MCP на пальцах

Сейчас много говорят про MCP, иногда чуть ли не как про таблетку от всего. Поэтому решил на пальцах объяснить, что это такое и что там есть, кроме инструментов.

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

Начнём с tools. Это обычные функции, которым разработчик дал описание и указал параметры. Модель по описанию выбирает подходящую, приложение отправляет запрос серверу и получает результат. Внутри может быть обращение к API, поиск, работа с файлами — обычный код, который кто-то написал.
Но функциями дело не ограничивается. Есть resources — данные, которые сервер предоставляет для контекста модели. Например, документация проекта или описание структуры базы. У ресурса есть свой идентификатор, по которому можно запросить его содержимое. Что прочитать и передать модели, решает приложение.
То есть подключить MCP-сервер с документацией — не значит, что модель уже всю её прочитала. Доступ к данным и сами данные в контексте — разные вещи.
Ну и prompts. Те самые промпты, только заготовленные на стороне сервера. Пользователь выбирает нужный, при необходимости указывает параметры и получает подготовленные сообщения для модели. Чтобы каждый раз не писать одни и те же инструкции. Сам по себе такой шаблон никаких действий не выполняет.

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

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

🛡 Гвардрейлы: зачем ограничивать искусственный интеллект?
В последнее время всё чаще можно услышать слово guardrails, особенно когда речь заходит об ИИ-агентах. Давайте разберёмся, что это такое, зачем они нужны и почему одних инструкций для модели бывает недостаточно.
Представьте, что вы поручили агенту исправить небольшую ошибку в проекте. Он изучил код, нашёл проблему и приступил к работе. Но попутно решил обновить зависимости, переписать конфигурацию и удалить несколько файлов, которые посчитал ненужными.
Возможно, из лучших побуждений. Только вы его об этом не просили.
Конечно, можно заранее написать в инструкциях: «Не изменяй ничего лишнего, не удаляй файлы, не трогай базу данных». И в большинстве случаев агент будет стараться этим инструкциям следовать.

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

И ещё один интересный момент: гвардрейлы необязательно должны использовать другую нейросеть.
Это могут быть обычные проверки, валидаторы, линтеры, ограничения доступа, хуки и другие вполне привычные разработчику инструменты.
Я с этим столкнулся при работе над собственным проектом codex-harness.
Оказалось, что мало просто добавить проверки. Нужно ещё убедиться, что они действительно запускаются и агент не может продолжить работу, если одна из них завершилась с ошибкой. Иначе получается довольно забавная ситуация: защита вроде бы существует, но в определённых условиях её можно обойти.
Собственно, этим и отличается реальный контроль от очередной строчки в системном промпте.
Разумеется, гвардрейлы не делают агента безошибочным и не заменяют нормального разграничения прав. Но позволяют существенно снизить вероятность того, что одна неудачная команда превратится в проблему для всего проекта.

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

Моё руководство к чистому коду

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

1. Один класс — один файл.
Не понимаю, зачем собирать десяток классов в одном файле. Гораздо удобнее, когда у каждого класса своё место. И искать проще, и разбираться в чужом коде.

2. Одна ответственность — один компонент.
Если класс и с базой работает, и письма отправляет, и бизнес-логику обрабатывает, я бы его разделил.
Не нужно пытаться запихнуть всё в один сервис только потому, что так быстрее написать.

3. Одна предметная область — свой пакет.
Пользователи, заказы, платежи — всё по своим пакетам.
Особенно не люблю, когда в проекте появляется папка utils, а через полгода там уже половина приложения. С helpers и common примерно та же история.

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

5. Структура проекта должна отражать его архитектуру.
Открыв проект, хочется понимать, где что находится, а не изучать историю решений предыдущих разработчиков.
Когда бизнес-логика разбросана между services, core, common и utils, работать с таким проектом становится не очень приятно.

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

Коллеги из Фактосборки решили проверить Codex Harness на практике.

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

Проверили Codex Harness: где он держит, а где его обходят

Это хуки для Codex: после каждой правки гоняют Ruff и Flake8 и не пускают ухудшения кода. Мы прогнали 13 сценариев. Новый лишний import, раздутую старую функцию и попытку ослабить правила — блокирует. А # noqa и правки через shell проходят. Главная дыра: если после блока агент не исправил код, а правит дальше, ошибка тихо уходит в «старый долг».

ИИ стал писать больше кода. А разработка быстрее не стала?

Попалось довольно интересное исследование двух учёных из Гарварда — Fiona Chen и James Stratton. Они решили проверить, как внедрение ИИ влияет на реальную работу команд разработки.
Для этого изучили около 300 миллионов событий в 718 компаниях за период с 2021 года по март 2026-го. Анализировали коммиты, pull request'ы, закрытые задачи и работу с ИИ-инструментами.

Результаты после внедрения ИИ-агентов получились любопытные:
На 30% больше написанных строк кода.
На 20% больше коммитов.
На 23% больше pull request'ов.
На 49% увеличилось время от создания PR до его слияния.
На 35% выросло количество комментариев при ревью.
Причём доля PR, которые отправляли на доработку, выросла примерно с 13% до 25%.

Статистически значимого увеличения количества закрытых задач и эпиков исследователи не обнаружили.
Получается, кода стали писать больше, изменений тоже, а вот сопоставимого прироста готового результата пока не видно.
Авторы связывают это с узким местом в процессе разработки — проверкой кода. Агент может быстро написать реализацию, но её ещё нужно проверить, исправить замечания, протестировать и довести до рабочего состояния.
Правда, тут есть нюансы. Те самые 49% — это время от создания PR до слияния, а не непосредственно часы, потраченные разработчиком на ревью. Да и само исследование основано на наблюдениях, а не контролируемом эксперименте. Поэтому говорить, что ИИ делает команды медленнее, было бы неправильно.

И возникает вопрос: а что вообще считать продуктивностью разработчика в эпоху ИИ? Количество написанного кода или количество задач, действительно доведённых до результата?

Оригинал исследования: Artificial Intelligence in the Firm: Bottlenecks in Software Production

База данных быстрее файловой системы? Оказывается, бывает и такое.

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

Разработчики SQLite решили проверить это экспериментально.
Они взяли 100 тысяч небольших объектов размером около 10 КБ и сравнили чтение из обычных файлов с чтением из SQLite.
Результат оказался неожиданным:
— SQLite читала данные примерно на 35% быстрее.
— Хранение в базе потребовало примерно на 20% меньше места.

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

📖 Эксперимент разработчиков SQLite

Synaptic Garden: что происходит в AI-индустрии сегодня и к чему готовиться завтра

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

Для тех, кто создает будущее, а не наблюдает за ним: @synaptic_garden

ИИ научился распознавать ИИ. А люди пока не очень

Сегодня наткнулся на любопытное исследование в Nature Human Behaviour. Учёные решили проверить, насколько хорошо люди отличают ответы нейросетей от человеческих.

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

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

Осталось придумать, кто будет проверять проверяющих. Хотя подозреваю, на эту должность тоже уже претендует ИИ.
Исследование в Nature Human Behaviour

Боб Мартин решил научить ИИ-агентов писать чистый код

Роберт Мартин, известный как Uncle Bob и автор книги «Чистый код», опубликовал на GitHub интересный проект под названием ub-mode.
По сути, это набор инженерных принципов, оформленный в виде скилла для ИИ-агентов. Но интересен здесь не столько сам формат, сколько подход к разработке.

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

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

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

Помимо инструкций, Мартин предлагает использовать отдельные инструменты: Crapper для оценки сложности кода с учётом тестового покрытия, Dryer для поиска дублирования и Mutator для мутационного тестирования. Последний позволяет проверить, действительно ли тесты обнаруживают ошибки, намеренно изменяя код.

Репозиторий: https://github.com/unclebob/ub-mode

GPT-6.1 Terra. OpenAI серьёзно прокачала свою быструю модель

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

Что изменилось в цифрах?
50,3% против 21,5% — результат на Terminal-Bench 4.0 по сравнению с GPT-5.6 Terra при максимальном уровне рассуждений.
16,7% против 53,6% — частота фактических ошибок на внутреннем тесте OpenAI при низком уровне рассуждений.
Более чем в 3 раза быстрее GPT-6 Astra и GPT-6.1 Sol при выполнении задач в Agents' Last Exam.
На 50% дешевле предыдущей Terra по стандартным тарифам API.

Причём на Agents' Last Exam, где проверяются способности агентов выполнять реальные задачи в программных интерфейсах, новая Terra при среднем уровне рассуждений показала результат на уровне GPT-6 Astra при стоимости токенов примерно в 10 раз ниже.
Отдельно стоит отметить контекстное окно — 1,05 миллиона токенов.

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

Конечно, для сложных инженерных задач Astra и Sol пока остаются более подходящими вариантами. Но для большого количества повседневных операций новая Terra выглядит весьма перспективно.
Модель уже доступна в Codex, ChatGPT Work и через API под идентификатором gpt-6.1-terra.
Для запуска в актуальной версии Codex CLI:
codex -m gpt-6.1-terra

Официальный анонс: https://openai.com/index/introducing-gpt-6-1-terra/