Комментарии 9
Отличный инструмент. А можете поделиться вашими командами для генерации графиков, а еще лучше внести это в репозиторий. А то вот получил я curve.jsonl и дальше не знаю что делать.
Внёс: tools/history/plot.py, рисует кривую из curve.jsonlpython3 tools/history/plot.py curve.jsonl -o curve.png
Нужен matplotlib. По умолчанию рисует critical+high на тысячу строк, --metric per_kloc_total даст все находки, а если передать несколько jsonl файлов - по линии на проект
Какой расход токенов в день?
Поставил
Но оно виснет на моем проекте, попробую сузить…
Хорошо бы добавить какой то встроенный сбор метрик по времени обработки, чтобы искать подобные случаи и локализовывать, отсылать автору.
А идея конечно хорошая. Где то видел похожий инструмент для sprint, можно из похожих линтеров для ии почерпнуть некоторых идей.
Желаю Вам хорошего развития этого и остальных проектов!
Спасибо, что попробовали! Зависание хочется поймать: до публикации инструмент жил на двух моих проектах, чужие кодовые базы только начали появляться. Встроенных таймингов по анализаторам пока нет (есть только общее время в конце) - идея хорошая, возьму в работу. А сузить можно уже сейчас: glint check -v покажет, сколько файлов нашлось и дошло ли дело до правил, а glint check -c <категория> и -r <правило> запускают анализаторы по отдельности - виновник находится за несколько запусков. Что найдётся (или даже если ничего) - заведите issue на github.com/aiseeq/glint с примерным размером проекта, посмотрю.
Сделал: в main появился флаг --timing, он печатает время по каждому правилу и самый медленный файл. Если снова зависнет - запустите с --timing и нажмите Ctrl+C, в отчёте будет секция IN FLIGHT: на каком правиле и каком файле оно застряло (или что застрял type-check на загрузке). Поставить можно так:
go install github.com/aiseeq/glint/cmd/glint@main
Ещё раз прочитал статью и возник такой вопрос: благодаря правилам линтера мы будем получать "красивый" код, но как проверяется, что модель делает вообще то что нужно?
Судя по количеству удалённых строк, явно не ревью :)
Автоматическое ревью? Тесты?
У меня сейчас небольшой проект стартует, как раз возможность попробовать отпустить вожжи, но у меня до сих нет в голове понимания, почему это будет работать.
Линтер и правда отвечает только за то, как код написан. "То ли он делает" проверяют другие слои.
Тесты: прогон должен быть зелёным перед коммитом так же, как статанализ, и порядок их появления зависит от типа задачи. Когда фиксим баг - тест до фикса, крайне важно сначала получить красный тест, воспроизводящий проблему. Иначе модель может сделать "фикс" и тест под фикс, но это не чинит багу. Когда пилим новую фичу - тесты после кода, тут порядок не важен. Но важно глазами проверить, что сделано то, что запрошено: если не проверить, может оказаться, что сделано не то, и под это "не то" уже написаны тесты, закрепляющие статус кво.
Плюс проектные инварианты, они в статье мелькали: запрет на разные источники истины, финансовые правила - это уже про поведение. Построчного ревью правда нет - я на проекте один, столько диффов не прочитать. Частичная замена - попросить агента глянуть критическим взглядом на свою же работу. В отличие от людей, модель не имеет привязанности к своему труду и не стремится его защищать: сказали критикуй - критикует.
Почему это будет работать - заранее не докажу, уверенность у меня накопительная: каждый разобранный баг становится тестом или правилом, и через пару месяцев старые классы ошибок перестают возвращаться. На старте нового проекта я бы взял линтер с первого дня, красный прогон блокирует коммит, каждый пойманный руками баг имеет шанс превратиться в глобальную проверку. И вожжи не столько отпускаются, сколько перекладываются - с чтения строчек на владение проверками. Расскажете потом, как зашло =)

Пятнадцать месяцев финтеха агентами: кривая качества по всей истории проекта