Comments 170
Вообще реальные оценки приводят - ускорение разработки в 2 раза. Т.е. да, вроде ускорение есть - но не так уж намного, в 2 раза, если не создавать тех. долг. Ожидать ускорения в 100500 раз - ну такого пока нет, дальше посмотрим.
В 2 раза - это очень много. Ускорение разработки прямо пересчитывается в бюджет, а сокращение бюджета в половину - это мега эпик вин.
Моя оценка ближе примерно к пи (3.14 раз). Речь именно про полный цикл от "составить внятное тз на разработку" до "фича на проде в промышленной эксплуатации" (т.е. уже отлажена на реальных задачах).
Конкретно этап "наговнокодить первый прототип", конечно, быстрее раз в -дцать.
Ну тут от специфики зависит. У нас полный цикл выглядит примерно так
BRD -> FSD -> Разработка -> Автотесты -> Компонентное тестирование -> Бизнес тестирование -> Интеграционное тестирование -> Нагрузочное тестирование -> Техтест на прелайв среде -> Внедрение в промсреду
Сами понимаете, что сокращение времени разработки даже в 3 раза не даст такого же сокращения TTM.
И да, с любого этапа после разработки возможен возврат на доработку. Где-то разработчик ошибся - не прошли автотесты или компоненты, где-то ошибся аналитик - не прошли бизнес-тест. Где-то что-то не учли - провалили интеграцию. Выбрали неудачное решение - провалили нагрузку... И т.д. и т.п.
У нас количество закрытых задач выросло в 1,5 раза. Это единственный измеряемый эффект. Где-то подросло качество, т.к. ИИ вытаскивает кейсы, которые просмотрели все.
У нас количество открываемых qa багов выросло в полтора раза, это я вижу. А вот скорость закрытия оных поднялась не особо, толи наши тестировщики стали лучше работать, толи прогеры стали клепать фигню
не, не только что кейсы просмотрели. Может и не просмотрели, видели, просто вечное "потом". А сейчас "отрефакторь наконец эту хрень, чтобы ничего не сломать" это 15 минут (месяц потом разгребать баги это конечно другое)
Наиглавнейший вопрос тут - сколько это ускорение стоит по сравнению с ускорением, которого было бы можно достичь без ИИ, то есть наняв дополнительных людей. Тесты ИИ, где приводилась стоимость показывают, что ИИ чаще дороже людей - он может иногда за ночь съесть недельную зарплату джуна, ничего особо толкового не сделав, то есть за ИИ надо следить сильнее. И надо ещё помнить, что наняв дополнительных джунов, вы через пять лет получите дополнительных миддлов, в то время как ИИ за это время миддлов заменить сможет вряд ли.
И надо ещё помнить, что наняв дополнительных джунов, вы через пять лет получите дополнительных миддлов, в то время как ИИ за это время миддлов заменить сможет вряд ли.
которым надо будет значительно повышать зарплату или они уйдут или просто уйдут, оставив проект в самый разгар и тд
«Кормить надо лучше — они и не улетят» ©
Вы ещё один момент упускаете: если процессы завязаны на модели из страны вероятного партнёра, то он получает неплохой такой рычаг влияния: достаточно ему запретить иметь со страной X дело — и вся её айтишечка одномоментно ляжет.
Вопрос пока исключительно в том, что надо дать заглотить наживку поглубже.
Запомните этот твит.
наняв дополнительных джунов, вы через пять лет получите дополнительных миддлов
Нет, не получите. Их получит ваш конкурент, предложив им +Х%
в то время как ИИ за это время миддлов заменить сможет вряд ли
Напомните, как там нейронки писали код 3 года назад? Никак? Точно через 5 лет мидлов не заменят? :)
Нет, не получите. Их получит ваш конкурент, предложив им +Х%
По моему опыту время «вхождения в проект» (перехода из состояния «кто я? где я? куды нажимать?» до состояния «за 5 минут поднимаю упавший прод в 3 часа ночи в субботу, находясь под мухой» составляет 18 месяцев. Поэтому как минимум полгода у конкурента будет [практически] бесполезная тушка — а Вы можете этого избежать, просто сделав человеку адекватный «оффер удержания».
Честно говоря не думал, что на это тему возникнет спор, так как он в рамках обсуждаемой темы не имеет смысла. Смотрите в рамках всего рынка труда: не нанимая джунов сейчас вы делаете мидлов в будущем дороже. Как они будут по рынку распределятся при этом совершенно не важно. Парадокс в том, что вклад в этом каждой фирмы ничтожен, поэтому все на это плюют, но суммарный результат будет драматичным.
Давайте посмотрим в прошлое - ведь программаное обеспечение для программирования (а обсуждаемый тут ИИ - это оно и есть) всегда эволюционировало. Вспомните, когда появились языки высокого уровня, былили ли массовые проблемы с теми, кто писал на ассемблере? Я такого не слышал. Увеличилась эффективность отрасли, но люди работу не теряли. Сейчас ситуация точно такая же: ИИ - это просто транслятор с языка человеческого в язык программирования. И его надо использовать для повышения эффективности, а не для снижения издержек.
И его надо использовать для повышения эффективности, а не для снижения издержек.
надо - оно понятно что надо, но кому надо то? нам с вами? или владельцам бизнеса у которых метрика принятия решения это две колонки с дебетом и кредитом в бухгалтерской программе?
Им и надо. Потому что увеличение эффективности приносит больше денег, чем снижение издержек. Я много смотрел интервью с успешными бизнесменами, и все как один говорят, что если вы вдруг нашли у себя лишние ресурсы, то их надо пускать на развитие, а не резать.
Потому что увеличение эффективности приносит больше денег, чем снижение издержек.
Это не очевидно если смотреть финансовые результаты
. Я много смотрел интервью с успешными бизнесменами, и все как один говорят, что если вы вдруг нашли у себя лишние ресурсы, то их надо пускать на развитие, а не резать.
говорить - это одно, КПИ у бизнесменов стоит на уменьшение издержек и увеличение прибыли в рамках финансового периода
Допустим если условный гендир компании видит что у него рост прибыли (доход-минус расход) не дотягивает до целевых цифр заявленных инвесторам-акционерам, самый простой выход - резко сократить расходы, а проще всего это сделать - сократить ФОТ
то их надо пускать на развитие, а не резать.
чтобы пустить их на развитие, надо описать задачи, ТЗ, собрать команды. а это несколько месяцев простоя этих лишних ресурсов, а это большой рост расходов при нулевых доходах и надо объяснение писать инвесторам-акционерам - какого черта такое допустили и почему люди без дела за кучу бабла сидят
именно по этому все увольнения происходят внезапно и срочно, даже с потерей ценного знания и ресурса, потому что топменеджер может не только премию потерять но и работу если он выйдет из плановых цифр роста-прибыли
акционерам плевать что через 2 года такой работы будет какаято прибыль, им важно какая прибыль по результатам квартала-полугодия будет
Всё ровно наоборот. Акцонерам плевать на прибыль, им важна стоимость акций. Поэтому прибыль обычно держат околонулевой, чтобы минимизировать налоги. А куда девается прибыль? Правильно, в развитие. Потому что рост стоимости акций происходит только через него. Это главная цель, а прибыль, которая будет в это инвестирована - одно из средств. Но есть и другие, о которых было сказано выше, и если это приводит к устойчивому росту, то цель будет считать достигнутой даже при умеренных убытках.
Когда у вас вместо заявленного роста в 40% рост 5%, инвесторы начинают продавать акции, сразу, они не думают о стратегии и о смысле. Вы пытаетесь сейчас рассказать идеальную ситуацию как должно быть, но так не бывает в реальности. Вы никогда не попадали под внезапные сокращения, когда топором неглядя машут? Когда вы в понедельник пафосно устроите офигенный планы разработки и продаж, а в пятницу пишете расстрельнный список чтобы у вас хотябы 2 программиста осталось чтобы 3 из 10 продуктов в проде не рухнули, потому что на следующей неделе в среду конец квартала и надо чтобы все были уже уволены
Я на такое три блин раза уже попадал
в развитие. Потому что рост стоимости акций происходит только через него.
Сейчас ситуация точно такая же:
Нет, не точно.
ИИ — это просто транслятор с языка человеческого в язык программирования.
Нет, не просто. Это непредсказуемый транслятор, который ещё и ошибки совершает (а потом — «вы совершенно правы, не надо было так делать!»)
Надо просто повесить один транслятор направив на другой транслятор. И править они друг друга будут до посинения (или до израсходования токенов).
ЗЫ: Надо будет поиграться с агентными чатогенераторами, заставить их решить те проблемы, которым я нашел безумные, на грани гениального, PoC. Потому что в так именуемом single-shot режиме оно мне на все 3 проблемы говорило "Никак нельзя, Сэр!"
наняв дополнительных джунов, вы через пять лет получите дополнительных миддлов, в то время как ИИ за это время миддлов заменить сможет вряд ли
Уверен, что сможет, поэтому именно в ИИ нужно вкладываться сейчас. Вспомните, что 10 лет назад нейросети рисовали психоделические картинки, 5 лет назад рисовали 6 пальцев, а сейчас в слепом тесте не всегда можно определить сгенерированное изображение. ИИ сейчас развиваются быстрей, чем джуны дорастают до мидлов, и при этом, в отличие от людей, они по мере развития становятся дешевле.
5 лет назад рисовали 6 пальцев
Да у них и сейчас с этим как-то не особо задаётся...
ИИ сейчас развиваются быстрей, чем джуны дорастают до мидлов, и при этом, в отличие от людей, они по мере развития становятся дешевле.
Легко становиться дешевле, когда тебя заливают баблом.
Сейчас уже голос неотличим от оригинала, чем пользуются мошенники, а картинки и видео стали такого качества, что уже пошли разговоры о введении тэга "ИИ", чтобы было понятно, где сгенерированный контент.
В сфере ИИ для того, чтобы не отстать - надо бежать со всех сил. Уже даже в поиск внедрили ИИ, и люди голосуют за него ногами. Зачем мне традиционный список сайтов с какими-то формулами и рекламными преувеличениями, например по утеплению дома, если поисковик в режиме ИИ сам всё посчитает, подберёт материалы в магазинах моего города и распишет сильные и слабые стороны каждого варианта?
Что бы потом не ругаться на галюцинации столкнувшись жестокой реальностью.
Если бежать изо всех сил не глядя куда бежишь, можно прибежать не туда куда хочешь.
Сейчас уже голос неотличим от оригинала, чем пользуются мошенники
Не знаю, не знаю. Я вот пока что вполне себе отличаю. Хотя сидят говорят как живые.
Зачем мне традиционный список сайтов с какими-то формулами и рекламными преувеличениями, например по утеплению дома, если поисковик в режиме ИИ сам всё посчитает, подберёт материалы в магазинах моего города и распишет сильные и слабые стороны каждого варианта?
...а о нюасе Вы узнаете уже потом.
Если искать традиционно, по сайтам и видеороликам, то нюансов будет ещё больше и цена ошибок - выше. ИИ же выдаёт в пережёванном виде все знания человечества, до которых смог дотянуться.
Если искать традиционно, по сайтам и видеороликам, то нюансов будет ещё больше и цена ошибок — выше.
Эмммм... Зачем вы ищете знания, прости госсди, по сайтам и видеороликам? Для этого профильная литература есть. И да, учиться надо. В некоторых случаях — годами.
ИИ же выдаёт в пережёванном виде все знания человечества, до которых смог дотянуться.
Ключевое слово — пережёванном. Иными словами, продукт, идентичный натуральному. Как было сказано,
@Hemml Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что‑нибудь понимаешь, она всегда делает плохо
Перевожу на общечеловеческий: она всё делает плохо. А когда вы считаете, что она что‑то делает хорошо — у вас просто недостаточно знаний в этой области, чтобы понять, почему на самом деле вышло всё‑таки плохо. Спросите у специалиста в этой области.
Вот, например, персонаж пытается меня убедить, что «ChatGPT отлично нарисовала комикс» — а я его немедленно тыкаю в кучу ошибок, которых он без посторонней помощи в упор не видит. Ну, знаете, глаза, божья роса, вот это вот всё.
Вот и в других областях точно так же.
Эмммм... Зачем вы ищете знания, прости госсди, по сайтам и видеороликам? Для этого профильная литература есть. И да, учиться надо. В некоторых случаях — годами.
Предлагаете для замены советского блока выключателей на ванную, отучится пару лет в электротехникуме? Вместо пошагового повторения действий в видео. Или для ремонта блока ABS автомобиля прокачать знания схемотехники, потому что эту неисправность надо искать без схем. Вместо "при ошибке 375 блока ABS тыкнуть паяльником сюда и заменить вот этот компонент". Сейчас многое можно делать самому, не изучая годами матчасть и не переплачивая "специалистам", которые сделают так, что за ними ещё придётся править.
5 лет назад рисовали 6 пальцев, а сейчас в слепом тесте не всегда можно определить сгенерироованное изображение
Мне кажется, что это слабый аргумент. То, что это будет исправлено было понятно сразу. Точно так же как и слова на картинках, которые сейчас пишутся намного лучше.
Когда есть сотни миллиардов фотографий с пальцами и словами на картинках, то нет сомнений, что на этом можно обучить модель. В пальцах же нет ничего уникального и особого. Мои пальцы примерно такие же как ваши. Это не какой-то специфичный бизнес-процесс или уникальные знания. Причем даже если при генерации они будут немного отличаться, это ни к каким проблемам не приведет.
ИИ — мощный ассистент, который отлично справляется с шаблонными задачами и генерацией каркасов. Но инженерную культуру он не заменяет.
Именно так.
Или, другими словами:
Из г**на и палок можно построить примитивную хижину для дикарей, живущих в круглогодично тёплом климате.
Но если из тех же материалов попытаться построить самолёт... то умные люди будут сто лет над этими дикарями смеяться и называть такие потуги "карго-культом".
Самый прикол в том, что дикарям ничего доказать невозможно, потому что они уверены, что у них всё работает: крылатая фиговина из навоза и сена стОит?.. Стоит! Такие же крылатые фиговины с неба хавчик бросают?.. Бросают! Чего ж тебе ещё надо, хороняка?! Всё работает, как надо!
Из г**на и палок можно построить примитивную хижину для дикарей, живущих в круглогодично тёплом климате
Когда-то давно у меня были Жигули, ВАЗ 2107
Ощущения такие же: когда нет снега, не ночь, нет дождя, не жарко, скорость невысокая (тормоза плохие), ехать недалеко (спина не скрючится) и ещё много условий - едешь и думаешь: "да нормальная машина! чего ещё надо?"
На секунду, папа вашего 2107 является победителем конкурса "Европейский автомобиль года" в 1967 году. Вот такие были стандарты в те времена.
Вот такие были стандарты в те времена.
В Европе были такие стандарты, люди на самоходных сараях передвигались типа citroen 2CV по сравнению с которым фиат 124 это космолет
а в 67 году в США самым популярным семейным авто был вот этот агрегат https://www.reddit.com/r/classiccars/comments/12x4h6g/1967_oldsmobile_delta_88_town_sedan/
с двигателем V8, АКПП, стеклоподъемниками и кондиционером
p.s. забавно как обычно закатывают глаза обычно вспоминая японские ниссаны 70-80годов как пример супертехнологичных авто... при этом в США уже в 50х нормой была АКПП, кондей, радио, и электростеклоподъемники и регулировкий сидений
citroen 2CV
Примерно как автомобиль Моргунова из фильма Операция „Ы“
с двигателем V8, АКПП
Я тоже удивлялся, на чём каталась молодежь из глубинки в твинпикс у которой и денег то не должно было иметься
Наиболее вероятно с двигателем Chrysler B 383 V8 (6,3 л) «большой» блок («big-block»),
Porsche 911 в том году имел объём 2 литра
в твинпикс
Нет, ну, ... Даже его же "Малхолланд драйв" выглядит на фоне "Твин пикс" вылощенным реализмом...
Я тоже удивлялся, на чём каталась молодежь из глубинки в твинпикс у которой и денег то не должно было иметься
Ну так пони кары, маслкары, это автомобили для школьников-студентов, буквально
"Мощный двигатель, эффектная внешность, простой салон, копечная стоимость"
...Фиат блин 124 с двигателем 1.1..ага, авто года... Европа место совсем не автомобильное, чтобы их серьезно воспринимать
БМВ например тех лет ведь тоже были чем-то странным внешне и внутренне
Интересно, как 6 литровый V8 был дешёвым?
а что в нем "дорогого"? бензин в те годы стоил вообще копейки, это аукнулось в 70-80 годах, но до середины 70х проблем с расходом в 30+литров на 100км не было никаких. в СССР например по этой причине основная масса грузовиков и автобусов были бензиновым
Интересно, как 6 литровый V8 был дешёвым?
А вы посчитайте по стоимости владения. V8 можно заправить ослиной мочой и он чих-пых но довезёт, можно забить на обслуживание и он всё равно проходит свои пол-миллиона. Экономичный же мотор, чуть недоглядел - и легла турбина, провернулись вкладыши, появились задиры и прогары. Тысячу долларов туда, тысячу - сюда (по американским расценкам).
"да нормальная машина! чего ещё надо?"
Совершенно верно. Жигули ориентировали для массового пользователя. Ведь богом Вы тогда еще не были...
Из г**на и палок можно построить примитивную хижину для дикарей, живущих в круглогодично тёплом климате.
Или
Можно ли сделать из г-на конфету?
Можно, но это будет конфета из г-на.
Просто и подход, описанный в статье, и сама статья устарели на пару лет. И то, что вайб-кодинг более-менее работает для poc, менее-более для mvp и в принципе не работает для долгоиграющих продуктов - тоже известно уже пару лет. Как там? А, во - с подключением!
И отладка, а то и переписывание отдельных узлов и модулей совершенно обычное дело.
А как же анекдот №-9976958.
Но если серьезно - тут весь вопрос в новой культуре разработки. Она есть у вас? Если вжик и готово - то никакая культура не нужна. А если же это только инструмент и его нужно внедрять, проводить ревью не терять контроль над кодом - то все намного сложнее.
Целью было проверить насколько можно доверять тому, что навайбкожено.
Сеть буквально завалена роликами, “как я за полчаса сделал аналог Windows” и прочее в этом духе. Причем когда смотришь ролик, кажется что всё… конец истории. Вот и хотелось понять так ли это на самом деле, есть ли границы и если есть, то где.
Проблема в том, что внешне выглядит очень круто. Думаю, что все были в шоке, получив первый результат. Но дальше минутной демонстрации “вот смотрите всё это отлично работает” нет ничего. Деморолик завершается. В смысле ничего не показывается, не тестируется, не проверяется. На одной чаше весов ошеломляющий вау-эффект, а на другой скучные проверки и тестирование.
А дальше диалог примерно такого вида:
Ты проверял как это работает? Ты понимаешь, как это работает?
А что проверять? Вот же отлично выглядит. Больше ничего не надо. Пользователь за полчаса получил то, чего ждал год.
Ладно… А ты уверен, что работает правильно?
ИИ сама написала тесты и все они прошли. Всё отлично. Хочешь, напишу промпт и сгенерируем еще 1000 тестов? Будет полное покрытие.
Я потыкался и то тут, то там ошибки.
Фигня вопрос, писылай ошибки, перегенерируем программу.
И пока речь идет о простой штуке - нет вопросов. Но я уверен, что все разработчики на корпоративном сейчас сталкиваются со свежими идеями от клиентов: зачем нам брать дорогой софт, если можно за 1 день сгенерировать. У них возникает вполне правильный вопрос - а за что мы, собственно, платим. Вот же всё работает.
В принципе, как решать свои проблемы - дело личное. Считаешь, что не нужны годы опыта, к черту понимание вопроса, а достаточно одного промпта - решай задачу так. Но как минимум надо осознавать, какой будет результат за рамками “вот смотрите, как круто”. Если результат вайбкодинга устраивает - отлично, пили всё сам. Если нет, то стоит задуматься о том как правильно применять ИИ. А для этого надо поверить на какой-то нетривиальной задаче и реально пощупать результат.
Хотелось понять, что там после первого вау-эффекта.
В принципе, как решать свои проблемы - дело личное. Считаешь, что не нужны годы опыта, к черту понимание вопроса, а достаточно одного промпта - решай задачу так.
Это в любом деле так. Клиент думает: "а чо так дорого, тут делов-то на две минуты" - но при этом сам эти двухминутные дела почему-то не делает, а хочет, чтобы их сделал ты. За две минуты и за две копейки.
Вы правы. Однако до ИИ программисты делали баги. В проектах баги висели, порой годами (да и до сих пор висят). Часто под постом "мы выкатили новую фичу" можно встретить комментарии "а когда баг ААА исправите, уже N времени висит"
Сейчас ИИ делает много багов, но ИИ также очень быстро их исправляет.
Фигня вопрос, писылай ошибки, перегенерируем программу.
И это в принципе работает. Тесты предотвращают регрессию, новая итерация почти всё исправляет. Итерация за итерацией и продукт начинает быть приемлемым.
У любого порядочного (хоть возможно временами не очень) инженера есть чувство того вносит ли исправление бага больше энтропии в конечный продукт, или меньше.
Одну и ту же задачу можно зачастую решить двумя путями - закрыть костылём и заглушкой, либо попытаться интуитивно почувствовать наличие другой "подкапотной" проблемы для которой текущая проблема это лишь частный случай, и решать общую.
Итеративно полученый "приемлимый" продукт таким образом очень легко может превратиться в совершенно неподдерживаемый нерасширяемый MVP астрономических размеров, на переработку которого уйдёт больше денег/усилий/времени чем на разработку с нуля.
ЛЛМ вот прекрасно справляется с этой частной проблемой мелкой итеративной разработки. Причем вполне прекрасно, до тех пор пока проект все ещё помещается в контекст (причем контекст до автокомпакта) и пока слова в названиях переменных и функций действительно отвечают за то что эти переменные и функции делают
Но не решает гораздо более сложную, глобальную и порою философскую проблему - что вообще такое хороший software и как его писать.
Одну и ту же задачу можно зачастую решить двумя путями - закрыть костылём и заглушкой, либо попытаться интуитивно почувствовать наличие другой "подкапотной" проблемы для которой текущая проблема это лишь частный случай, и решать общую.
Тут есть ещё такой момент, что часто выгодно на первом этапе быстро разработать рабочий продукт с костылями и заглушками, отловить все нюансы не очевидные изначально.
А уже потом из этого монстра прошедшего первичную откатку на реальных задачах спокойно пересобрать новую версию с продуманной архитектурой с учетом выявленных на первом этапе проблем.
Если же сразу сильно вкладываться в архитектуру можно потерять кучу времени на оптимизацию тех моментов, которые в конечном продукте вообще не критичны и наоборот упустить что-то в моментах казавшихся исходно не важными, но в итоге оказавшимися критичными.
Экономически невыгодно писать два раза. Тем более что даже MVP который делает что то полезное уже полгода разработки. Нет вторых полгода. Кроме того контекст новой системы будет замылен старыми решениями так что-то тупик. Надо сразу вкладываться в проектирование архитектуры и периодически делать интеграци онный меж issues code review
Тут есть ещё такой момент, что часто выгодно на первом этапе быстро разработать рабочий продукт с костылями и заглушками, отловить все нюансы не очевидные изначально. А уже потом из этого монстра прошедшего первичную откатку на реальных задачах спокойно пересобрать новую версию с продуманной архитектурой с учетом выявленных на первом этапе проблем.
Но при этом частенько после первого этапа набИгают ыфективные манагеры и с криками «да чо тут пересобирать, работает жы!!!» уводят всех на новый проект.
Такие "итеративные быстрые исправления" быстро превратят приложение в неподдерживаемую переусложненную перевязанную простыню говнокода, в которой сам ИИ без 100грам не разберётся. Начнет чинить одно и ломать другое.
Сейчас ИИ делает много багов, но ИИ также очень быстро их исправляет
...на новые.
Тесты предотвращают регрессию, новая итерация почти всё исправляет. Итерация за итерацией и продукт начинает быть приемлемым.
И тут хрестоматийное
Тебе доверили достроить за другим прорабом лабораторию на острове. Ты приходишь на объект, а там кроме недостроенного здания: огромный вентилятор (размером со здание), большой воздушный шар и комната, набитая швабрами. Почесав голову, ты разбираешь этот хлам и доделываешь лабораторию. Сдаешь объект ученным, но через 5 минут они выбегают с криком: «УТЕЧКА ЯДОВИТОГО ГАЗА!!!».
— Как так-то? Должно же работать! — в отчаянии кричишь ты и звонишь прошлому прорабу: — Вася, у нас ядовитый газ потёк! В чем проблема?
— Не знаю, должно было все работать. Что-то в проекте менял?
— Немного, швабры вынес…
— Швабры потолок держали!
— Что??? Что извините???
— Говорю, швабры потолок держали. Над ними цистерны с газом были. Очень тяжелые, пришлось в комнату снизу швабры напихать.
— Ты хотя бы записку на двери повесил бы, что швабры для держания потолка! У нас тут ядовитый газ течет! Что нам делать?
— Включай вентилятор. Он сдует газ с острова.
— Я его демонтировал сразу же!
— Зачем? Зачем ты построил 120-тонный вентилятор? Ты не мог положить ящик #$%^ ПРОТИВОГАЗОВ?
— Ящик противогазов искать нужно, а вентилятор у меня с прошлого заказа оставался.
— Вася, я убрал твой вентилятор! Мы тут задыхаемся!
— Херли вы тогда там делаете? Садитесь на воздушный шар и уелетайте оттудова!
А так почти приемлемо, да.
Фигня вопрос, писылай ошибки, перегенерируем программу.
И это в принципе работает
Зависит от цены падения. Вы готовы выплатить из своего кармана?
Авторы этих роликов обычно не программисты. А PM, лиды какие-то не оч технические. Ну то есть сказал сделать ИИ такс-трекер и вааау, оно смогло. И работает. Магия! Программисты не нужны!
Смотрите на этой с другой стороны: раньше надо было для такого найти программиста и заплатить ему. Теперь не надо. И совершенно не важно, что там под капотом, и какой там "говнокод", если он выполняет твои задачи.
Я долго искал себе VPN клиент под android, который умеет подключаться к HTTPS-прокси серверу. Не нашел. Нашел socks, переписал перевайбкодил на HTTPS, потом добавил туда VK tunnel (TURN), VLESS, zapret и failover. Все это добро работает без жалоб (я проверил только что чат с друзьями - с 15 июня). А весит меньше, чем один клиент на VLESS из гугл плей (видимо потому что я туда рекламу не добавлял, хых). При этом, например, найденную относительно недавно дыру с обнаружением VPN-а на Android я закрыл день в день.
Или, например, я публикую картинки 4 дня в неделю на куче платформ разом. Есть сервисы, которые это делают за деньги, но там неполный список платформ, что мне нужны. Теперь у меня такой для личных нужд крутится на домашнем сервере, бесплатно.
Да я ж не против такого использования. Вы что-то делаете, применяете для себя, окей. Но не бежите писать про это волшебные тексты, что ИИ заменит программистов, экстраполируя условный такс-трекер на корпоративную систему.
Инструмент он на то и инструмент, что надо знать где его использовать и где его не использовать ;)
Ни в коем случае. Но иногда порывает поправить людей, которые считают, что вайбкод все еще застрял на уровне 2023 с перепиской в чате. И это мой грех. :)
я из 2023 - поясните, пожалуйста, что не так с решением задачек через интерфейс чата, если нужный контекст умещается максимум в 2 - 3 класса, и задача конкретная, для которой LLM не нужно знать весь проект?
Заявляется ведь, что модель одна и та же
Поясняю: знать весь проект никогда лишним не будет, люди с аргументами "тут ллм нормально накодит, а в другом месте сломается" не дадут соврать. Кроме того, при локальном исполнении можно тут же прогнать тесты или вообще само приложение.
Что касается "модель одна и та же", конкретно в ChatGPT в веб-версии доступна только 5.6 Sol и 5.5.
Встречный вопрос: а почему просто не поставить приложуху для кода от разработчика? Ну тот же Codex или Claude Code?
есть проекты, которые я не имею права скармливать в чужую LLM, а кусками исследовать можно. Также мне не хочется отдавать свои кровные лишь за то, что модель будет лопатить код, в котором сейчас никакой помощи от нее мне не нужно.
Хочется иметь контроль над тем, чем я делюсь и за что плачу. Здесь же от адептов агентской разработки вижу рассказы о 200$ за один день.
Вы возможно скажете про AGENTS.md, прописать там "туда не ходи, сюда ходи", но инструкции ведь могут спокойно игнорироваться.
Возможно приду-таки к clade code потому что chatGPT, показав себя очень классно в первой половине года, сейчас бешено деградирует. Почти каждый ответ получаю "You are right to challenge that, I shouldn't have ...." и простыня извинений. Сегодняшний мой кейс например находится исключительно в одном классе, сложный расчет комиссии который я писал несколько лет назад и надеялся пофиксить в чатомГПТ - итог 5 часов мучений и уверенных советов ломающих все.
Раньше в тарифе Plus за 20$ был нормальный thinking mode порой по 5 - 10 минут, сейчас выплевывает буллшит практически мгновенно. Есть кнопка "плоти больше", но когда меня надувают, желания доплачивать никакого уже нет.
Есть кнопка "плоти больше", но когда меня надувают, желания доплачивать никакого уже нет.
А разве 20-баксовый план не имеет доступа к Codex? Я правда не знаю. Посмотрите. Можете дать ему доступ к папке с одним файлом и повторить эксперимент.
Здесь же от адептов агентской разработки вижу рассказы о 200$ за один день.
Это трудности перевода по большей части, как тут. Добровольно на API с 200 баксов за день никто не сидит, это делают только юрики и прочие бизнесы. Лично я с воскресенья спустил 3224$ "апишных", но я сижу на подписке за 200 баксов в месяц.
хм, опять же, в моем сегодняшнем случае чатГПТ несколько часов подряд путал, фигурально, окно с дверью, и я сомневаюсь что подробный план дома с фундаментом ему бы помог, как бы не наоборот. Задача была максимально локальной.
Скорее выглядит как инфляция тарифа Plus, текущая модель стилем и тупым многословием местами явно возвращает в 2024й, даже смайлики снова начала присылать. Повторюсь, в какой-то момент режима чата за эти 20$ мне хватало за глаза, output был супер структурированным, ответы взвешенными. Реально становилось страшно за профессию)
Но видимо теперь цены чуть приблизили к реальности, и целесообразность использования нужно пересчитывать.
Если в режиме Codex останется та же модель, каши с ней я не сварю точно. Скорее попробую клод.
Благодарю за ответ!
Если у вас уже есть Codex, то попробуйте лучше его. Что касается Claude, то там были какие-то подвижки убрать Code из версии за 20 баксов, не знаю, к чему они в итоге пришли. Чат конечно будет, а вот Code может и нет.
Скорее выглядит как инфляция тарифа Plus, текущая модель стилем и тупым многословием местами явно возвращает в 2024й, даже смайлики снова начала присылать.
Code/Codex мне за год не прислал ни одного смайлика. Видимо, проблема в системном промпте.
У него действительно в системном промпте есть запрет на смайлы: https://github.com/openai/codex/blob/42266240fde628ef74c2b4e2a54d9bde059cd3e6/codex-rs/core/templates/model_instructions/gpt-5.2-codex_instructions_template.md?plain=1#L24
В openAI даже на самом дешевом 20-баксовом тарифе 5.6 Sol безлимитна в режиме чата
"Добродетель вознаграждается на то свете, грех же приятен сам по себе"
Если честно, то не очень верится, что Вы не понимали заранее, чем завершится эксперимент. Я ещё из одних ранее прочитанных статей на Хабре примерно такого и ожидал результата (будет неплохой прототип, но с кучей ошибок и совершенно ненадёжный с массой неожиданных багов).
Предположу, что он Вам нужен был, скорее, чтобы было что клиентам показывать при продлении договоров (на их аргументы "да нам ИИ все напишет, если скидки 90% не будет!".
Хотя статья много кому полезна в таком аспекте может быть, спасибо. Удивился, что карму Вам не подняла до высот заоблачных:-)
И интересно, что сказал (и что будет говорить) неизвестный мне апологет. Что-то сдаётся мне, что сильно это его позицию не изменит. Будет аргумент типа "у зануд, конечно, ничего не заработает".
На самом деле я не знал как закончится эксперимент и мне точно не нужен был аргумент для доказательства, что ИИ способен делать только что-то кривое, а надежные вещи это только полноценное кодирование.
Логика очень простая - если ИИ действительно способен заменить корпоративную разработку, то это по любому пробьет дорогу на рынок. Ну хорошо, я буду вешать лампу на уши, но ведь это ситуацию не изменит. Клиенты по любому где-то увидят то, что им нужно. Какой смысл от этого прятаться? Я же не могу запретить клиентам смотреть по сторонам.
Мне как раз и хотелось посмотреть, как это работает на самом деле. Роликов было просмотрено множество, но там везде были слишком "карамельные" примеры.
Результат сильно выбивался из ожиданий. Я думал, что будет реализовано меньше функций, но предполагал, что качество будет выше. Получилось по другому - реализовано очень много, но надежность очень сомнительная. Причем, что интересно понять что есть проблема можно только если самому потыкать.
При классической разработке фичи реализуются медленнее, но ты привыкаешь, что если уж сделано, то не будет падать от первого касания. Тут же всё по другому. Не то, чтобы это было совсем ужасно, просто оценивать результат надо не так, как мы ранее привыкли. Надо это осмыслить, чтобы понять как правильно применять ИИ.
Штука реально крутая, но оценивать её надо не так, как мы привыкли.
Что за модель-то использовали? Сколько агентов работало?
Последний на тот момент Claude. А вот сколько агентов не помню.
Надо было в текст добавить, а так, сейчас технология развивается 7-ми мильными шагами, возможно стоит, через пол года, чуть модифицировать Промт и дать ту же задачу актуальной модели. Ибо то, что год назад казалось невозможным, сейчас ИИ модели делают спокойно...
сейчас технология развивается 7-ми мильными шагами
меня недавно тут уверяли, что ИИ образца зимы 25-26 года и лета 26 - это два разных уровня, многократный прирост. Однако разница в качестве кода там на грани погрешности, новые модели даже кое-где подсливали в моменте. Так что в данный момент лично я не вижу никакого 7мильного развития, только увеличение стоимости подписки)
Значит очень плохо смотрите. Сейчас занимаюсь реверсинжинирингом одного проекта, и все что выше 4.8 вообще отказывается вести диалог сразу, 4.7/4.8 реагируют обычно нормально, но иногда спотыкаются в классификаторе об какой-нибудь драйвер который надо написать, 4.6 безотказные. Разница просто земля и небо, 4.6 это на час работы сессии, потом начинает плыть, 4.7/4.8 стабильно держатся несколько часов. В плане написания тулчейна для всего этого предпочитаю пользоваться 5+ порой, просто опуская sensitive детали, и все равно после того как я побыл meat-proxy, оно делает это качественнее чем 4.7 условная со всем контекстом.
Да не понятно а чего ожидали? за 48 часов сделать продукт? Да, MVP быстро будет. Но дальше то точно так же тестировать, дорабатывать. ПРосто код пишет AI, и быстрее чем руками. А функциональность - точно так же , проектировать, реализоваывать частями, тестировать и так далее. Просто быстрее в 2-3 раза
Я то как раз не ожидал, что всё быстро взлетит. Я вижу разработку продукта изнутри каждый день и там очень много нюансов.
Меня скорее смущают люди, которые ожидают чуда. ИИ отличная штука, но приземлить ожидания людей не просто. Опытные специалисты говорят примерно одно и тоже, что отлично работает, но обратите внимание на это, не упускайте то... К ним вопросов нет.
Но вокруг много людей с горящими глазами и совершенно неадекватными ожиданиями. Вот они как раз ждут и более того уверены (!), что за 48 часов можно сделать продукт. Хотя, какие 48 часов - 1 час максимум. На любые указания на проблемы, мол давай проверим, а что там с производительностью, что к корректностью реализации и прочее ответов несколько. Или "ты просто не можешь пользоваться ИИ", или "завтра выйдет такая модель, что ух...".
Доказать некорректность дольше чем создать этот мираж результата
Вот это наверно и есть самый большой парадокс. Генерируешь за час, а потом 2 дня проверяешь. Если не проверять, то кажется, что можно экономить время.
Раньше создание было намного более трудоемким, чем проверка. Сейчас всё изменилось в точностью до наоборот. Не то, чтобы это ужасно, но это требует другого подхода к разработке. Хотя, тоже стоит задуматься, что считать созданием. Правильно сформулировать задачу не так просто.
Но наверно, хотя я точно не уверен, у людей ощущение, что теперь можно создавать и выкатывать в прод любой продукт за день появилось именно из-за этого. Мы же как привыкли? Сначала что-то относительно долго пишется, а потом довольно быстро тестировщики покрывают тестами. Под "быстро" я имею в виду время по сравнению с разработкой.
И вот теперь время на разработку сжалось очень сильно и люди считают, что тестирование будет делать как и раньше. И вдруг выясняется, что всплыли проблемы, которых ранее не было. Но сравнивают ведь только время написания (генерации кода), т.е. то, что раньше пилилось долго, а сейчас делается быстрее.
В результате у потребителей ощущение, что новые фичи должны появляться чуть ли не на следующий день. Это сделать можно, но ведь пользователи будет ожидать прежнего качества, а тут есть проблемы.
Вот это наверно и есть самый большой парадокс. Генерируешь за час, а потом 2 дня проверяешь. Если не проверять, то кажется, что можно экономить время.
Как бы да, но проверять нужно и написанный человеком код. Зачастую - не быстрее. Кроме того, что касается ллм, то конкретно в веб разработке ее можно пустить в Chrome и сказать "прогони все изменения, что были сделаны" - оно с доступом к корректно набитому логами коду достаточно быстро отловит все, что ей покажется багом. На slint тоже пробовал mcp подключать с той же целью - худо-бедно, но вполне работает "даже когда вы спите".
Мне кажется, эксперимент доказывает немного не то, что заявлено.
Из входных данных сознательно исключили архитектуру, оптимизации и edge cases, поставили задачу «сделай примерно так же», а через 48 часов пошли проверять архитектуру, оптимизации и edge cases. Но это уже не просто разработка, а одновременно reverse engineering требований и реализация зрелого enterprise-продукта по пользовательской документации. Команда людей за 48 часов этот тест тоже с треском провалит.
При этом самое интересное эксперимент как раз показал: за двое суток получился весьма правдоподобный прототип того, на что раньше ушло бы существенно больше времени. Дальше его надо проектировать, тестировать, переписывать и доводить — то есть заниматься разработкой. Кто вообще обещал, что разработка исчезнет?
И отдельно улыбнуло «DuckDB + SQL — но с Big Data так не работают». С Big Data как раз прекрасно работают SQL-движки, а 50 млн строк для DuckDB сами по себе совершенно не космос. Если приложение решило затащить всё это в браузер и браузер умер по OOM — это плохая архитектура конкретного прототипа, а не разоблачение SQL или ИИ.
Так что получился хороший материал про опасность принимать красивый PoC за настоящую готовую для прода вещь. Но как доказательство тезиса «ИИ не способен делать сложные системы» эксперимент заметно натянут.
Есть ещё фундаментальная проблема постановки: если внутреннее устройство исходной системы подопытной модели не показали, то требовать от неё воспроизвести именно эти скрытые механизмы бессмысленно. По одинаковому внешнему поведению могут находиться признаки десятков разных архитектур. Тут ИИ не «не догадался» — задача просто недоопределена.
И это уже не говоря, что можно придираться и в стиле "наш продукт делает запросы в вот такой источник более продуманно" - но не показать, что значит продуманно.
Я бы даже сказал, что итог у Вас получился вполне себе неплохой. Сами представьте, если Вы посадите разраба без лишних техзаданий такое пилить - он и вовсе на такой задаче откажется даже начинать, уже заранее догадываюсь о подставе при приёмке.
И отдельно улыбнуло «DuckDB + SQL — но с Big Data так не работают». С Big Data как раз прекрасно работают SQL-движки, а 50 млн строк для DuckDB сами по себе совершенно не космос.
Т.е. вы считаете, что работа с данными сводится к select? Если всё упиралось бы только в это, то любая СУБД положила бы на лопатки любую аналитическую платформу. Но я не разу не видел ни один проект, где бы было так.
Конечно при любой обработке данных есть операции со множествами, которые прилетели из реляционной алгебры, с этим никто не спорит. Но реальная обработка не сводится ТОЛЬКО к ним. Такие операции это часть более сложного конвейера.
Собственно, в статье есть прямое указание на это. "Продвинутая аналитика предусматривает комбинацию разных источников (базы, веб‑сервисы, ответ ИИ, файлы и так далее), предобработку, сложные алгоритмы и многое другое".
Команда людей за 48 часов этот тест тоже с треском провалит.
Мне кажется что главное из поста и вашего комментария это то что ML-bro надо ловить как раз на том моменте когда "Человек больше не нужен, ллмки сами прекрасно справятся" плавно перетекает в "Ну что вы хотели, тут бы и человек не справился, куда уж там ллмке!"
Да просто если я возьму фотошоп, возьму LLM и попрошу соорудить замену фотошопу — то внешне замена будет похожа, но вот вести себя в каждом аспекте будет крайне малознакомо. И пока я не укажу на каждую нестыковку, модель не будет знать, как оно, «в динамике», должно выглядеть, ощущаться, работать, глючить.
Просто «Сказка о тройке» какая‑то, поставить задачу так, что априори не получится хорошего решения, и говорить, что «не смогла, смотрите же!»
Меня скорее смущают люди, которые ожидают чуда.
Тут просто разный уровень "чуда" ожидается.
Для меня вот, например, до сих пор чудо, что если насыпать большую кучу полу-случайных текстов из интернета (с кучей ошибок и мусора, принципиально неустранимых) и статистически по ним пройтись, то итоговый результат сможет написать вообще хоть какую-то рабочую программу. Не взять с SO готовый шаблон FizzBuzz и заменить там 5 на 7, а прям написать, с нуля, по ТЗ. Математически доказуемо рабочую, даже если простую.
А ставить такой системе задачи "напиши развесистый рабочий продукт за 48 часов" это сродни тому, как если бы в гугле вводить запрос "какая вывеска была на заднем плане в таком-то малоизвестном фильме в определённый момент" и ожидать получить ответ. Тут единственный способ показать человеку, что так не бывает - дать попробовать самому.
Мозг чешется от этой статьи. Общий контекст примерно "да, красиво, но не годится для реальной замены". Всё это формируется мелкими деталями - это не смогла ИИшница, это не так сделала, прочая и прочая. Только в статье нет конкретики. Перед нами такой же результат, как у ИИ - красиво, но без конкретных деталей пользы никакой нет.
В статье нет ничего нового, ничего полезного. Примерно эту мысль я вижу уже лет 5? В конце есть приписка "можем поделиться", но именно эта та часть, за которую обычно и любили статьи на хабре. Не просто поделиться, а провести свой анализ и выдать полезную суть.
В статье есть ссылка на запись вебинара, где всё это показывается в живую. Кстати, после середины вебинара есть прикольная речь "адвоката ИИ". Немного шуточная, но довольно интересная. Как говорится "не всё так однозначно".
Если интересуют детали, могу выслать более подробную информацию по тестированию. Более того, можете получить само сгенерированное приложение и поиграться самому. Платформу Loginom, которую пробовали навайбкодить, мы тоже предоставим. Проведите свой анализ. Было бы интересно.
Насчет "эту мысль я вижу уже лет 5" - это сильно! Видимо вы начали генерировать код задолго до появления не то, что Codex, Cursor, но даже до выхода первой версии ChatGPT. :)
Всё, что вы написали, имело бы смысл, если бы мы понимали задание, на основе которого ИИ решал вашу задачу. А что, если бы с ИИ работал человек, который разбирается в том, как должно быть, и в вашей архитектуре хотя бы месяц?
Если честно, у меня скептической отношение к заявлениям что ИИ работал день/ночь/неделю и выдал решение проблемы.
Постоянно читаю/слышу, но собственный опыт что-то далек от такого совершенства даже на достаточно простых задачах. Его родного надо постоянно пинать/ поправлять. Заставлять переписывать и тестировать. Хотя последние версии уже научились сами тесты добавлять и проверять что то что они сделали работает. Правда не всегда и не во всем но тем не менее.
При этом код ИИ пишет достаточнотбыстро и правильно если давать задачи наибольшими частями.
Я бы сказал что раза в 4 разработка ускоряется. Грубо говоря то что делал бы руками неделю можно за день сделать. Но это 8 часов реального кодинга, хоть код модель пишет- теперь приходится ставить задачи и давать указания на исправления.
Это проще чем целый день самому кодить, но тоже выматывает. И не факт что в таком режиме можно. Неделю но-стоп работать. Не знаю как у других но обычно нормально водить можно часа 4 в день потом крыша начинает ехать и больше багов чем фич получается.
В общем я довольно скептичен по возможности АИ - как инструмент в помощь - весь замечательная, реально упрощает работу и повышает скорость, но то что с ее помощью любая домохозяйка сможет разрабатывать корабли бороздящее просторы …. Не верится.
Я бы сформулировал так что появился ещё один язык программирования, нативный (ну насколько промт можно считать нативным) а ии это просто транслятор с одного языка на другой (c# или js неважно)
И вот насколько будет детальным изначальный запрос настолько качественный получится результат.
появился ещё один язык программирования, нативный
, без спецификации языка, стандарта, библиотек и фреймворков, и сразу с кучей некомпетентных в разработке носителей (пусть "стажёров"). Интересная ситуация.
И вот насколько будет детальным изначальный запрос настолько качественный получится результат.
Но как определить, когда достаточно деталей? Даже с искусственными ЯП, с чёткими спецификациями, описания часто недостаточно для всех нюансов.
Я бы сформулировал так что появился ещё один язык программирования, нативный (ну насколько промт можно считать нативным) а ии это просто транслятор с одного языка на другой (c# или js неважно)
Один крайне важный момент, который все упускают: этот язык недетерминированный.
> cc test.c -o 1.out
> cc test.c -o 2.out
> cmp 1.out 2.out
>Как тебе такое, Илон Маск дяденька Карпатый?
Замените компилятор на другой, получите другой выход. Поставьте LLM конкретный seed, и получайте одинаковый выход.
Замените компилятор на другой, получите другой выход.
Совершенно не обязательно.
Поставьте LLM конкретный seed, и получайте одинаковый выход.
Во-первых, так чего не подставляете?
Во-вторых, это в теории. На практике пока что ошибки округления всё портят.
Во-первых, так чего не подставляете?
Никто не подставляет, потому что детерминированность ради детерминированности никому не нужна, ну разве что вам. Вот. С ИИ работают не как с компилятором калькулятором, а как с человеком, а люди как бы тоже недетерминированные, и для управления этой вот недетерминированостью есть разные техники контроля. Более того, если бы всё околокомпьютерное было детерминировано, то не нужны были бы контрольные суммы и прочие коррекции ошибок.
Во-вторых, это в теории. На практике пока что ошибки округления всё портят.
У вас видеокарта каждый раз вычисляет по-разному?
люди как бы тоже недетерминированные
Странные у Вас какие-то люди.
Я вот, наоборот, ценю в человеке предсказуемость (то есть именно что детерминированность). Когда его просишь изменить цвет шрифта — и он меняет цвет шрифта, а не переписывает всю страницу напрочь.
У вас видеокарта каждый раз вычисляет по-разному?
Ви так говорите, как будто в игре при 60 fps это сильно заметно.
Ах, предсказуемость, сначала приводите пример компилятора, который детерминированный, а потом оказывается, что имеется ввиду не математический термин, а "предсказуемость". ИИ достаточно предсказуемый, чтобы делать что-то полезное.
А в чём проблема-то? Один и тот же компилятор всегда даст один и тот же выход(*)
(*)
если не придуриваться и не тыкать в меня макро__TIME__, которое вообще-то для того и предназначено.
ИИ достаточно предсказуемый чтобы делать
(металлическим голосом:) Вы совершенно правы! /s
что-то полезное.
А мне «что‑то» не нужно — мне нужны вполне определённые вещи.
А разве кто-то спорит, что ИИ способен делать что-то полезное? Вопрос же в другом - где границы применимости?
Одни говорят, что это отличный помощник, но для задач с высокой ценой ошибки надо проверять результат. Ведь я поэтому сначала проговорил, что предлагается сделать не простое одноразовое приложение, а повторить серьезный корпоративный продукт. Повторить не в смысле сделать копию, а в смысле реализовать базовый функционал. Кроме того есть серьезные и вполне обоснованные опасения, если вы получили результат, но не понимаете его, то в очень скором будущем возникнут проблемы с тем, чтобы это была поддерживаемо.
Вторые говорят - если тесты прошли, то всё отлично и можно доверять. Большего для доверия к результату и не надо. Нашли ошибки, фигня - генерируем всё еще раз. Или, что понимание вообще не нужно - работает же, что еще надо? Мол, я вообще не хочу ничего понимать и изучать, так что меня всё устраивает.
В статье как раз и описывался попытка проверить реалистичность второго подхода, который звучит как "давайте просто доверять и пусть ИИ нагенерит программу". Какой-то результат получился, но на вопрос о том насколько этот подход способен надежно решать сложные задачи ответ мягко говоря не утвердительный. По крайней мере, пока.
Причем некоторые фундаментальные вопросы вообще проигнорированы, т.к. у двух сторон принципиально разное понимание и они полностью противоречат друг другу. Сторонники чистого и ничем не оскверненного ИИ говорят, что автотестов достаточно. Более осторожные говорят, ну как же так - вот же не работает, вы вообще проверяли? А в ответ - все тесты зеленые, значит все ок.
На один слой непроверенного, «грязного» кода наслаивается другой и генерирует технический долг на годы вперед
Аналогичный эксперимент пробовали на https://github.com/dev993848/fluxbb-next
Несмотря на уверенно отмеченные галочки о завершении половина не сделано, основой функционал сломан, миграция на известных кейсах ломается, ссылки на несуществующие issues, автор не проверил и слился.
И если копнуть в истории гита задаче поставлена нормально. Только проверок заранее сделанных не было и LLM пошла скруглять углы, не читая (долго) а вспоминая что-то из своей обучающей выборки.
Нейросети отлично кодят, но вот архитектор из нейросети довольно паршивый. То есть промт должен быть не “эй вот тебе документация, сделай так же или лучше!”. Нужно расписывать архитектуру, объекты, методы, классы, функции и все то что делает продукт продуктом… Именно поэтому у нейросетей хорошо получаются проекты где архитектура простая, там где все с этим сложно -друг на друга накладываются допущения, которые делает нейросеть при генерации. И вот как раз такие допущения, что все пойдет по сценарию, дают синергетический эффект. ))
Нейросети отлично кодят, но вот архитектор из нейросети довольно паршивый
О. Прям в палату мер и весов в раздел "Фаза торга". Мы находимся в 2026 году. В 2023 заявить, что нейросети отлично кодят не смог бы даже упоротый фанат научной фантастики. Этот путь был пройден за 3 года
Далее будет "нейросети не умеют в аналитику", "нейросети не умеют учитывать эмоции пользователя", "нейросети не несут ответственности", ...
Интересно, а почему вы решили, что технологии будут расти без ограничений? Если сейчас быстро развивается, то всё... Эти чудеса никогда не закончатся, потолка нет, предела росту нет.
Когда какая-то технология в определенный период развивается бешенными темпами, почему-то возникает мнение, что это будет всегда. Хотя все вокруг усыпано примерами, что после бешенного роста достигается потолок, который не получается преодолеть.
В середине двадцатого века скорость в авиации росла в 2 раза каждые 10 лет, была полная уверенность, что человечество будет летать во много раз быстрее скорости звука. И с какой скоростью мы летаем сейчас? Когда бурно развивался космос, казалось, что вот-то и на Марсе будут яблони цвести. Что там с Марсом? С появлением антибиотиков многие болезни вылечили и мы теперь не болеем?
И таких примеров сколько угодно: производительность процессоров, емкость батарей, продолжительность жизни, высота зданий, урожайность... Возьмите любую технологию и прочитайте, что о ней говорили в период взрывного роста.
У технологий есть ограничения. В момент взрывного роста трудно понять где они находятся. Это надо нащупать. Но в том, что где-то упремся в потолок - это наверняка.
Нейросети отлично кодят
скорее генерируют относительно корректный код, подверженный массе детских проблем и ляпов
"Клон Enterprise‑системы за 48 часов" а в деньгах это сколько получилось?
Ну так, в чем проблема? Теперь выкладываете ее в бету, юзеры (и вы) пишут репорты, ии легко и быстро фиксит все и через пару недель-месяцев получаете то же самое что и у вас, но без лютого легаси и тех. долга из-за которых вы даже темную тему прикрутить не можете. Конечно, интересно узнать что там были за доки, промпты и модели, раз она вместо части функционала сделала заглушки, ну да ладно, бывает (мне такое gpt-5.6-luna делала, сэкономил токенов называется).
И если бы ии могла выдавать законченный продукт такого масштаба за 48 часов, вас бы всех уже давно разогнали, так что радуйтесь :)
Спасибо за статью. Приятно, когда кто-то разбирает похожие кейсы и подсвечивает проблемы.
Я и читаю в интернете, и на собеседованиях слышу от людей, что появляется все больше компаний, которые заставляют все делать через LLM, не трогая код руками. Причем компании уровня банков, а не те, что делают типовые сайты на заказ.
В итоге люди выгорают, продукты постепенно портятся. И это вряд ли приведет к чему-то хорошему. Так что хоть кому-то надо доносить альтернативную информацию.
Мне кажется, что еще упускается то с какой бешенной скоростью накапливается технический долг. Реально можно за пару часов генерации получить технический долг в год.
Когда гонятся только за скоростью, то по-любому придется снижать требования к качеству. А как иначе? Математика учит, что при решении оптимизационной задачи оптимизировать можно только одну функцию. Даже когда говорят о многокритериальной оптимизации, все равно при помощи каких-то баллов и весов всё сводится к одной функции.
Вывод простой. Хочешь получить результат быстрее - нет проблем, реши, чем готов жертвовать. Иногда это очень даже норм. Не всем уперлось качество. Смущает только то, что слишком часто или откровенно плюют на это или делают вид, что проблемы нет. Можете игнорировать сколько хотите, но математика так не работает.
Спросите у тех, кто разгребает генерацию что они думают по поводу ревью кода. Конечно бесит, когда просто генерируется шлак, не проверяет и вываливается на человека. Нагенерировал - молодец, только просьба проверить что получилось.
Отладка должна быть что у продукта, созданного человеком, и что у продукта, созданного ИИ. Без этого никуда. Было бы интересно сравнить, как бы шло построение данной системы с ноля, при заказе у сторонних разработчиков, которые, как и ИИ, ничего о ней не знают. Подозреваю, что как минимум существенно медленнее, и существенно дороже. И никто бы сразу не выдал, что ИИ, что живой человек, готовый и вылизанный продукт.
Спасибо за статью. Но вроде как надо спросить ИИ, что ты собираешься делать (распиши по пунктам, что будешь использовать и как и почему), если не понятно задай вопросы.
Если бы всё решалось так просто, то не было бы проблем. Например, когда речь идет о тестировании, ведь так люди и делают, говорят "сделай тесты, чтобы было полное покрытие и тестируй пока все не пройдут". Результат - тесты есть, все корректно пройдены, но всё равно ошибки.
Всегда есть какие-то допущения, узкие места, особенности реализации. Ведь любой алгоритм анализа вообще реализовать легко, вон их сколько лежит в открытом в виде. Мы сами про разработке Loginom, конечно же, используем готовые библиотеки, но их встраивание в продукт дело совершенно не простое.
"сделай тесты, чтобы было полное покрытие и тестируй пока все не пройдут". Результат - тесты есть, все корректно пройдены, но всё равно ошибки
Ну это значит, что покрытие неполное, раз ошибки. Вы буквально заставляете нейронку делать криво (не покрывать тестами), а потом удивляетесь, что она вам делает криво. Это как я скажу таджику в ремонте: "Нормально, братан, делай как хошь", а потом буду удивляться, что все криво...
Да, но ведь полное покрытие тестами теоретически невозможно. По этому поводу даже есть теорема. Но и без теоремы и строгих математических доказательств, даже на уровне здравого смысла, ясно, что это сделать не получится никогда. Аргументация выглядит не убедительно.
def calculate_discount(price, discount_percent):
return price - (price * discount_percent / 100)
Можно написать тесты обеспечивающие полное покрытие. Например вызвать calculate_discount(100, 5) и сравнить ответ.
Покрытие полное? Да. Функция корректная? Нет.
Это не полное покрытие.
Полное - это тестирование всех возможных валидных значений + реакция функционала на невалидные значения. Это как минимум.
Нет, это как раз по определению полное покрытие. Ибо “Полное покрытие тестами (100% покрытие) — это ситуация, когда каждый участок исходного кода или каждое бизнес-требование программы запускается и проверяется хотя бы одним тестом.”
А у вас это уже проверка валидных значений, граничных значений, ну и невалидных значений.
каждый участок исходного кода или каждое бизнес-требование программы запускается и проверяется хотя бы одним тестом
Ну это же бессмысленно... Тест ради теста... Формализм ради галочки.
Ну да, зато в CI красиво выглядит :)
Более того, покрыть какую то сложную логику тестом зачастую сложнее, чем написать эту логику.
Да, это люди любят. Мол, все тесты зеленые, значит всё ок. Метрики, дашборды, все дела...
Да, по нашему опыту с автотестами больше проблем чем прихода от них. Чуть логика поменялась - надо все править включая автотесты. А логика меняется не по нашей приходи, а по запросу бизнеса.
И все равно это очень ограниченный объем тестирования. Несколько корректных кейсов плюс несколько некорректных (выдающих ожидаемую нами ошибку).
Так что тут все равно есть элемент подгонки под ответ.
Чуть логика поменялась - надо все править включая автотесты. А логика меняется не по нашей приходи, а по запросу бизнеса.
ну значит бизнес пусть и оплачивает это
с автотестами больше проблем чем прихода от них
не роняли прод еще по причине что забыли три кейса из 50 проверить вручную?
ну значит бизнес пусть и оплачивает это
Мы с ними с одной тарелки едим :-)
не роняли прод еще по причине что забыли три кейса из 50 проверить вручную?
Я же писал уже тут про наш цикл:
BRD -> FSD -> Разработка -> Автотесты -> Компонентное тестирование -> Бизнес тестирование -> Интеграционное тестирование -> Нагрузочное тестирование -> Техтест на прелайв среде -> Внедрение в промсреду
От компонентов и далее делается руками. И это основное тестирование. Автотесты так, чтобы было. В компонентах аналитик проверяет на соответствие FSD, в бизнес-тесте заказчик (бизнес) проверяет на соответствие BRD. Интеграция - проверка что новый или доработанный модуль не порушит работу системы в целом (а там этих модулей сотни тысяч и они между собой взаимодействуют - тут важно не только обратную совместимость контракта сохранять, но и внешнюю логику вплоть до возвращаемых кодов ошибок). Нагрузка - тут понятно, чтобы ресурсов не жрало как не в себя и работало быстро - там обычно сразу видны всякие проблемы типа
возникает RESOLVE SYSTEM POINTER при вызове ***. Возможно это динамический вызов ***. Для динамического вызова у нас есть засервисованный вызов ***. Надо им пользоваться. Он запоминает указатели на программы.
или
Также виден SQL PREPARE в ***
(тут речь о динамическом SQL - он очень ресурсозатратен, мы используем статический, где PREPARE происходит на этапе компиляции, или вообще без SQL, прямым доступом к БД если речь идет об одной таблице и есть нужный индекс).
Подобные вещи очень плохо сказываются в периоды пиковых нагрузок когда утилизация серверов доходит до 90%. Один лагающий модуль может по цепочке за собой потянуть много чего и возникает лавинный эффект.
Такие вещи - сразу обратно на доработку.
А уронить прод для нас - непозволительно дорого выйдет. В том числе и в деньгах. Тестирование в целом занимает кратно больше времени чем разработка.
Речь о разработке в рамках АБС - того, что крутится на центральных серверах банка.
Можно попробовать использовать ИИ не как отдельный инструмент, а как часть сервиса
Например вот тут описал что-то похожее: гибридная связка из ИИ и сервиса, где ИИ отвечает за адаптационные механизмы и подстройку.
Но хорошо такое не будет работать без хранилища спецификаций, которое будет дополняться и самим ИИ, по мере набора опыта, и оператором, по мере выявления желаемых изменений в сервисе или получении внешней информации, например какой-то внутренней информации о грядущих изменениях от компаний, с которыми связан сервис.
В идеале собрать гроздь подобных гибридных микросервисов (чем меньше сервис, тем проще ИИ), и из них уже сам крупный сервис выстроить. Балансировать состав сервиса тоже можно научить отдельного агента, который будет координировать изменения на своем уровне - какие-то сервисы выводить из эксплуатации, какие-то вводить, консультировать по текущей архитектуре, потоках данных, нагрузке, проблемах, чтобы микросервисы адаптировались не вслепую, ну и обратный поток управления, если микросервису чего-то не хватает на уровне инфраструктуры для дальнейшего развития, это уже задача агента управляющего самим сервисом организовать ввод в строй новых микросервисов.
Сложную систему можно выстроить. Но начинать можно с простейших элементов - для начала поднять один такой микросервис, научиться управлять его развитием, дать ему инструменты для самодиагностики, скорректировать инструкции, убедиться что он научился самостоятельно справляться с изменениями и проблемами, которые можно решить на его уровне. Если получилось стабилизировать один - этот опыт можно раскатать и на второй. И так постепенно, по мере роста уровня и проблем, вводить в строй новые элементы системы.
Чтобы такого не происходило - надо использовать потому что правильные механики :) Рекомендую обратить внимание на мой цикл статей тут - https://habr.com/ru/articles/1021474/ и дальше
И на фреймворк TAUSIK
ИИ — мощный ассистент, который отлично справляется с шаблонными задачами и генерацией каркасов. Но инженерную культуру он не заменяет.
Если сегодня не будет стажёров и джунов, делающих шаблонные задачи, то завтра не станет инженерной культуры.
Но представьте: если бы обычный разработчик требовал, чтобы ему четко и однозначно пояснили каждую мелочь до написания кода, зачем он вообще такой нужен?
Но представьте: если бы обычный художник/дизайнер требовал, чтобы ему четко и однозначно пояснили каждую мелочь до рисования, зачем он вообще такой нужен?
Эх забыли люди что значит разрабатывать “водопадом”!
Если что, то во всяких авиациах и проч. ответственной технике (т.е. за жертвы реально посадить могут) очень часто задание на разработку именно в таком подробном виде и приходит (а если приходит не в таком виде - то отправляется обратно на доработку)
Заменяльщики уже отбалаболились типа агенты заменят разрабов - все уже поняли, что агент без разраба ничего путного не может. Скоро настанет второй холодный душ - в конторах, где требуют "ИИ скорости", когда прилетят проблемы поддержки легаси и скрытых зафоллбэченных ллм-кой багов. Окажется, что нужно ещё каждую строчку проверять и контролировать, не говоря уже о нюансах архитектуры.
Есть еще вариант использования ИИ не для вайбкодинга всей системы, а для настройки платформы под конкретный проект. К примеру для MES систем есть такие опенсорсные решения.
Есть еще вариант использования ИИ не для вайбкодинга всей системы, а для настройки платформы под конкретный проект. К примеру для MES систем есть такие опенсорсные решения.
Я не про такое. Есть опенсорсные проекты на github, где вы можете себе забрать решение и развернуть на своих ресурсах (например, https://github.com/iot-solutions-ru/ispf). И никто у вас ничего внезапно не отберет.
Окей, а если посадить 5 разработчиков и дать им 10 дней. Сделают ли они за такой короткий срок систему хоть сколько нибудь лучше чем то что получилось у ИИ за 48 часов? Сильно сомневаюсь, подобных детских болезней будет еще больше, но они скорее всего просто скажут: «Мы только-только начали, дайте нам еще хотя бы месяц».
Выскажу свои пять копеек, почему бы и нет. Сама по себе постановка вопроса — а можно ли полностью довериться ИИ заранее провальна. И не потому, что ИИ плох и не надежен, а потому что вообще никому ничего нельзя доверять. Это тоже самое, по сути, что собрать бриф с заказчика и отдать его на аутосорс или фриланс, через время без какого-либо надзора прийти за готовым результатом в надежде что все будет так, как ожидает заказчик и работает корректно. Это так, глобальное умозаключение.
Я понимаю, что к ИИ очень сомнительное отношение, да я и сам где-то про это высказывался, что не лезьте с вайбкодом в сложные вещи, пилите ботов, лендинги, дашборды и все такое, но в моих глазах статья получилась скорее комплиментарной в адрес ИИ, а не наоборот и вот почему. ИИ не видел исходники, не имел доступа к бизнесу за уточнением деталей, к инфре и базе, работал с очень ограниченной докой и при этом сделал что-то, что работает, пусть и ограничено, но это можно исправлять, улучшать и тд. По моему опыту, чем больше документации и чем она детальнее, тем лучше можно добиться результатов. За годы сложилась история, что дока всегда ужасна. Ее заполнять и поддерживать, регулярно пополнять да и ЕЩЕ фиксировать все костыли и соглашения часто просто некому, да никто и не требует. Возможно внедрение ИИ сдвинет это с места в сторону улучшения, так как теперь можно доку генерировать задешево в промышленных масштабах,описывая любые технические аспекты. А с подробной докой и результат лучше, и ошибок меньше.
Сама по себе постановка вопроса — а можно ли полностью довериться ИИ заранее провальна.
По той простой причине, что «правильность» или «неправильность» — она в глазу смотрящего — а самому ИИ глубоко пофиг — он просто генерирует правдоподобную последовательность токенов. Если смотрящий не понимает, что там чушь написана — он схвает и добавки попросит.
LLM — это эмулятор валящегося студента на экзамене: он «выдумывает» всегда — просто иногда «выдуманное» им совпадает с правильным ответом — и мы «ставим ему пятёрку»; а иногда является чушью различных степеней полноты — и тогда мы говорим: «это он галлюцинирует».
Все «настройки» и «тренировки» LLM сводятся к тому, чтобы тем или иным способом увеличить количество первых случаев и уменьшить — последних.
Самое ценное здесь не список багов, а то, что все они одного класса. Ни один не ловится компилятором и ни один не виден в отчёте о пройденных тестах. Узел есть, кнопка работает, в поток данных он не подключён.
Тот же класс никуда не девается, когда ИИ перестаёт писать с нуля и начинает править существующую систему. Только заметить становится сложнее: нет новой системы, которую можно проверить целиком, есть дифф на двадцать строк, и он выглядит нормально.
Про недоверие к автоотчётам согласен полностью. Вопрос, на который у меня пока нет хорошего ответа: как сформулировать критерий приёмки так, чтобы его можно было проверять не только руками? Сверка сырых данных с эталоном работает, пока эталон есть.
Сложные системы — не сумма простых систем
Золотые слова
Добрый день, не увидел в статье то как происходил процесс кодогенерации, использовался какой то подход типа spec-kit или был просто большой Промт отданный агенту с просьбой его реализовать ?
Краш‑тест клона корпоративной системы, написанного ИИ за 48 часов