Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток AI и ML доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 41
Что вам мешает задать правила кодстайла и реализовать авточек написанного по задаче кода на кодстайл? Что мешает проработать архитектуру на уровне диаграм и полного описания? И да, согласен что профессия в том виде в котором была изменится. Мы не будем писать код, мы будем задавать правила для его написания и контролировать результат
"Мы не будем писать код, мы будем задавать правила для его написания и контролировать результат" - не хватает картинки с Шариковым
Ничто не мешает сделать так, как вы написали, но чтобы начать делать правильные диаграммы нужно понимать что такое взаимосвязь и как она образуется. Чтобы проработать архитектуру нужно знать чем отличается одна БД от другой, да и вообще что такое база данных нужно знать))) Т.е. знания которые сейчас получают программисты буду дополняться умениями работать с ИИ инструментами. И на выходе получаем программиста, который уже не будет писать код из головы (и да, именно здесь и будет ускорение), но также этот человек составляет аромат (здесь добавляем время). А также этот человек будет ответственным за полученный результат - ответственность за результат мы же не снимаем с человека?
Сегодня писал фичу руками и прямо кайфанул. Полный контроль, никакого иишного идиотизма, напряжения от рулетки, никакого ревью, исправлений, раздражения.. Да, медленнее значительно. Но код на 100% такой, как мне нужно и удовольствие от работы. Уже забыл что это такое. ЛЛм вроде избавляет от рутины, но с ревью больше устаешь, пытаясь итерациями довести код хотябы до приемлимого уровня. Все говорят про производительность, а про то, что нравится или нет эта новая работа ревьюером, редактором, менеджером ллм - никто. Качество кода/архитектуры и ощущение разработчика тоже важно.
Тоже прихожу к мысли что от ИИ агентов нужно уходить (только как чат использовать для коротких кусков кода). Написание хорошого подробного промпта занимает примерно 30% времени если бы самому с нуля писать, я говорю про настоящий промпт который создает фичу за один проход и потом пару мелких правок остается доделать. То есть хороший подробный промпт это 2-3 часа, потом кодогерация 20 минут, потом ревью и добивка до финального состояния еще полчаса-час, в итоге задача готова за 4 часа, но это всё выматывает настолько (читка тонны чужого кода) что лучше бы я сам потратил на написание кода 10 часов на лайте под музыку. Думаю скоро настоящие разрабы с ИИ (не вайбкодеры кто не смотрит в код) будут получать массовое выгорание очень быстро и скорость разработки будет полностью этим нивелирована.
Система заставила думать. Неприятно, согласен.
Можно оставаться на том же месте и продолжать ничего не менять.
А если серьезно, то это тяжело только на первых порах. Потом придут идеи, как оптимизировать одно. Потом второе, третье. На выходе вообще получится так, что оно само там пыхтит, скребёт, работает, и получен годный результат.
Вы же в универе тоже по началу страдали и думали)
Так проблема упирается в проверку корректности кода созданного ИИ, человек никак быстрее думать не сможет, ему все равно нужно будет смотреть код ИИ. Человек пишет фичу 8 часов, за эти 8 часов он итеративно строку за строй сразу же и валидирует и проверяет код, и это размазывается на 8 часов и ментально человек не устает. Когда нужно отревьюить 8 часов кода, но за один час, это создает очень сильную нагрузку и выгорание уже где-то на пороге при такой нагрузке. То есть без ИИ было просто 8 часов кодинга по ТЗ, стало 3 часа описание подробного тз и 1 часа ревью 8 часового кода, что равно = 11-12 часовая нагрузка.
Если вы не проверяете код за ИИ у меня для вас плохие новости.
Согласен с вами, что время покажет, посмотрим, что из этого выйдет
Как уже сказано было кем-то и где-то. Если вы каждый шаг проверяете за ИИ, значит, вы где-то упустили возможность что-то автоматизировать.
По своему опыту скажу, что ИИ очень круто автоматизируется и обучается. Особенно, клод и его Опусик с Соннетом. Это прям потрясающие ИИ, которые работают идеально, если правильно научить их работать с вашим кодом.
Ещё ни разу не видел, чтобы модель инициативно создавала архитектуру. С цепочкой классов с интерфейсами с правильно огранизованным наследованием, с фасадами, с внедрением зависимостей.. Чтобы логически правильные конструкторы и размещение атрибутов и параметров. Агент всегда решает задачу "здесь и сейчас". Всегда прямолобый код у всех топовых моделей. А если начинать расписывать где какие классы нужны с какими методами, это уже понеслась работа, на этом вайбкодинг заканчивается. И потом, когда сформировано подробное ТЗ с примерами (а это тоже мягко говоря не сразу), все равно огромное количество тупости. От организации методов до передачи данных. Ну логика страдает постоянно. Может загружать отношения по нескольку раз в разных местах или связать классы одной функциональностью (и в чем тогда смысл разделения). Или переменные по тупому организовать или синтаксис из прошлого десятилетия, усложнения в читабельности, постоянные дублирования логики, не использование возможностей фреймворков (и какой тогда в них смысл), фоллбэки везде где только можно, что никакую ошибку не поймать.. Все на многократных исправлениях. А исправления бывают тупее чем первоначальные варианты и это все надо обьяснять, постоянно печатать тк много ссылок, названий итд.. выхватываешь раздражение в итоге и усталость. Я абсолютно точно знаю, что большинство забивает на такие "мелочи" т.к. у самих код всегда был не лучше. Максимум пробегутся глазами вертикально с видом, что все в порядке. Но у меня проекты долгосрочные с постоянным развитием, качество и поддерживаемость кода на первом месте т.к. любые костыли всегда порождают новые и по цепочке. Техдолг сразу себя не проявляет, но это всегда растущие проблемы.
ИИ лучше использовать как Т9 для кода. В таком случае как раз нейронка используется для генерации, а не для создания архитектуры.
Конечно важно, и даже пока это все использует мало людей, ничего страшного. Но когда начнете проигрывать на рынке со своей производительностью, (не вы конкретно возможно, но в целом) то и выбора не останется.
Производительность за счет качества нужна только тем у кого нет денег или кому плевать на свой продукт. До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Ага им еще пару менеджеров и то шанс что они что-то путное родят, резко падет. А вот когда будет ситуация когда один нормальный разработчик делает 1.5-2-3 раза больше, с «ии» чем нормальный разработчик без «ии», вот тогда будет интересно
В 3 раза больше производительность - это значит он в 3 раза больше ревьюит код, что отнимает время и энергию. А частенько он будет просматривать его вертикально (работает и ладно), без каких-то идей по архитектуре и тд которые часто приходят во время написания руками. Плюс объяснять все это ллм геморойно. Т.е. будет производительность за счет качества. Плюс далеко не всем компаниям нужна "сумасшедшая производительность". Там где важен продукт и его поддержка - качество всегда будет на первом месте. Я не говорю, что ии не нужно юзать. ИИ хорош для коротких явных генераций - например есть абстрактный класс от которого уже один сервис отнаследовался и тебе нужно написать второй точно такой же. Вот такое можно сгенерировать. А вот в разработке прям фич, ну хз, что-то я подустал от такого..
Но ревью когда занимает меньше времени ведь так? Нагенерило посмотрели. Поехали дальше.
>>А частенько он будет просматривать его вертикально (работает и ладно)
И в чем тут проблема? Люди не делают ошибки? Вы не видели багов готовые живут годами? вопрос лишь в том к какой вероятностью она будет их делать, если меньше чем человек-то..
>>без каких-то идей по архитектуре и тд которые часто приходят во время написания руками.
Лично мне идеи по архитектуре проходят вообще в основном не тогда когда я пишу код. Вообще написание кода далеко уже не основное на что уходит время.
Или вы когда приходите на проект который до вас писали пару лет, вы его весь ревьюите? Или все же «верите что оно работает» и начинаете добавлять фичи, улучшать архитектуру? Так и тут.
Самому конечно прикольно писать в тоже люблю, но сейчас в основном делаю уж какие-то совсем интересные задачи. Как я написал выше пока это работает и влияние на рынок не заметно, как только 20-30% начнут активно использовать, то и остальным придется. Компаний которым надо качество где супер задачи и они будут за это готовы переплачивать не так и много.
Нагенерило посмотрели. Поехали дальше.
Если плевать на свой продукт, то наверное да. У меня опыт с ллм немного другой.. Уже писал насчет быстроты. Она не для всех на первом месте. Тем более за счет качества. Мне нужна архитектура, долгосрочная поддержка, качество и получать удовольствие от работы. Работать в соревнованиях на скорость не планирую.
Кто ратует только за быстроту создания программного кода с помощью текущих возможностей автогенераторов в ущерб перечисленных Вами требований, то, как говорится, бог им в помощь. Ответственные разработчики это прекрасно понимают и полностью разделяют Вашу позицию, а на поднятый по этой теме хайп смотрят не иначе как на попытки (сознательные или нет - это отдельная тема) их деквалифицирования (профессионального обнуления) и лишения способности самостоятельно думать и принимать решения.
Так вот то что качество потеряется, это лишь домыслы. если на этапе нагенерил-посмотрел что-то не устроило, никто не мешает «исправить». И со временем исправлять приходится все реже.
А архитектура продумывается и так, а написание кода лишь реализация.
Я же не говорю что оно заменяет разработчика, думать то всеравно нужно, а вот потребность написания кода руками потихоньку отпадет все больше и больше. И именно это повлияет на рынок
Верификация стороннего программного кода (неважно кем созданного, человеком или ИИ-роботом) по трудоемкости соизмеряется с его разработкой с нуля, начиная с порога в 1000 строк на ЯП. Причём не только требуется его тщательное тестирование, но и документирование всей логики для последующей поддержки другим разработчиком, облегчая ему работу. Если речь пойдёт о десятках и сотнях тысяч строк такого кода, то можно только представить об"ем и сложность такой работы. Причём нужно учитывать, что сама специфика воспринятия и верификации чужого программного кода НЕ проще (а в некоторых случаях и сложнее) его непосредственной разработки и НЕ каждому специалисту под силу делать её квалифицированно. Прежде всего требуется большой практический опыт именно самостоятельной разработки. Поэтому, если смотреть с этих профессиональных позиций, то как говорится, "ещё бабушка на двое сказала" будет ли все проще и лучше работать с таким готовым "на блюдечке" кодом.
Было бы точно и значительно лучше ровно наоборот: текст программного кода разработанный человеком проверяет ИИ-робот, находит ошибки и выявляет уязвимости. Вот тогда это действительно бы ускоряло процессы отладки и тестирования, а в целом сокращало время разработки сложного ПО.
Так зачем вам верифицировать весь код? Да еще и сразу?
Никто не же говорит о сценарии что вот вам «ии» за полчаса нагерило 100500 строк кода по вашему описанию «хочу чтоб было круто» и вы сидите полгода это разгребаете.
Точно так же разрабатывается проект итеративно, с продумыванием архитектуры, отладкой и тестированием (на которые время будет в обоих сценариях тратится), но с «ии» будет потрачено на реализацию (вместо условно 12 месяцев) 10, 9, 6.. в зависимости от того насколько конкретный разработчик повысил свою производительность. И все это без какой либо потери качества.
Вы, уважаемый, свой костюм на других пытаетесь одеть, который им совсем не подходит. Если разрабатываете софт в расчёте что сами его будете до конца поддерживать или он исключительно только для вас, тогда вопросов нет. Используйте на здоровье все что вам нравится. Но судя по вашему толкованию, лексике и жаргону, вы не работали в команде профессионалов, которая проектирует и разрабатывает софт измеряемый в сотнях тысяч строк ЯП, который работает и поддерживается с функциональным расширением более 10 лет. Весь процесс его разработки повторяет 1в1 процесс проектирования и разработки сложного технического изделия и его жизненного цикла, где непосредственно написание кода программой единицы (класса, модуля, процедуры, функции) соотносится с этапом изготовления узла или детали на станке по готовому технологическому процессу. При поломке детали есть документация техпроцесса и по ней при необходимости ЛЮБОЙ рабочий сразу изготовит новую. ИИ-робот по вашему заданию сгенерировал программный код. Он может быть верным, никто не спорит, но надо провести его тщательное тестирование. Раз ставили задачу, то сами и проверяете полученный код и, если все на ВАШ взгяд Ок, то отдаёте его на сборку БЕЗ внутренней документации логики его работы. Ведь верификации не было, "зачем верифицировать весь код", верно? Проходит время, софт у заказчика работает нормально, но вдруг через год или даже полгода, "вылетает" run-time rroror (качество надёжности работы). Если в системе заложен собственный отладочный механизм активации вызовов программных единиц (стек вызовов), то вы без труда локализуете процедуру или функцию. Для такого механизма необходимо, чтобы каждая процедура в начале работы заносила в стек свое имя, значения вх. параметров, а на выходе Ок или причину ошибки. Никакой генератор это вам не сделает, я уже не говорю о том, что ему невдомек в начале процедуры делать проверку значений входных параметров на их допустимость для её успешной работы, сформировать текст сообщения об аварийном завершении и обеспечить выход НЕ допуская run-time error. Но Вы, уважаемый, уже в другой конторе по новой "генерите коды", а кто и как за вас будет разбираться в Вашем оставленном наследстве, которое НЕ документировано, так как её верификация не проводилась? Правда, повторяю, если бы это была команда профессионалов разработчиков ПО, то вам бы вменялась обязанность документирование кода, который хотя и был создан с помощью ИИ-генератора, но все равно автором считаетесь Вы как ответственность за него лежит на Вас, а не на генераторе. Самое главное тут: другому программисту нужно срочно (да да! ) быстро разобраться в вашем коде и устранить ошибку. На память же вы ему оставили только текст промта по которому ИИ-генератор и выдал на "блюдечке" этот самый злаполучный код.
Вывод. Если код разработан с помощью автогенераторов, то он все равно должен быть верифицирован, при необходимости доработан и обязательно документирован. Для этого генерируемые программные единицы должны быть как можно меньше, в диапазоне от 50 максимум 100 строк ЯП. А как уже было сказано выше, процесс восприятия и верификации чужого программного кода бывает НЕ проще, а может и сложнее чем его разработка самостоятельно и не каждый специалист сможет эту работу выполнить квалифицированно.
Да, и напоследок, если можно, небольшой совет: если Вы планируете заниматься разработкой серьёзного ПО, а не оставаться и мыслить на уровне обычного "кодера", то вам нужно срочно дообразоваться в этой сфере, например, почитать книгу Ф. Брукса "Как создаются и разрабатываются программные комплексы" или что-то вроде этого по разработке ПО.
Вы конечно все интересно написали и по делу. Вот только все больше напоминаете луддита. В разработках прям очень-очень-очень крупных систем я не участвовал, но вполне себе крупных и высоконагруженных дело было.
Никто не отрицает существования проектов которые «10 лет и прочее» но проектов которые за 10 лет переписывались по 3 раза фактически с 0, даже в крупных компаниях я видел намного больше.
и опять же не очень понимаю что вы пытаетесь доказать, точнее пытаетесь но совсем не то о чем я говорю. Если вы уникальный специалист в уникальный области, со 100 летними проектами, то кончено пишите код руками сколько влезет. Я же пишу именно про рынок, что люди не использующие «ии» будут проигрывать тем кто использует. (За редким исключением)
>>Никакой генератор это вам не сделает, я уже не говорю о том, что ему невдомек в начале процедуры делать проверку значений входных параметров на их допустимость для её успешной работы, сформировать текст сообщения об аварийном завершении и обеспечить выход НЕ допуская run-time error.
Что за бред вообще, если при разработке есть такое требование то нет разницы как я его реализую, руками написав нужный инфраструктурный код или «нагенерив» его. Но в целом это не имеет значения.
А так, пока вы упорно отрицаете возможность повышения производительности разработки без потери качества, весь мир движется в этом направлении
https://habr.com/ru/news/1011730/
Так что даже спорить не интересно, а учитывая и постоянный прогресс, думаю очень скоро увидим «кто был прав»
Против лгунов и луддизм с доками будет очень кстати.
Пмсм всё идёт к "одноразовому" коду. 1000-10000-100000 строк? Никто их "вручную" проверять не будет. Тесты не проходит? Сломалось через неделю-месяц-год прода? В корзину его. LLM-ка напишет новый и протестирует его за час. Тем более, что за год скорость написания возрастёт немеряно. И новый код с тестами будет занимать пару-тройку минут.
До ллм можно было нанять за почтибесплатно 10 начинающих "индусов" вместо одного нормального разработчика - было бы тоже очень производительно.
Так ведь именно так до LLM и делали :) условному Майкрософту на качество кода вообще с высокой колокольни наплевать. Почти никто же не откажется от Windows или Office, что бы там индусы или LLM ни наворотили.
Ну ладно, программисты в обычном понимании станут вымываться из процесса. Несомненно появятся инструменты верификации кода, написанного ИИ. Вопрос первый: кто напишет эти инструменты? Тот же ИИ? Волк будет служить сторожем в овчарне и охранять овец от самого себя? Вопрос второй: программисты - ладно, они все-таки (пусть не все) как-то перестроятся на новые форматы работы. А что делать продакт-менеджерам, аджайл-кришнаитам и вообще - всей той обвязке, что существует (пока) в разработке ПО? Я, к слову, из программистов, так что вроде как проблемы индейцев шерифа волновать не должны, но все-таки любопытно )))
Когда код начинают писать машины: что реально изменится в программировании
Сегодня Вы ( и машина) пишете код на языке высокого уровня, который придуман человеком и для человека. Предположим, что завтра машина придумает язык программирования для машин. Который, опять предположим, будет гораздо эффективнее и безопаснее нынешних языков. Листинг , очень возможно, будет выглядеть так - 0110000101000.... Что реально измениться в программировании? "А скрипач не нужен, родной …"
Не нужно будет читать код. Никто сейчас не лезет в сгенерированный машинный код и не разбирает инструкции. Будете решать задачи "по месту" на один раз без поддержки, и все превратиться в сбор и формализацию требований.
Недавно решил провести эксперимент - вместо ручной пилы взял станок с ЧПУ и сделал деталь почти без ручного вмешательства.
И тут появляется вопрос.
Если станок станет стандартом, кем вообще будет столяр?
В реальности пролетариат перешёл в офисы и в услуги. Несколько сейчас офисным работникам останется хоть какая-то работа, или все будет заменено роботами, это вопрос.
Программу для ЧПУ кто составлял? Вы или сам станок по словесному описанию? Разница же лежит именно в этой плоскости: вы машине свои требования передаёте на формализованном языке (обычное программирование) или на естественном (вайбкодинг).
взял и сделал :)
https://vkvideo.ru/video-178399692_456239269
Для профессионального разработчика (!!! не путать с кодером, вайбкодером и т.п) создание серьезного ПО это по сути и этапам процесс 1в1 проектирования и изготовления сложного технического изделия. Пониманию этого вот уже как полвека. Процесс непосредственного написания программного кода соотносится с этапом изготовления деталей изделия на станках по разработанным техпроцессам. Добавляется только то, что программный код каждой процедуры (не говоря уже о всем проекте) должен быть задокументирован его автором, если он разрабатывался не по заранее строго задокументированному алгоритму и имеет варианты реализации. То есть программный код "пишется" (не люблю это слово в этом контексте) не только для ЭВМ, но или других людей, которые впоследствии должны его быстро воспринять и внести необходимые коррективы для продолжения жизненного цикла ПО. Это первое.
Верификация стороннего программного кода (неважно кем созданного, человеком или ИИ-роботом) по трудоемкости соизмеряется с его разработкой с нуля, начиная с порога в 1000 строк на ЯП. Причём не только требуется его тщательное тестирование, но и документирование всей логики для последующей поддержки другим разработчиком, облегчая ему работу. Если речь пойдёт о работе с десятками и сотнями тысяч строк такого кода, то можно только представить об"ем и сложность такой работы. Причём нужно учитывать, что сама специфика воспринятия и верификации чужого программного кода НЕ проще его разработки и не каждому специалисту под силу делать её квалифицированно. Прежде всего требуется большой практический опыт самостоятельной разработки. Если смотреть с этой позиции, то как говорится, "ещё бабушка сказала" будет ли все проще и лучше. Это второе.
Было бы неоценимо, если бы ИИ-робот по тексту программного кода отдельной процедуры мог бы сделать её проверку и указать на ошибки, уявимости или возможное их появление при работе кода. То есть наоборот: верифицировать программный код разработанный вручную. Тут я двумя ногами за такого бесценного ИИ-помощника. Но как сказано выше, модели ИИ построенные на LLM, могут делать только то, чему обучены, а точнее на что настроены. Смогут их такому их научить (а может уже и умеют !) тогда, как говорится, "пример в студию" и я снимаю шляпу.
Пока ничего принципиально не меняется. Раньше замысел нужно было описывать кодом, сейчас замысел и код надо описывать словами. Суть не меняется - нужно производить как можно быстрее работающий код, так чтобы не терять контроль и не утонуть в хаосе и неопределенности.
До тех пор, пока АИ недостаточно умён, чтобы взять на себя всестороннюю ответственность за развитие продукта, программист по сути занимается тем же самым что и раньше, пропуская через мозг понимание что как работает и куда это все идёт.
Что возможно станет приятнее, это укрупнение задач отдельного разработчика, когда целую фитчу или модуль пишет один человек. Раньше наниматели старались этого избежать, опасаясь рисков - медленно, риск прочесть если человек уволится. Теперь становится быстрее и с АИ намного легче оперировать чужим кодом.
И ещё - невероятно дешевые POC. Теперь вместо того чтобы просить коллегу рассмотреть возможность что то добавить в его модуль я могу добавить это сам с АИ за пол часа и прийти на митинг с готовым вариантом решения.
Представьте: я tech lead нескольких команд. 30 человек пишут ТЗ, код, тесты. Я выстраиваю процесс, управляю им, оцениваю и принимаю результат.
А теперь заменяем людей на AI-агентов. Что меняется?
Удивительно мало. Агентам так же нужны чёткие спецификации, декомпозиция задач, критерии приёмки. Так же нужен code review. Так же нужен кто-то, кто видит систему целиком и принимает архитектурные решения.
Что реально меняется: скорость итераций и цена ошибки. Агент напишет 1000 строк за минуту — но если задача поставлена криво, за ту же минуту сгенерирует 1000 строк мусора. Человек остановится и спросит. Агент — нет.
И тут выясняется, что всё, чему нас учил классический software engineering, работает ещё лучше с агентами: формализованные роли (аналитик, архитектор, разработчик, QA — только теперь это агенты), workflow с этапами и валидацией на каждом переходе, короткий контекст вместо монолитного промпта, автоматические проверки качества перед тем как результат пойдёт дальше по цепочке.
Кто умел управлять командой из 30 человек — справится и с 30 агентами. Кто не умел — получит хаос быстрее, чем раньше.
Читать код — это вообще важный навык, независимо от нейросетей.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Когда код начинают писать машины: что реально изменится в программировании