Ask HN: Как справляться с отправкой AI-кода, который вы не понимаете?
Ask HN: How to deal with shipping AI-written code you don't understand?
Я на пенсии, и единственный, перед кем я отчитываюсь за прогресс, — это я сам. Я упрямый сторонник качества, а не скорости, но при этом люблю прогресс. Этим утром я получил предварительные результаты C-фронтенда к компилятору: используя clang для компиляции в LLVM IR, затем транслируя в наш IR и подавая его в автовекторизатор, я получил значительное ускорение на том же исходном коде — например, Mandelbrot в 187 раз, mandel_deep в 1312 раз. Hacker News не проявляет интереса: любые мои посты со ссылками на веб-страницы сразу блокируются или помечаются как dead, поэтому я подожду, пока будет готов C++-фронтенд (где-то на следующей неделе), и анонсирую в другом месте.
Компилятор, который берёт стандартный C/C++ код и ускоряет его, автоматически находя участки для параллельной обработки данных и планируя их на GPU без дополнительных усилий программиста, — это довольно редкая вещь. Кроме того, он управляет локальной сетью, так что вы можете запускать xcd на машинах в вашей LAN или через мост TB4/5 между Mac'ами, и он будет планировать задачи на другие GPU так же, как управляет несколькими GPU на локальной машине. Он оценивает как задержку, так и время вычислений, чтобы определить, на каких устройствах стоит планировать.
- spike021
Я провожу много времени, итерируя планы реализации фич с Claude (на работе) и GPT (для личных проектов).
Затем я слежу за тем, чтобы они писали много тестов и чтобы при изменении, добавлении или удалении функциональности тесты обновлялись вместе с ней.
В целом я стараюсь сам просматривать изменения и просить его объяснять изменения.
Это не идеально, но мне кажется, что итеративный этап планирования не так уж сильно отличается от моего старого цикла: исследование -> обдумывание реализации -> реализация.
В этот момент просмотр любых изменений кода идёт рука об руку с тем, как я писал код до LLM.
Главное отличие в том, что обычно я заставляю его вносить любые изменения для того, что мне не нравится.
- ChrisMarshallNY
Тестирование.
Много-много тестирования. Обычно я тестирую в интерактивном режиме с LLM. Теперь, когда я трачу меньше времени на кодинг, у меня есть больше времени на тестирование.
По моему опыту, с LLM я тестирую больше, чем тестировал свой собственный код. Я не нахожу ошибок в кодинге, но нахожу ошибки в реализации.
Ещё один момент: я прогнал LLM на куче действительно зрелого кода, который написал сам и мог бы поклясться, что он «идеален», и она нашла ряд проблем.
Никто не идеален. Доверяй, но проверяй.
- skeledrew
Технически это просто смена роли. Теперь вы менеджер проекта или что-то в этом роде, а не разработчик. Работа менеджера проекта — не понимать код, а только следить за тем, чтобы он делал то, что должен, и не делал того, чего не должен. И чтобы разработчики и прочие не были заблокированы и работали хорошо. Примите новую роль.
- trezm
Я игрался с https://getchronosphere.com. Он (пытается) пересобрать PR в связное путешествие, а не в огромную кучу. До этого момента это было несколько полезно, и всё ещё улучшается.
- spacedcowboy
Я медленно склоняюсь к мысли, что если это работает, меня это устраивает. Я ведь тоже никогда лично не проверял всю работу своих коллег, просто доверял, что они сделали её хорошо.
Это не значит, что я слепо доверяю LLM — мой проект — это автовекторизующий компилятор. Я заставляю его писать кучу тестов, и у меня есть реальные, нетривиальные программы, которые он скомпилировал. У меня есть «гейт» перед релизами, который занимает буквально часы на 5 разных архитектурах. Сказать, что этот код протестирован, — это... мастерское преуменьшение.
Думаю, помогает долгая сессия планирования: углубление в детали, проработка угловых случаев, проектирование тест-кейсов — знаете, работа и усилия. Как только это сделано, легче позволить ему работать всю ночь и сделать крупную производственную фичу.
Я всё ещё просматриваю код, но, положа руку на сердце, не могу сказать, что просмотрел всё; иногда я что-то упускаю в сложном коммите. Я стараюсь делать коммиты маленькими и локальными, но иногда это нелегко совместить с правилом «не ломай ничего».
Так что всё сводится к тому, что я работаю над этим около 6 месяцев, и пока это срабатывало для меня. Знаете, вроде как привыкаешь к особенностям коллеги со временем.
Скажу, что по моему опыту качество кода довольно высокое. Может быть, это благодаря усилиям, вложенным заранее на этапах планирования, не знаю, но я, похоже, не страдаю от того «шлака», на который жалуются люди. YMMV.
- 4ndrewl
Именно так каждый день чувствует себя любой продакт-менеджер.
Если вы промптер LLM, выпускающий продукты, ваши результаты больше похожи на результаты продакт-менеджера, а не инженера-программиста.
- solatic
Это не так уж непохоже на жизнь инженера уровня Principal до ИИ. Технически вы курируете работу многих инженеров над их собственными системами, но вы не можете физически просмотреть весь код сам. Вы понимаете, что человеческое ревью кода сокращает, но не устраняет количество и серьёзность багов, попадающих в продакшен. У вас в голове нет низкоуровневых деталей, только высокоуровневые. Вы проектируете, как все эти инженеры взаимодействуют друг с другом, не наступая никому на ноги.
Время покажет, были ли мы правы, перейдя от системы, где мы доверяли людям понимать низкоуровневую систему, к системе, где мы доверяем навороченным калькуляторам. Но пока это работает.
- cadamsdotcom
Разработка через тестирование и пирамида тестирования.
Если агент написал тесты и, что критически важно, видел, как они падают, прежде чем начать работу по их прохождению, у вас есть большая уверенность.
Ревью собственной работы тоже проще — тестовый и производственный код обычно зеркалят друг друга, давая гораздо более полную картину. Запутались в производственном коде? Пойдите почитайте его тесты немного, потом возвращайтесь.
Также легче понять изменение, если вы присутствовали при сборке, наблюдая за транскриптом и периодически проверяя. Это не обязательно должно быть вашей основной задачей — оставьте его на втором мониторе, оно само привлечёт ваше внимание.
И наконец, поверх разработки через тестирование, пусть агент сначала (до первого цикла разработки через тестирование) построит сквозной тест, покрывающий работу, которую он будет делать. Как только этот тест станет зелёным (на языке TDD — «проходит»), ваша работа сделана, и вы можете наводить чистоту по желанию.
Поиграйте с этим перед релизом, доведите до ума. Никогда ещё не было так легко разгрести технический долг и сделать UI идеальным.
В конце концов вы будете готовы упаковать это в PR!
Теперь вы можете использовать агентов и проявить креативность. Заставьте коллег сгорать от желания отревьюить вашу работу. Подумайте о том, чтобы записать видео в Loom, чтобы провести их по ней. Подумайте о переработке в серию коммитов; это займёт всего несколько секунд для вашего агента, и вы сможете рассказать историю для людей. Может быть, вы хотите выстроить её в соответствии с вашими трудностями; может быть, лучше показать, как разные слои появляются с каждым коммитом — […]