Играю в VR, люблю болтать и картоху. Закрываю бэклог на Steam Deck. | YouTube: https://www.youtube.com/@SokolQuest | Telegram: https://t.me/sokolquest
Я думаю речь о том, что если джун будет бездумно работать с нейронкой, то не вырастет в скиллах. Ну и никогда не поймет, что такое хороший код и чем он отличается от просто рабочего.
Похоже на Python, я за него не сильно шарю. Но выглядит как колхоз, да. А где ссылка на реп? В посте чет не видел.
Просто видел много воя от сишников и шарпистов, а вот от джавистов как-то не попадалось. Хотя по моему опыту сишники в целом люди неприятные, может в этом дело.
Я планирую вообще по-хитрому. Я даю одни и те же вводные Claude и Codex, они пишут планы. Потом я показываю им планы друг друга и спрашиваю, какой берем за основу и что в нём дорабатываем. В 99% случаев оба агента сходятся на том, что план Codex лучше, но его нужно дополнить какими-то деталями из плана Claude. В итоге они вместе пишут один итоговый план, пока оба агента не будут довольны. В 9 из 10 случаев получается документ, который полностью описывает реализацию задачи, и при этом примерно так, как я сам бы это делал. В 1 из 10 случаев я вношу какие-то финальные уточнения сам или указываю нейронкам на что-то, что они пропустили. Например, что можно что-то переиспользовать, если немного расширить, или ещё что-то в этом духе. Но такое бывает крайне редко, сейчас они уже и сами прекрасно видят весь контекст и предлагают какие-то улучшалки с точки зрения архитектуры. Плюс у них в базовых инструкциях есть простое указание, которое исключает супер-классы на тысячи строк: «Следуйте принципам SOLID, DRY и KISS». Мелочь вроде, а результат прям реально получается хороший.
Да, я тоже сейчас никого не знаю, кто кодит руками. Это не значит, что таску можно скопипастить, отдать нейронке и закоммитить потом сразу то, что получилось на выходе, но процесс разработки правда кардинально поменялся. Ты теперь больше планируешь и думаешь над действительно сложными вещами, чем программируешь саму логику.
Ну КАК писать нейронки сейчас тоже могут придумать, для этого есть режимы планирования ) Но в целом согласен — человек, который вообще не понимает в программировании, вряд ли получит действительно хороший результат с помощью вайбкодинга. Особенно если он использует всего одну модель. С двумя ещё более-менее можно что-то сделать, но надо прям очень хорошо менеджерить, а это тоже далеко не все умеют.
На сях скорее всего фарш будет. Агенты хорошо натасканы на веб-программировании, а вот с низкоуровневой логикой у них пока ещё так себе получается. Про Java не знаю, не моя область.
Свой репозиторий не дам, так как у меня весь крупняк в привате, но, думаю, можешь походить по реддиту, там люди регулярно делятся какими-то своими опенсорс-решениями, которые они запилили за пару недель под свои хотелки. Только надо смотреть последние, которые были начаты хотя бы после ноября прошлого года.
Ну вот я не знаю какую именно модель и на каком уровне усилий он гонял. Модели, которые в работе использую я, такой фигнёй не страдают уже полгода как минимум. С тех пор как вышел Codex 5.3 и Opus 4.5, ситуация с агентской разработкой очень сильно изменилась.
Да сегодня, на самом деле, очень легко поддерживать нейросетевой код. Если его пишут топовые модели, которые ты предварительно заставляешь планировать, что они будут писать, они выстраивают вполне приличную архитектуру. По крайней мере в веб-проектах. Codex и Claude на усилиях high и выше выдают сегодня результат уверенного миддла. По мере разрастания проекта могут создавать различные god object, конечно, но это и кожаные делают с такой же интенсивностью, пока их явно не попросишь сделать рефакторинг. Единственное, если с нейронкой работает человек, который в программировании вообще ни бум-бум, то я бы советовал использовать сразу 2 разные модели — одну в режиме основного исполнителя, вторую — как проверяющего и ревьюера. Потому что недоработки и дырки 100% будут.
Бездумно — это Ctrl-C/Ctrl-V, без анализа результата и понимания, почему сделано так, а не иначе. Ну а про хороший код я тебе в комментарии не объясню — на эту тему десятки книг написаны. Если бы объяснить разницу между хорошим и плохим кодом было легко и просто, то все вокруг давно бы стали синьорами.