Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
Что вам мешает задать правила кодстайла и реализовать авточек написанного по задаче кода на кодстайл? Что мешает проработать архитектуру на уровне диаграм и полного описания? И да, согласен что профессия в том виде в котором была изменится. Мы не будем писать код, мы будем задавать правила для его написания и контролировать результат
Сегодня писал фичу руками и прямо кайфанул. Полный контроль, никакого иишного идиотизма, напряжения от рулетки, никакого ревью, исправлений, раздражения.. Да, медленнее значительно. Но код на 100% такой, как мне нужно и удовольствие от работы. Уже забыл что это такое. ЛЛм вроде избавляет от рутины, но с ревью больше устаешь, пытаясь итерациями довести код хотябы до приемлимого уровня. Все говорят про производительность, а про то, что нравится или нет эта новая работа ревьюером, редактором, менеджером ллм - никто. Качество кода/архитектуры и ощущение разработчика тоже важно.
Тоже прихожу к мысли что от ИИ агентов нужно уходить (только как чат использовать для коротких кусков кода). Написание хорошого подробного промпта занимает примерно 30% времени если бы самому с нуля писать, я говорю про настоящий промпт который создает фичу за один проход и потом пару мелких правок остается доделать. То есть хороший подробный промпт это 2-3 часа, потом кодогерация 20 минут, потом ревью и добивка до финального состояния еще полчаса-час, в итоге задача готова за 4 часа, но это всё выматывает настолько (читка тонны чужого кода) что лучше бы я сам потратил на написание кода 10 часов на лайте под музыку. Думаю скоро настоящие разрабы с ИИ (не вайбкодеры кто не смотрит в код) будут получать массовое выгорание очень быстро и скорость разработки будет полностью этим нивелирована.
Система заставила думать. Неприятно, согласен.
Можно оставаться на том же месте и продолжать ничего не менять.
А если серьезно, то это тяжело только на первых порах. Потом придут идеи, как оптимизировать одно. Потом второе, третье. На выходе вообще получится так, что оно само там пыхтит, скребёт, работает, и получен годный результат.
Вы же в универе тоже по началу страдали и думали)
Так проблема упирается в проверку корректности кода созданного ИИ, человек никак быстрее думать не сможет, ему все равно нужно будет смотреть код ИИ. Человек пишет фичу 8 часов, за эти 8 часов он итеративно строку за строй сразу же и валидирует и проверяет код, и это размазывается на 8 часов и ментально человек не устает. Когда нужно отревьюить 8 часов кода, но за один час, это создает очень сильную нагрузку и выгорание уже где-то на пороге при такой нагрузке. То есть без ИИ было просто 8 часов кодинга по ТЗ, стало 3 часа описание подробного тз и 1 часа ревью 8 часового кода, что равно = 11-12 часовая нагрузка.
Если вы не проверяете код за ИИ у меня для вас плохие новости.
Согласен с вами, что время покажет, посмотрим, что из этого выйдет
Как уже сказано было кем-то и где-то. Если вы каждый шаг проверяете за ИИ, значит, вы где-то упустили возможность что-то автоматизировать.
По своему опыту скажу, что ИИ очень круто автоматизируется и обучается. Особенно, клод и его Опусик с Соннетом. Это прям потрясающие ИИ, которые работают идеально, если правильно научить их работать с вашим кодом.
Ещё ни разу не видел, чтобы модель инициативно создавала архитектуру. С цепочкой классов с интерфейсами с правильно огранизованным наследованием, с фасадами, с внедрением зависимостей.. Чтобы логически правильные конструкторы и размещение атрибутов и параметров. Агент всегда решает задачу "здесь и сейчас". Всегда прямолобый код у всех топовых моделей. А если начинать расписывать где какие классы нужны с какими методами, это уже понеслась работа, на этом вайбкодинг заканчивается. И потом, когда сформировано подробное ТЗ с примерами (а это тоже мягко говоря не сразу), все равно огромное количество тупости. От организации методов до передачи данных. Ну логика страдает постоянно. Может загружать отношения по нескольку раз в разных местах или связать классы одной функциональностью (и в чем тогда смысл разделения). Или переменные по тупому организовать или синтаксис из прошлого десятилетия, усложнения в читабельности, постоянные дублирования логики, не использование возможностей фреймворков (и какой тогда в них смысл), фоллбэки везде где только можно, что никакую ошибку не поймать.. Все на многократных исправлениях. А исправления бывают тупее чем первоначальные варианты и это все надо обьяснять, постоянно печатать тк много ссылок, названий итд.. выхватываешь раздражение в итоге и усталость. Я абсолютно точно знаю, что большинство забивает на такие "мелочи" т.к. у самих код всегда был не лучше. Максимум пробегутся глазами вертикально с видом, что все в порядке. Но у меня проекты долгосрочные с постоянным развитием, качество и поддерживаемость кода на первом месте т.к. любые костыли всегда порождают новые и по цепочке. Техдолг сразу себя не проявляет, но это всегда растущие проблемы.
Конечно важно, и даже пока это все использует мало людей, ничего страшного. Но когда начнете проигрывать на рынке со своей производительностью, (не вы конкретно возможно, но в целом) то и выбора не останется.
Производительность за счет качества нужна только тем у кого нет денег или кому плевать на свой продукт. До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Ага им еще пару менеджеров и то шанс что они что-то путное родят, резко падет. А вот когда будет ситуация когда один нормальный разработчик делает 1.5-2-3 раза больше, с «ии» чем нормальный разработчик без «ии», вот тогда будет интересно
В 3 раза больше производительность - это значит он в 3 раза больше ревьюит код, что отнимает время и энергию. А частенько он будет просматривать его вертикально (работает и ладно), без каких-то идей по архитектуре и тд которые часто приходят во время написания руками. Плюс объяснять все это ллм геморойно. Т.е. будет производительность за счет качества. Плюс далеко не всем компаниям нужна "сумасшедшая производительность". Там где важен продукт и его поддержка - качество всегда будет на первом месте. Я не говорю, что ии не нужно юзать. ИИ хорош для коротких явных генераций - например есть абстрактный класс от которого уже один сервис отнаследовался и тебе нужно написать второй точно такой же. Вот такое можно сгенерировать. А вот в разработке прям фич, ну хз, что-то я подустал от такого..
Но ревью когда занимает меньше времени ведь так? Нагенерило посмотрели. Поехали дальше.
>>А частенько он будет просматривать его вертикально (работает и ладно)
И в чем тут проблема? Люди не делают ошибки? Вы не видели багов готовые живут годами? вопрос лишь в том к какой вероятностью она будет их делать, если меньше чем человек-то..
>>без каких-то идей по архитектуре и тд которые часто приходят во время написания руками.
Лично мне идеи по архитектуре проходят вообще в основном не тогда когда я пишу код. Вообще написание кода далеко уже не основное на что уходит время.
Или вы когда приходите на проект который до вас писали пару лет, вы его весь ревьюите? Или все же «верите что оно работает» и начинаете добавлять фичи, улучшать архитектуру? Так и тут.
Самому конечно прикольно писать в тоже люблю, но сейчас в основном делаю уж какие-то совсем интересные задачи. Как я написал выше пока это работает и влияние на рынок не заметно, как только 20-30% начнут активно использовать, то и остальным придется. Компаний которым надо качество где супер задачи и они будут за это готовы переплачивать не так и много.
Нагенерило посмотрели. Поехали дальше.
Если плевать на свой продукт, то наверное да. У меня опыт с ллм немного другой.. Уже писал насчет быстроты. Она не для всех на первом месте. Тем более за счет качества. Мне нужна архитектура, долгосрочная поддержка, качество и получать удовольствие от работы. Работать в соревнованиях на скорость не планирую.
До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Так ведь именно так до LLM и делали :) условному Майкрософту на качество кода вообще с высокой колокольни наплевать. Почти никто же не откажется от Windows или Office, что бы там индусы или LLM ни наворотили.
Ну ладно, программисты в обычном понимании станут вымываться из процесса. Несомненно появятся инструменты верификации кода, написанного ИИ. Вопрос первый: кто напишет эти инструменты? Тот же ИИ? Волк будет служить сторожем в овчарне и охранять овец от самого себя? Вопрос второй: программисты - ладно, они все-таки (пусть не все) как-то перестроятся на новые форматы работы. А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО? Я, к слову, из программистов, так что вроде как проблемы индейцев шерифа волновать не должны, но все-таки любопытно )))
Когда код начинают писать машины: что реально изменится в программировании
Сегодня Вы ( и машина) пишете код на языке высокого уровня, который придуман человеком и для человека. Предположим, что завтра машина придумает язык программирования для машин. Который, опять предположим, будет гораздо эффективнее и безопаснее нынешних языков. Листинг , очень возможно, будет выглядеть так - 0110000101000.... Что реально измениться в программировании? "А скрипач не нужен, родной …"
Не нужно будет читать код. Никто сейчас не лезет в сгенерированный машинный код и не разбирает инструкции. Будете решать задачи "по месту" на один раз без поддержки, и все превратиться в сбор и формализацию требований.
Недавно решил провести эксперимент - вместо ручной пилы взял станок с ЧПУ и сделал деталь почти без ручного вмешательства.
И тут появляется вопрос.
Если станок станет стандартом, кем вообще будет столяр?
В реальности пролетариат перешёл в офисы и в услуги. Несколько сейчас офисным работникам останется хоть какая-то работа, или все будет заменено роботами, это вопрос.
Программу для ЧПУ кто составлял? Вы или сам станок по словесному описанию? Разница же лежит именно в этой плоскости: вы машине свои требования передаёте на формализованном языке (обычное программирование) или на естественном (вайбкодинг).
Для профессионального разработчика (!!! не путать с кодером, вайбкодером и т.п) создание серьезного ПО это по сути и этапам процесс 1в1 проектирования и изготовления сложного технического изделия. Пониманию этого вот уже как полвека. Процесс непосредственного написания программного кода соотносится с этапом изготовления деталей изделия на станках по разработанным техпроцессам. Добавляется только то, что программный код каждой процедуры (не говоря уже о всем проекте) должен быть задокументирован его автором, если он разрабатывался не по заранее строго задокументированному алгоритму и имеет варианты реализации. То есть программный код "пишется" (не люблю это слово в этом контексте) не только для ЭВМ, но или других людей, которые впоследствии должны его быстро воспринять и внести необходимые коррективы для продолжения жизненного цикла ПО. Это первое.
Верификация стороннего программного кода (неважно кем созданного, человеком или ИИ-роботом) по трудоемкости соизмеряется с его разработкой с нуля, начиная с порога в 1000 строк на ЯП. Причём не только требуется его тщательное тестирование, но и документирование всей логики для последующей поддержки другим разработчиком, облегчая ему работу. Если речь пойдёт о работе с десятками и сотнями тысяч строк такого кода, то можно только представить об"ем и сложность такой работы. Причём нужно учитывать, что сама специфика воспринятия и верификации чужого программного кода НЕ проще его разработки и не каждому специалисту под силу делать её квалифицированно. Прежде всего требуется большой практический опыт самостоятельной разработки. Если смотреть с этой позиции, то как говорится, "ещё бабушка сказала" будет ли все проще и лучше. Это второе.
Было бы неоценимо, если бы ИИ-робот по тексту программного кода отдельной процедуры мог бы сделать её проверку и указать на ошибки, уявимости или возможное их появление при работе кода. То есть наоборот: верифицировать программный код разработанный вручную. Тут я двумя ногами за такого бесценного ИИ-помощника. Но как сказано выше, модели ИИ построенные на LLM, могут делать только то, чему обучены, а точнее на что настроены. Смогут их такому их научить (а может уже и умеют !) тогда, как говорится, "пример в студию" и я снимаю шляпу.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда код начинают писать машины: что реально изменится в программировании