Pull to refresh
73

Техножрец

1,2
Rating
49
Subscribers
Send message

Вот как раз статью готовлю. Думаю, сегодня уже будет ближе к вечеру

Мсье встречал 130 тысяч. Но это прямо напряжённая неделя была

Vibe code, ai assistant programming, ai agentic enginering... Какая разница, как это называть. Вы не сможете нормально пользоваться нейросетями при разработке, пока не научитесь проверять код не читая его.

Известно, что каждый автор Хабра должен написать статью про кватернионы.

Такое мы всегда плюсуем.

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

Да нет там ничего ценного. Там самый общий базовый прогон. Ваши тоже самое увидят.

Я лучше статьёй поделюсь. Думаю, завтра уже выложу. Там и про ревью и про правила как раз будет. И много ещё про чего

Про 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"? Не стыдно ли его людям показать? Можно ли это дело вывешивать в интернет? Не уволят ли меня, если я то, что мы написали начальнику покажу.

Тут не должно быть дословного понимания. Программирование агента - оно где-то между риторикой, магией и психологией.

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

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

Да. Направлять нейросеть в области, где у тебя нет опыта сложнее. Но это возможно, хотя и требует отдельного нетривиального навыка.

Управления нейронками - это навык. Ему тоже надо учиться. Решить нейронкой описанную в статье задачу так, чтобы комар носа не подточил - более чем реально. Рука у пацана не набита ещё. Пусть дальше тренируется

Да. Я вообще стараюсь не формулировать в повелительном наклонении, всегда оставляя пространство для отступления.

Особенно полезным показало себя заклинание "сообщай о плохих запахах". Я, когда это писал, думал он по ходу дела будет докладывать о замеченных проблемах в ранее написаном коде. И это сработало. Но вместе с тем агент начал чистосердечно докладывать о своих косяках. Оно прям спасает.

Information

Rating
1,972-nd
Registered
Activity