Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
У меня только один вопрос родился как у новичка в программировании.
1. Я могу запрограммировать много задачь, но защитить данный не смогу наверно и в одной из всех задачь с которыми столкнусь.
Как научиться программировать так чтобы данные с которыми я работаю не утекали и сколько примерно времени нужно чтобы этому научиться?
Вот мой единственный и подходящий под статью вопрос. И да ИИ так программировать никогда не сможет с учетом того что заказывать программу будут такие криворучки как я и подобные мне специалисты вайбкодеры.
В нынешних реалиях, чтобы научиться программировать - для начала бросить вайбкодить.
Как научиться программировать так чтобы данные с которыми я работаю не утекали и сколько примерно времени нужно чтобы этому научиться?
Не пытаться переложить свою работу на условного клода, думать самому. А ИИ использовать только как справочник, максимум как средство быстро накидать какой-то совсем тривиальный лапшекод, который просто долго и неинтересно писать самому.
Ну вот, есть самое главное – осознание, что ты криворучка (кстати, почему вы пишете «задачь», но не «криворучька»? Выглядит недоработкой ☺). А значит, надо выпрямлять руки, то есть учиться. И учиться долго, систематически. Нет царского пути в геометрию.
Ответ душнилы - ты не можешь.
Область знаний становится больше и сложнее, причем скорость этого скорее всего превышает скорость обучения.
По факту, ты, либо учишься на ошибках других, либо допускаешь их сам и учишься. Есть еще одно направление обучения - встать на место злоумышленника, и пытаться 'взламывать' свои решения еще до их внедрения.
Ровно то же происходит и с проектами, которые пишут кожаные мешки, особенно когда этих мешков много и они работают одновременно. Всё постоянно пытается взорваться и медленно ползёт на велосипеде, давя на педали костылями. Просто LLM дали возможность каждому почувствовать себя менеджером большой команды, пилящей большой продукт.
У Вас вероятность, что человек глючит - 0.15, а что нейронка - 0.03. Все дальше можно не считать. Человека на пенсию, он и есть главный багодел тут, обезьяна с гранатой. Причем оно ведь и в реальности так - разработчики пишут код с ошибками, потом долго сидят под отладчиком и хмурят брови, потом пишут тесты, потом отдают в отдел QA, потом в отдел проверки безопасности, потом переделывают. И вот тогда получается более менее надежный код.
И на каждом этапе тоже есть вероятность допустить ошибку. Вот задача Anthropic сделать вероятность ошибок Claude Code < вероятности ошибок человека.
Цепочку разработки с проверкой качества вайбкодеры не освоили в этом их проблема. Решений может быть два на этот случай:
Это нужно активно продвигать на курсах вайбкодинга.
Вшить проактивные навыки проверок качества на уровне Claude code и сделать их обязательными.
Пока до этого далеко, но со временем придут к какому-то решению.
а пустые тесты которые всегда проходят это и есть проверка качества от llm
Проверять тоже нейронкой? Она не находит половину косяков. Из разумного решения - языки со строгой типизацией плюс линтеры, сканеры и прочие валидаторы. Но вот проверять логику не умеет. Возможно когда-то научится, да.
Зато человек лучше пишет не-ошибочный код, что уже перевешивает провал по ошибочному. Разве нет? Зависит от ситуации, но в общем случае?
И проверяет ошибочный и не-ошибочный тоже качественнее. Впрочем, медленнее, тут не поспоришь. А насчёт дешевизны нужно считать — сколько в мире уходит на людей / сколько в мире людей — и сравнивать — сколько в мире уходит на ИИ X / сколько в мире экземпляров (пользователей?) этого ИИ. В долларах.
К слову, вовсе не интересно, сколько там уходит на электроэнергию у ИИ — нам важны токены/подписки в сравнении с ЗП, а не сколько и на что из этой прибыли тратиться (человек тоже себе покушать покупает ;).
В те стародавние времена, когда ИИ не использовалось в разработке) мы много раз были свидетелями маштабных факапов, когда разработчик перепутал терминалы, на автомате скопировал не ту команду, просто по усталости или запарке не протестировал новый код. Мы видели это в публичном поле, на примерах коллег и собственном опыте. То что вы рассчитали в статье как 4.5 критические ошибки на миллион программистов, которые пишут по 20 коммитов в день - это неимоверный, непостижимый уровень качества. Сравните с любыми открытыми отчётами по качеству кодовых баз.
Хватит пороть чушь про общую деградацию. Есть отдельно безответственность, которая вкупе с некомпетентностью является главной причиной ошибок ПО. И есть просто инструменты. ИИ это инструмент. Да, кода стало больше. Но я ответственно заявляю, что среднее качество этого кода ВЫШЕ среднего качества кода 10-20 лет назад. Именно среднего, раз уж мы берем общую температуру по индустрии.
Давайте уже наберемся мужества признать, что всеобщая доступность такого инструмента - это не проблема новичков, которым снизили порог входа. Это не проблема пользователей, которые получают результат сразу. Это проблема опытных разработчиков. На них (на нас?) ответственность задавать планку качества и внятно определять критерии этой планки. Не ныть в духе "хоспаде, нас завалят нейрослопом", а обучать новичков, показывать проблемные места коде, развивать инструменты валидации. Надо принять достойно смерть профессии в её первоначальном понимании.
И да - у меня около 12 лет опыта разработки и мне до боли в жопе и запястьях надоел ручной труд. Вы считаете всех вокруг обезьянами с гранатой? Я считаю луддитов от ИИ престарелыми гиббонами, не освоившими базовый инженерный принцип - надо решать проблемы оптимальными способами.
p/s/ извиняюсь за излишнюю эмоциональность, я тут обращаюсь не лично к автору, а скорее к устоявшемуся мнению, которые расцениваю как в корне неверное
повышение количества низкокачественной рабочей силы породило невероятно неэффективный код.
что сделает повышение количества сгенерированного кода? умножит неэффективность на два? возведет в степень? или наоборот
повышение количества низкокачественной рабочей силы породило невероятно неэффективный код
Такое уже было и были сделаны выводы. Если вам не нравится пользоваться неэффективным софтом - пользуйтесь эффективным. Если вам не нравится что кто-то другой пользуется неэффективным софтом - ну, во-первых, это не ваше дело, во-вторых, а в чем предложение? Вот сейчас половина современного софта написана поверх виртуальных машин, electron-ов и энтерпрайзных фрейморков. Это ИИ сделал? Да ИИ наш главный союзник в расчистке этих авгиевых конюшен.
что сделает повышение количества сгенерированного кода?
Как минимум, больше кода значит больше выбора. Какие последствия того, что выбора больше - думайте сами.
Да, я гордо зову себя луддитом. В оригинальном смысле, не в ругательном. Да, существуют технологии, которые не решают реальные проблемы, а только создают новые (часто в виде эрозии трудовых прав).
Цитата на египетской стеле из гробницы Хепи (ок. 3000 лет до н.э., найденной в Гизе)
"Мы отказались от традиций наших предков... дети больше не слушаются... всё рушится, и нет того, кто бы возродил порядок".
Существует множество примеров из истории, в которых можно найти такой же страх. Автомобили заменили лошадей, лампы заменили свечи, телефон - письма, интернет - книги и т.д.
Сейчас, как и тогда, многие люди боятся признать новую эру, но она реально наступает. ИИ внедряется не только в нашу жизнь, делая её проще, но и в производство, бизнес или сельское хозяйство. ИИ заменяет целые профессии. Страшно... нет. Мир изменился, надо к нему приспосабливаться, находить новые ниши.
P.S. Развивать голову никто не отменял)
ИИ заменяет целые профессии.
Можете привести хотя бы несколько примеров, где ИИ заменил целую профессию? Пока ИИ неспособен быть заменой даже оператора чата поддержки.
Развивать голову никто не отменял
Да, учитесь думать своей головой, а не просто верить обещаниям продавцов лопат, которые рекламируют лопаты)
Перестать писать код надо было еще лет 15 назад. Совсем. А то удивляются, что "Hello world" "гигабайты" весит. Уже и так писали одно и то же по сотому кругу. Ну вот теперь это ИИ будет делать.
Цифры с потолка, методика ещё из какой-то части тела, но результаты почему-то нравятся и обсуждаются всерьёз. С чего бы вдруг проекту расползаться куда-то, а уборщицам увольняться? Что мешает покрывать тестами, ревьюить ревьюерами и рефакторить проект не за месяцы, как это сделала бы команда программистов, а за часы с LLM-кой? И это, учитывая, что те LLM, что есть сейчас это самые тупые LLM из всех, что будут созданы в будущем. Firefox поддерживается большой командой, благо Google спонсирует, но LLM нашла за месяц (а реальное время работы, думаю, измеряется в нескольких днях) дырок больше, чем они все за год. Но вот откуда-то идея про расползающиеся проекты. Конечно, пока ими занимаются жертвы курсов по успешному успеху, ожидать чего-то серьёзного от проектов не стоит. Но этот этап быстро проходит и максимум, что может развалить менеджер - проект по учёту калорий в съеденной еде, то бишь личные проекты.
Когда будут "самые умные", программисты уже точно не будут нужны.
Да, нашло дырки и не только в firefox. Только вот если начать делать “plz fix”, то дырок станет больше. LLM не умеет думать и решает проблему самым простым способом, не рассчитывая на то, что это еще и поддерживать потом надо. Код постоянно дублируется, потом в этих дублях находится ошибка, а фиксится только в части из них. Вынести дубли в отдельную функцию? Выносить куски в отдельные модули? Не, надо все в один файл сложить и норм. Работает же, тесты проходит…
Код постоянно дублируется
Бывало раньше, но давно такого уже не наблюдаю. В любом случае, один промпт (если его уже не добавили в системном промпте или где-то в обвязке) и модель найдет и поулучшает что надо. Возможно, не всё будет идеально, но и люди не пишут идеально. А вообще по большому счёту важно да, чтоб работало и какие-то неоптимальности кода, ни на что особо не влияющие, не так и важны. Вот я писал себе телеграм юзербота на Пайтоне, которого особо и не знаю и Telethon именно исходя из того, чтобы он просто выполнил мне нужную задачу. Под 100 килобайт кода, 2650 строк и довольно удобная чисто практическая утилита анализирующая группы по заданным правилам и собирающая нужную информацию. В коде не вижу явных дублирований и струкрура на вид простая, если прям сильно надо будет, разберусь. Но мне нужна выполняемая кодом работа, а не код. В рабочем коде, конечно, всё контролирую, иногда вижу неоптимальности, избыточности, уточняю что это реально ненужные вещи, а не что-то чего я не понимаю, прошу удалить лишнее. Вполне нормальное выходит.
Для простых проектов без дальнейшего развития получается неплохо. Для своих поделок у меня получается вполне по более-менее простой постановке задачи сгенерировать работающий код. И он даже делает что надо. А вот если заглянуть внутрь, то там много странного: то колонки в таблицах, которые не используются, потому что другая ошибка позволяет это обойти, то шелл скрипты, со встроенным питоном (python3 << EOF..EOF). Если где-то повтроряется требование, то реализаций получается две. Например проверка email на валидность и приведение его в канонический формат дублируется каждый раз. Если перефразировать пословицу: выглядит как код, работает как код, значит код. Но хромой.
Допустим глючит модель с вероятностью P_{err} = 0.03 , при этом деструктивные глюки бывают с вероятностью P_{destr} = 0.001, обвязка клода пропустит это с вероятностью P_{miss} = 0.05 и абсолютно правый, но усталый от нейрослоповых гоблинов оператор, пропустит ошибку с вероятностью P_{human} = 0.15.
А давайте допустим не 0.03, а 0.99. Или 0.0000000001. Что это "аналитика" на случайных числах? И этот человек еще жалуется на LLM.
Автору спасибо. Хотя бы за попытку как то обсчитать процесс генерации кода с помощью ИИ и за то, что дал направление поразмыслить как этот процесс в принципе сначала измерять, а потом уже контролировать.
Контроль, в принципе, существует. Можно детерменировать выхлоп ИИ через SDD и TDD по спекам. Будет выглядеть как код на естественном языке со всеми плюсами и минусами.
тут смысл не в том, чтоб он "выгладел как код на естественном языке", а в том, чтоб его можно было сопровождать на всех этапах эксплуатации. Иначе он будет просто одноразовым
Ну да, вполне себе сопровождаем. Только чем подробнее будет писаться эта спека, тем более она будет ммм… кодом :)
# Endpoint: Change Email
**Метод:** `POST /user/{uid}/change_email`
## Бизнес-логика и алгоритм
1. **Подготовка:**
- Канонизировать `new_email` согласно [R001-email.md].
2. **Проверка конфликтов:**
- Поиск в БД: `SELECT id FROM users WHERE email = {new_email}`.
- Если найден другой `id` -> `409 Conflict`.
3. **Атомарная транзакция:**
- Получить `old_email` текущего пользователя.
- Выполнить `UPDATE users SET email = {new_email} WHERE id = {uid}`.
4. **Управление состоянием кеша (Post-commit):**
- Удалить основной профиль: `DEL user:profile:{uid}`.
- Удалить старый индекс почты: `DEL email_to_id:{old_email}`.
- Обновить новый индекс почты: `SET email_to_id:{new_email} -> {uid}`.
## Обработка ошибок
- При любой ошибке БД транзакция откатывается, кеш не трогаем.
Что-то мне это неуловимо напоминает ))
Примерно так нормальные архитекторы (не вкатуны после курсов успешного успеха) пишут ТЗ на разработку ПО, дополняя блок-схемами с описанием процессов. Теперь в Markdawn вместо MS World. Однако проблему поддержки и сопровождения кода это не отменяет. Я уже несколько раз сталкивался с запросом от QA: а пришли мне промпт, которым это было сделано, потому что головой и руками такое тестами намного сложнее обложить. И еще. Код, написанный человеком, практически все LLM очень плохо понимают, в отличии от сгенерированного - и наоборот. И это, как мне кажется, намного более стремно, так как пошло расхождение логик и как бы эти процессы вразнос не пошли.
Ну так SDD придумали задолго до ИИ истерик. :) Правда оно было сильно более формализовано.
Код написанный опытным разработчиком обычно чуть более избыточен, чем надо. Но при этом сильно более читаем. То есть у тебя нет конструкций типа if (!!(checkup?do_this():do_that()) && (a == 1) && ((b == 10) && (c < other_func()))) {...}, а все расписано через отдельные понятно названные переменные и отдельные проверки.
А можно пояснить про расхождение логик? Не оч понял тейка.
Это когда подключаешь готовый проект, написанный людьми, и даешь задачу провести анализ и добавить фичу. В большинстве случаев задача просто невыполнимая в лоб. Для ее решения приходится проводить глубокий рефакторинг кода с написанием md То есть фактически надо тратить время на перевод, уж не знаю насколько точно я это формулирую. Однако, если сделать тоже самое с вайбкодинговым проектом, то каким то волшебным образом таких плясок с бубном не требует. Даже если это не с гитхаба качалось. И такое у меня часто... и объяснений этому я пока не нашел
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Миллион клодобезьян: естественный отбор вайбкодинга