Статья про NOVA вышла вчера ночью. Прочитали вы её сегодня утром. Пост про регулярные ревью я оставил четыре часа назад. Несколько часов вы работали над планом... С какой же скоростью вы пишите?
Судя по всеми у вас в методологии разработки нет регулярных ревью кодовой базы. Поверхностный аудит находит ряд проблем. Агент утверждает, что проект местами нарушает декларированные правила, есть нарушения заявленных границ. Не берусь оценить, действительно ли это так, но агент ревьювер вещает недовольно.
Меня, как матёрого вайбкодера, больше тревожит вот это: emit_c.rs 28,944 строк, types/mod.rs 16,757, parser/mod.rs 9,896, field_cache.rs 8,987. Агентам сложно работать в крупных файлах. claude этим особенно страдает. Если бы проект проходил регулярный анализ, файлы были бы давно распилены.
Агент утверждает, что emit_c.rs - цитирую: "занимается локальным type inference, registry population, monomorphization details, protocol boxing, diagnostics, runtime lowering, special cases для stdlib, result/option tracking, contracts runtime emission и кучей фазовой логики".
Плохой запах.
Этих гавриков надо посылать не только на ревью последних изменений, но и проект в целом смотреть регулярно. Иначе монолиты растут как снежный ком
Хм... Вы меня сломали. Прогнал текст статьи, что я готовлю через три детектора. Один сказал, что текст стопроцентно писал ИИ. Но этот детектор подозрительный какой-то, так что его не считаем. Ещё два детектора сказали, что текст стопроцентно писал человек. Вот сижу теперь и думаю... Неужели так плохо написано, что меня стопроцентно в люди засчитывают :(
... Как-то раз, ещё когда cyberforum был торт, я консультировал там одного чувака. Парень пришёл на форум жаловаться, что у него в проекте на Ардуинке двигатель крутится только если в комнате горит свет. На десятой итерации технического допроса выяснилось, что в проекте есть датчик освещения, который, хоть и не включен в общий цикл, вполне себе пишет данные. Потом мы быстро обнаружили переполнение массива, пишущее в переменную отвечающую за блокировку двигателя и приведения были оправданы.
Это я к чему... Вы на то и инженер, чтобы заподозрить и уточнить. Этому инженеров учили до нас. Этому учили нас. И мы дальше будем это передавать
Это тоже будет в статье. Как понять почему ваш повар всё время косячит? У вас есть под охрененно прозорливый детектив с высочайшим уровнем эрудиции. Пошлите агента разобраться, почему агент косячит.
Обнаружьте, что его сбивает. Проведите рефакторинг. Спрячьте холодильники с неправильными продуктами в подвал. Сделайте так, чтобы на кухне при всём желании нельзя было заблудиться. Снимите картину со стены, если она падает, когда агент поворачивается.
На самом деле, что делать такие вещи - вам не надо уметь готовить. Очень желательно уметь. Но вообще-то достаточно наблюдать за поведением агента. У вас с какого-то момента в голове просто лампочка загораться начинает. Он ещё ничего не делал, а вы уже понимаете, что попёр не туда
А вам не надо, чтобы код был идеальным. Вам надо, чтобы он работал. Можно задать этот вопрос иначе. Является ли наш код "production ready"? Не стыдно ли его людям показать? Можно ли это дело вывешивать в интернет? Не уволят ли меня, если я то, что мы написали начальнику покажу.
Тут не должно быть дословного понимания. Программирование агента - оно где-то между риторикой, магией и психологией.
Работа с нейронкой в области, где у тебя нет экспертизы весьма своеобразна. Роль эксперта в этом случае передаётся нейросети. Ключевыми заклинаниями становятся вопросы: "всё ли мы правильно делаем?", "соответствует ли наш код общепринятым практикам?", "какие ожидаются проблемы?", "где код может сломаться?", "корректно ли мы обрабатываем ошибки?". И прочие метавопросы.
Собственно, я как раз сейчас набираю материал к статье по вайбкодерским практикам. У меня планируется раздел по работе с агентом вне зоны компетенции.
Да. Направлять нейросеть в области, где у тебя нет опыта сложнее. Но это возможно, хотя и требует отдельного нетривиального навыка.
Управления нейронками - это навык. Ему тоже надо учиться. Решить нейронкой описанную в статье задачу так, чтобы комар носа не подточил - более чем реально. Рука у пацана не набита ещё. Пусть дальше тренируется
Да. Я вообще стараюсь не формулировать в повелительном наклонении, всегда оставляя пространство для отступления.
Особенно полезным показало себя заклинание "сообщай о плохих запахах". Я, когда это писал, думал он по ходу дела будет докладывать о замеченных проблемах в ранее написаном коде. И это сработало. Но вместе с тем агент начал чистосердечно докладывать о своих косяках. Оно прям спасает.
Вместо запроса "подними сервисы любой ценой не подгоняя проверки под результат" написать "Попробуй поднять сервисы. Если этого сделать не удасться, дай отчёт о том, чего не хватает и что ломается".
Так неудача становится положительным результатом и сеть не пытается обманывать
На самом деле, если амортизацию видеокарт посчитать, там не так уж много получается. Тут надо прям считать, чтобы уразуметь, сколько токен на самом деле стоит. Мои прикидочные подсчёты дали число на порядок ниже, чем про то обычно говорят. Не знаю. То ли я дурак, то ли лыжи не едут.
Стоимость электроэнергии там скорее всего составляет достаточно ничтожную долю. Больше уходит на амортизацию, на поддержку работы дата центра, на зарплаты, на налоги, на прочие непрофильные расходы
А, система распознавания речи. Понимаю. Сам использую.
Про sonnet ничё не знаю. Знаю, что профилактика не проводилась
Статья про NOVA вышла вчера ночью. Прочитали вы её сегодня утром. Пост про регулярные ревью я оставил четыре часа назад. Несколько часов вы работали над планом... С какой же скоростью вы пишите?
Определённо нет. С аудитом кода прекрасно справляется даже qwen3.6-27b. Не верю, что sonnet мог пропустить emit_c.rs
Глянул проект глазами агента.
Судя по всеми у вас в методологии разработки нет регулярных ревью кодовой базы. Поверхностный аудит находит ряд проблем. Агент утверждает, что проект местами нарушает декларированные правила, есть нарушения заявленных границ. Не берусь оценить, действительно ли это так, но агент ревьювер вещает недовольно.
Меня, как матёрого вайбкодера, больше тревожит вот это: emit_c.rs 28,944 строк, types/mod.rs 16,757, parser/mod.rs 9,896, field_cache.rs 8,987. Агентам сложно работать в крупных файлах. claude этим особенно страдает. Если бы проект проходил регулярный анализ, файлы были бы давно распилены.
Агент утверждает, что emit_c.rs - цитирую: "занимается локальным type inference, registry population, monomorphization details, protocol boxing, diagnostics, runtime lowering, special cases для stdlib, result/option tracking, contracts runtime emission и кучей фазовой логики".
Плохой запах.
Этих гавриков надо посылать не только на ревью последних изменений, но и проект в целом смотреть регулярно. Иначе монолиты растут как снежный ком
Нельзя же так списками злоупотреблять...
Хм... Вы меня сломали. Прогнал текст статьи, что я готовлю через три детектора. Один сказал, что текст стопроцентно писал ИИ. Но этот детектор подозрительный какой-то, так что его не считаем. Ещё два детектора сказали, что текст стопроцентно писал человек. Вот сижу теперь и думаю... Неужели так плохо написано, что меня стопроцентно в люди засчитывают :(
Сама идея детекторов - очевидная дурость. Они by design не будут работать.
... Как-то раз, ещё когда cyberforum был торт, я консультировал там одного чувака. Парень пришёл на форум жаловаться, что у него в проекте на Ардуинке двигатель крутится только если в комнате горит свет. На десятой итерации технического допроса выяснилось, что в проекте есть датчик освещения, который, хоть и не включен в общий цикл, вполне себе пишет данные. Потом мы быстро обнаружили переполнение массива, пишущее в переменную отвечающую за блокировку двигателя и приведения были оправданы.
Это я к чему... Вы на то и инженер, чтобы заподозрить и уточнить. Этому инженеров учили до нас. Этому учили нас. И мы дальше будем это передавать
Это тоже будет в статье. Как понять почему ваш повар всё время косячит? У вас есть под охрененно прозорливый детектив с высочайшим уровнем эрудиции. Пошлите агента разобраться, почему агент косячит.
Обнаружьте, что его сбивает. Проведите рефакторинг. Спрячьте холодильники с неправильными продуктами в подвал. Сделайте так, чтобы на кухне при всём желании нельзя было заблудиться. Снимите картину со стены, если она падает, когда агент поворачивается.
На самом деле, что делать такие вещи - вам не надо уметь готовить. Очень желательно уметь. Но вообще-то достаточно наблюдать за поведением агента. У вас с какого-то момента в голове просто лампочка загораться начинает. Он ещё ничего не делал, а вы уже понимаете, что попёр не туда
А вам не надо, чтобы код был идеальным. Вам надо, чтобы он работал. Можно задать этот вопрос иначе. Является ли наш код "production ready"? Не стыдно ли его людям показать? Можно ли это дело вывешивать в интернет? Не уволят ли меня, если я то, что мы написали начальнику покажу.
Тут не должно быть дословного понимания. Программирование агента - оно где-то между риторикой, магией и психологией.
Работа с нейронкой в области, где у тебя нет экспертизы весьма своеобразна. Роль эксперта в этом случае передаётся нейросети. Ключевыми заклинаниями становятся вопросы: "всё ли мы правильно делаем?", "соответствует ли наш код общепринятым практикам?", "какие ожидаются проблемы?", "где код может сломаться?", "корректно ли мы обрабатываем ошибки?". И прочие метавопросы.
Собственно, я как раз сейчас набираю материал к статье по вайбкодерским практикам. У меня планируется раздел по работе с агентом вне зоны компетенции.
Да. Направлять нейросеть в области, где у тебя нет опыта сложнее. Но это возможно, хотя и требует отдельного нетривиального навыка.
Управления нейронками - это навык. Ему тоже надо учиться. Решить нейронкой описанную в статье задачу так, чтобы комар носа не подточил - более чем реально. Рука у пацана не набита ещё. Пусть дальше тренируется
Да. Я вообще стараюсь не формулировать в повелительном наклонении, всегда оставляя пространство для отступления.
Особенно полезным показало себя заклинание "сообщай о плохих запахах". Я, когда это писал, думал он по ходу дела будет докладывать о замеченных проблемах в ранее написаном коде. И это сработало. Но вместе с тем агент начал чистосердечно докладывать о своих косяках. Оно прям спасает.
Что делать. Разрешить сети не выполнить задачу.
Вместо запроса "подними сервисы любой ценой не подгоняя проверки под результат" написать "Попробуй поднять сервисы. Если этого сделать не удасться, дай отчёт о том, чего не хватает и что ломается".
Так неудача становится положительным результатом и сеть не пытается обманывать
Да, человеку не скажешь: "Мы с тобой сделали мусор, стирай всё, будем писать по новой". Нейронка же даже не морщиться.
Я так одну систему четыре раза переписывал, пока понял, как она выглядеть должна
Признавайтесь, кто читал это, применяя навыки скорочтения? :)
На самом деле, если амортизацию видеокарт посчитать, там не так уж много получается. Тут надо прям считать, чтобы уразуметь, сколько токен на самом деле стоит. Мои прикидочные подсчёты дали число на порядок ниже, чем про то обычно говорят. Не знаю. То ли я дурак, то ли лыжи не едут.
Стоимость электроэнергии там скорее всего составляет достаточно ничтожную долю. Больше уходит на амортизацию, на поддержку работы дата центра, на зарплаты, на налоги, на прочие непрофильные расходы
Мы должны написать всё, что нужно написать сейчас!