Я разработчик в сфере мобильных игр, занимаюсь в основном программированием геймплея и инструментарием для команд. Люблю Lua, C++, Godot и делать интересные хобби проекты, связанные с геймдевом. Эта статья как раз про один такой проект
Godot - популярный игровой движок на C++ с собственным скриптовым ЯП Физический сервер - программный компонент движка, отвечающий за физические вычисления
Коллизия – в физической симуляции процесс пересечения пары объектов
Недавно у меня была итерация тестирования. Задача — проверить функционал, для которого нужно было создать 50+ сущностей. Однотипных, с разными названиями.
Обычно такое делаю через интерфейс. Открываю форму, заполняю поля, сохраняю. Потом ещё раз. И ещё. Пятьдесят раз. Я замерял: на одну сущность уходит примерно 20 секунд. Умножаем на 50 и получается больше 15 минут однотипных действий. А времени на итерации всегда мало.
Идея была простая, почти наивная: если попросить модель в конце ответа честно написать, уверена она в своём коде или нет, можно ли по этой метке заранее отлавливать плохие решения? Не гонять тесты, не читать код глазами, а просто смотреть на последнюю строку.
Я прогнал 20 небольших задач на Python через три модели, по три повтора на задачу, и собрал 179 ответов. Все 179 закончились строкой CONFIDENCE: SURE. Вариант UNSURE в промпте был, им не воспользовался никто. При этом четыре решения завалили скрытые тесты. Одно превращало 1024 байта в 1.0 MiB, другое падало на разнице между двумя самыми обычными датами. Под обоими стояло SURE.
Привет!
Привет!
В настоящее время многие пробуют использовать ИИ в своей работе, так как он позволяет автоматизировать значительное количество действий. Однако на текущем этапе развития эта технология все еще содержит много подводных камней.
Привет 👋
Самая неприятная ошибка рабочего AI-агента — не странный ответ. Это убедительное «готово», после которого кто-то идёт проверять, переделывать и извиняться перед коллегами.
Ассистенту, который предлагает формулировки, можно простить неудачный абзац. Агенту, который меняет рабочие данные, этого уже мало. Мне интереснее обсуждать его приёмку: что именно должно произойти, чтобы задачу можно было считать закрытой.
Когда говорят о парсинге на Python, в один список обычно складывают BeautifulSoup, Selenium, Scrapy и Playwright. Выглядит как выбор из четырёх аналогов, но это инструменты разных уровней. BeautifulSoup не умеет ходить в сеть. Selenium вообще не парсер. Scrapy — фреймворк, внутри которого можно использовать любой парсер. Сравнивать их в лоб — примерно как сравнивать двигатель, коробку передач и такси.
На практике эта путаница обходится дорого. Для сбора каталога из пары тысяч страниц поднимают Selenium с Chrome, хотя данные лежат в обычном HTML. Или наоборот: полдня пытаются вытащить requests’ом то, что рисует JavaScript, и не понимают, откуда в ответе пустой <div id="root">Читать полностью »
if roc_auc < 0.85: exit 1Читать полностью »
Ошибка линтера стоит пяти минут. Ошибка сканера, который проверяет сайты на соответствие 152-ФЗ, выглядит иначе: «ваш сайт нарушает закон». Если сайт при этом в порядке, а отчёт уже ушёл дальше, расплачивается чужая репутация.
Я пишу такой сканер. Его отчёт читает не только разработчик: он уходит веб‑студии, а от неё владельцу сайта. То есть за выдуманную находку краснеть будет не код, а люди, которые ему поверили.
Мы много разрабатываем с помощью coding agents: веб‑приложения, MCP‑серверы, пайплайны обработки данных, системы из нескольких агентов. И чем лучше становилась инфраструктура вокруг агентов, тем больше в ней появлялось инструкций, проверок, субагентов и автоматики. По идее, разработка должна была становиться дешевле. А расход контекста рос.
Первое подозрение было очевидным: слишком раздутые промпты. Мы искали не там.
Агент закончил изменение и запустил тесты. 178 тестов, все зелёные. На stdout прилетело 38 365 байт TAP:
# Subtest:...
ok 1 ‑...
‑-
duration_ms:...
type: 'test'
..
