Стало. Мы живём в разных мирах: в моём ценностью является удовлетворённость юзера, а в вашем – выполнение плана релизов. Даже если для этого нужно фальсифицировать результаты тестов: сделаем релизный пайплайн зелёным, хоть и известно, что он валится, выкатим релиз в срок, а разбираться будем потом. Могу предположить, именно поэтому у вас несколько релизов в день: по сути вы превратили прод в тестовый полигон – выкатываете на него сырой код, а когда начинают сыпаться ошибки, судорожно чините по живому. Другой причины не вижу, не бывает систем, в которые по нескольку раз в день добавляют полноценные новые фичи, требующие релиза.
Поэтому я за то, чтобы флаки разбирать и классифицировать по источнику, а не просто «бороться с тестами» или «всегда считать это багом».
Видите ли, из Вашего текста это никак не следует. Строго наоборот:
Следующая идея — использовать рераны (--reruns): они повторяют упавшие тесты несколько раз. И если тест проходит при повторе в большинстве случаев, то он считается успешным.
Рераны мы начали использовать, но всё же их было недостаточно.
Вы таки используете рераны – добиваясь зелёного пайплайна несмотря на то, что часть тестов упала – безо всякой классификации, просто потому, что "большинство за". Применительно к проду это звучит как: "если падает всего у двух юзеров из пяти, то и фиг с ним".
То есть мы видим: «Да, тест упал, но мы знаем почему».
А на проде юзер тоже видит: "да, упало, но мы знаем, почему!" – и сразу успокаивается?
Не надо бороться с тестами – бороться надо с багами, которые они вскрывают. Плавающий дефект – это не неудобство тестировщика, у которого пайплайн падает. Это проблема, которая в сколько-нибудь нагруженной системе гарантированно вылезет на проде. Лечить нужно болезнь, а не симптомы.
Остаётся неясным вопрос, что делать тем, у кого в линухе никакого трэя нет – одни буковки. И сдаётся мне, среди тех, кому нужен rsync нас значительное большинство.
Сразу видно что вам никогда не прихидолсь пересобирать мир. … минуты … :)
Я вроде писал о человеческом времени. Подозреваю, при сборке этого самого мира (сколько бы времени она ни занимала) никто не сидит в интерактиве с компилятором, указывая ему, что делать. А если сидит, то что-то там крепко неправильно.
если ИИ настолько хорошь - то почему мы не просим его сразу генерить бинарки?
Может быть, потому, что замена компилятора ИИ не сэкономит ни минуты человеческого времени? Или потому, что компиляция кода – строго формализуемая задача, а его написание – нет? Каждый инструмент должен применяться по назначению – а то получается: если микроскоп такой тяжёлый, почему им гвозди не забивают?
насколько код ломается при переходе на новую версию?
Мы с Клодом день просидели (на миграции ~40К строк кода). Но там большую часть времени заняла миграция на primary constructors. dart fix для неё есть, но работает кривовато, нужно тщательно следить за руками. И добавления в линтер use_primary_constructors недостаточно, нужно вот это вот всё:
Тогда более или менее норм отрабатывает. Хотя был странный глюк: автофикс в четырёх местах удалил док комменты. На скорость не влияет, конечно, но настораживает.
А замена либ гуёв и локализации довольно легко прошла. Пока вроде глюков не заметил.
Держим Foreground Service, подключение по сокету к серверу, и получаем пуши.
Заранее прошу прощения, если вопрос тупой – с низкоуровневой инфраструктурой передачи пушей никогда не разбирался. Спрашиваю из любопытства.
Вот у меня сейчас есть аппа, которая тоже держит FGS – но, никакого уведомления на шторке она не показывает. По простой причине: у неё нет пермиссии не пуши – мне не надо, меня локейшн интересует, FGS только ради того, чтобы он не терялся в бэкграунде. А у вас так сделать нельзя? Если вы работаете в обход FCM, пермиссия на нотифы вообще требуется?
Для App Review был добавлен специальный демонстрационный режим
Я уже довольно давно пришёл к тому же. В частности, что эппл, что гугль любят нанимать ревьюверов из дешёвых стран типа Индии, Малайзии и т.п. В результате они у нас либо сразу банились, и мы получали отказ по не работающему логину, либо логин проходил, а вот платежи из неподдерживаемой страны – нет. Тоже отказ. Пришлось добавить на бэк список продакшн версий, и если версия аппы более новая, считать, что это ревью или тесты, и обходить все критические блокировки. Ну и ещё кое-что по мелочи пришлось подгонять под них.
Использовать ИИ можно очень по-разному, и любопытно, что разные пути сходятся к одному и тому же выводу: человек уходит с ревью строк на ревью намерений и границ.
Именно так. ИИ генерирует слишком много кода в единицу времени, чтобы человек мог его хотя бы оценивать в том же темпе. Да и честно говоря, претензию именно к качеству кода свежим моделям предъявить трудно – чисто технически они пишут хорошо. При условии, что задача, ограничения и критерии успеха сформулированы точно и недвусмысленно. Со знаменитыми галлюцинациями практически не сталкиваюсь – ну может, пару раз что-то похожее было. Вероятно, в силу именно того, что каждый шаг проекта документирован, причины принятых решений понятны и особого простора для фантазий не оставляют.
Когда код пишет агент со скоростью тысячи строк в час, ревьюить его глазами на соответствие архитектуре невозможно — вы станете бутылочным горлышком или начнёте пропускать.
Это правда, если ревьювить каждую строчку, то наверное, было бы быстрее самому написать. Но выход есть: надо разбивать работу на этапы. Я все изменения (за исключением самых мелких) пускаю через superpowers: сначала сам пишу описание фичи или изменения в отдельном .md, потом он пишет полную спецификацию, я просматриваю и корректирую по необходимости, и далее он на основе этой спецификации пишет план реализации. Код в нём тоже есть, но на него я особо не смотрю даже, а обращаю внимание в первую очередь именно на соответствие предложенного плана архитектурным решениям. Ну и на заключительном этапе, конечно, обязательное ревью другим агентом. Пока результат (на проекте в ~30K строк кода) меня устраивает.
Что любопытно, при таком подходе количество строк документации в .md (49K) превышает количество строк собственно кода.
В отличие от человека ИИ не учится на решаемой задаче. Новая версия условно "прослушала углубленный курс", но не получила опыт в вашем проекте.
Смотря что вкладывать в понятие обучения. Новых навыков не приобретает, да – веса фиксированные для данной версии. А вот базу знаний по конкретному проекту очень даже накапливает, в различных формах: спеки, созданные в процессе решения отдельных задач, плюс история проекта в ~/.claude/projects/{project path}, правила и скиллы, созданные в процессе работы над проектом, тесты, в конце концов.
Я сейчас делаю небольшой (~30К строк кода) проект, изначально в паре с клодом. И самого начала по всем канонам: SDD, TDD. Сам не пишу практически ничего, иногда какие-то мелочи подправляю. И качество кода, и функционал вполне удовлетворительные, и в процессе добавления фич предыдущие решения он помнит прекрасно – порой лучше меня. На каждое решение в проекте есть два документа: спека и план реализации – к которым он при необходимости обращается. Тестов более 800, 77% покрытие. Это можно считать обучением? Новая версия модели эти знания будет использовать точно так же, как и предыдущая.
программисты нам больше не нужны, Заказчики пока не в курсе.
Тут есть довольно интересный момент. Многие привыкли брать оплату по человеко-часам. Получается, замена живых разработчиков на ИИ для них – чистый убыток.
Не совсем понятно, чем это отличается от подключения MCP/LSP сервера используемого языка. Он ведь точно так же выставляет наружу граф ASP и греп становится не нужен. Не поясните разницу/преимущества?
Стало. Мы живём в разных мирах: в моём ценностью является удовлетворённость юзера, а в вашем – выполнение плана релизов. Даже если для этого нужно фальсифицировать результаты тестов: сделаем релизный пайплайн зелёным, хоть и известно, что он валится, выкатим релиз в срок, а разбираться будем потом. Могу предположить, именно поэтому у вас несколько релизов в день: по сути вы превратили прод в тестовый полигон – выкатываете на него сырой код, а когда начинают сыпаться ошибки, судорожно чините по живому. Другой причины не вижу, не бывает систем, в которые по нескольку раз в день добавляют полноценные новые фичи, требующие релиза.
Видите ли, из Вашего текста это никак не следует. Строго наоборот:
Вы таки используете рераны – добиваясь зелёного пайплайна несмотря на то, что часть тестов упала – безо всякой классификации, просто потому, что "большинство за". Применительно к проду это звучит как: "если падает всего у двух юзеров из пяти, то и фиг с ним".
А на проде юзер тоже видит: "да, упало, но мы знаем, почему!" – и сразу успокаивается?
Не надо бороться с тестами – бороться надо с багами, которые они вскрывают. Плавающий дефект – это не неудобство тестировщика, у которого пайплайн падает. Это проблема, которая в сколько-нибудь нагруженной системе гарантированно вылезет на проде. Лечить нужно болезнь, а не симптомы.
Собственно, это всё, что нужно знать об этом проекте и о команде, которая его делала. Соответственно, неудивительно, что там появляется
и
Остаётся неясным вопрос, что делать тем, у кого в линухе никакого трэя нет – одни буковки. И сдаётся мне, среди тех, кому нужен
rsyncнас значительное большинство.Я вроде писал о человеческом времени. Подозреваю, при сборке этого самого мира (сколько бы времени она ни занимала) никто не сидит в интерактиве с компилятором, указывая ему, что делать. А если сидит, то что-то там крепко неправильно.
Может быть, потому, что замена компилятора ИИ не сэкономит ни минуты человеческого времени? Или потому, что компиляция кода – строго формализуемая задача, а его написание – нет? Каждый инструмент должен применяться по назначению – а то получается: если микроскоп такой тяжёлый, почему им гвозди не забивают?
Там есть одна бяка, линтер тупо крэшится на
enum Foo() {...}– приходится добавлятьМы с Клодом день просидели (на миграции ~40К строк кода). Но там большую часть времени заняла миграция на primary constructors.
dart fixдля неё есть, но работает кривовато, нужно тщательно следить за руками. И добавления в линтерuse_primary_constructorsнедостаточно, нужно вот это вот всё:Тогда более или менее норм отрабатывает. Хотя был странный глюк: автофикс в четырёх местах удалил док комменты. На скорость не влияет, конечно, но настораживает.
А замена либ гуёв и локализации довольно легко прошла. Пока вроде глюков не заметил.
Заранее прошу прощения, если вопрос тупой – с низкоуровневой инфраструктурой передачи пушей никогда не разбирался. Спрашиваю из любопытства.
Вот у меня сейчас есть аппа, которая тоже держит FGS – но, никакого уведомления на шторке она не показывает. По простой причине: у неё нет пермиссии не пуши – мне не надо, меня локейшн интересует, FGS только ради того, чтобы он не терялся в бэкграунде. А у вас так сделать нельзя? Если вы работаете в обход FCM, пермиссия на нотифы вообще требуется?
Я уже довольно давно пришёл к тому же. В частности, что эппл, что гугль любят нанимать ревьюверов из дешёвых стран типа Индии, Малайзии и т.п. В результате они у нас либо сразу банились, и мы получали отказ по не работающему логину, либо логин проходил, а вот платежи из неподдерживаемой страны – нет. Тоже отказ. Пришлось добавить на бэк список продакшн версий, и если версия аппы более новая, считать, что это ревью или тесты, и обходить все критические блокировки. Ну и ещё кое-что по мелочи пришлось подгонять под них.
Именно так. ИИ генерирует слишком много кода в единицу времени, чтобы человек мог его хотя бы оценивать в том же темпе. Да и честно говоря, претензию именно к качеству кода свежим моделям предъявить трудно – чисто технически они пишут хорошо. При условии, что задача, ограничения и критерии успеха сформулированы точно и недвусмысленно. Со знаменитыми галлюцинациями практически не сталкиваюсь – ну может, пару раз что-то похожее было. Вероятно, в силу именно того, что каждый шаг проекта документирован, причины принятых решений понятны и особого простора для фантазий не оставляют.
Это правда, если ревьювить каждую строчку, то наверное, было бы быстрее самому написать. Но выход есть: надо разбивать работу на этапы. Я все изменения (за исключением самых мелких) пускаю через
superpowers: сначала сам пишу описание фичи или изменения в отдельном.md, потом он пишет полную спецификацию, я просматриваю и корректирую по необходимости, и далее он на основе этой спецификации пишет план реализации. Код в нём тоже есть, но на него я особо не смотрю даже, а обращаю внимание в первую очередь именно на соответствие предложенного плана архитектурным решениям. Ну и на заключительном этапе, конечно, обязательное ревью другим агентом. Пока результат (на проекте в ~30K строк кода) меня устраивает.Что любопытно, при таком подходе количество строк документации в
.md(49K) превышает количество строк собственно кода.Смотря что вкладывать в понятие обучения. Новых навыков не приобретает, да – веса фиксированные для данной версии. А вот базу знаний по конкретному проекту очень даже накапливает, в различных формах: спеки, созданные в процессе решения отдельных задач, плюс история проекта в
~/.claude/projects/{project path}, правила и скиллы, созданные в процессе работы над проектом, тесты, в конце концов.Я сейчас делаю небольшой (~30К строк кода) проект, изначально в паре с клодом. И самого начала по всем канонам: SDD, TDD. Сам не пишу практически ничего, иногда какие-то мелочи подправляю. И качество кода, и функционал вполне удовлетворительные, и в процессе добавления фич предыдущие решения он помнит прекрасно – порой лучше меня. На каждое решение в проекте есть два документа: спека и план реализации – к которым он при необходимости обращается. Тестов более 800, 77% покрытие. Это можно считать обучением? Новая версия модели эти знания будет использовать точно так же, как и предыдущая.
Ага. Только вот токены стоят 2х от опуса. И по первым впечатлениям очень похоже, что жрёт она их намного активнее.
Тут есть довольно интересный момент. Многие привыкли брать оплату по человеко-часам. Получается, замена живых разработчиков на ИИ для них – чистый убыток.
Да, извините 🙂
Понятно, спасибо. Надо будет попробовать.
Не совсем понятно, чем это отличается от подключения MCP/LSP сервера используемого языка. Он ведь точно так же выставляет наружу граф ASP и греп становится не нужен. Не поясните разницу/преимущества?
Собственно, всю статью можно было бы сократить до одной фразы: