Comments 17
как хорошо что благодаря таким людям, специалисты будут еще более востребованы)
как плохо что благодаря таким людям нас ждет эпоха нейрослоповых приложений. уже началась, плеймаркет забит в топах сгенерированным шлаком где только иконки отличаются зато пейвол загружается первым при старте
Маркеты стали клонами сомнительного качества забиваться сильно раньше ИИ.
раньше их было 6-8 на десяток апок, сейчас цифры уже трехзначные.
вчера искал простой тестер для микрофона что бы можно было переключать источники записи прям в апке и записывать звук что бы понимать как записало.
более двух десятков апок с разными названиями, иконками и скринами (и авторами) которые выглядят одинаково - той же самый пейвол и функционал просто под разными шкурками
под сотню разного "нового" что опубликовано до пары месяцев назад прям явно нейронное аж по скринам видно
апку я так и не нашел, в итоге через звонок на другой телефон и запись там тестил
но если индустрия всё равно идёт туда - вопрос становится инфраструктурным. Так или иначе все рано или поздно перейдут на такой способ написания. В том или ином виде
такой как у вас точно нет.
если бы у вас было четко прописанные правила по архитекруте и требованиям, то такой фигни бы у вас не было. это смотрю по тому что оно успешно сгенерировало с первого раза, то есть у вас там функционала и бизнес-логики жменька.
реальный большой проект сможет сделать только "по мотивам". а уж патчить, править и тд только если расписать промт километровый со всеми краевыми условиями
кстати, то что оно у вас для фикса переписывало все в ноль это тоже проблема в первую очередь постановки задачи
Спасибо, это справедливое замечание.
Я как раз и столкнулся с тем, что при маленьком проекте проблема уже проявляется, а на больших она становится только хуже. Даже при нормальной архитектуре и требованиях AI всё равно генерирует решение в контексте конкретного состояния экосистемы: версии зависимостей, инструментов, среды.
Continuum не пытается заменить архитектуру или постановку задачи. Он скорее фиксирует сам процесс получения результата: какой план действий привёл к рабочему состоянию и как это состояние потом воспроизвести или диагностировать, когда среда изменилась.
Про переписывание с нуля согласен. Это тоже симптом плохой постановки задачи и отсутствия механизма инкрементального ремонта. Собственно, идея как раз родилась из раздражения, что каждый раз происходил reset вместо минимального исправления.
Большие проекты, скорее всего, действительно будут работать только "по мотивам". Я пока и рассматриваю это как слой вокруг генерации и воспроизводимости, а не как замену нормального engineering процесса.
Буду рад, если подскажете реальные кейсы, где такой подход точно развалится. Сейчас как раз интересно найти границы применимости.
я думаю это у вас скорее от отсутствия релевантного опыта. лично для меня нейронки это просто очень быстрые но туповатые джуны))
нарезал задачи, потом проверил и поправил по месту (или зарядил заново) то все ожидаемо. исследование идеи и накидать прототип тоже ок. но отпускать в свободное плаванье или подпускать к бизнесу что бы он навесил на уши свои космические корабли - точно нет
на сейчас если я что то с нуля делаю при помощи нейронки с расчетом что это не прототип, то я сначала сам прописываю основной скелет руками, а потом уже сажусь за промт. просто потому что прописать базовую архитектуру быстрее чем словами прописывать что ты хочешь и краевые условия.
и то потом полученное поделие я руками довожу потому.
а проблем с фиксами и патчами нет, если ты знаешь проект, понимаешь как оно все работает и знаешь что именно надо починить. прописываешь конкретный промт и все ок, точечно правит и все работает.
А что, если на это всё смотреть в контексте "у кода теперь нет ценности, есть ценность у результата"? Может и бог с ним, что моделька будет переписывать одно и то же по нескольку раз в год, если результат от этого не ломается? Тогда контекст вопроса перемещается в другую плоскость - как обеспечить целостность результата? (не поплыли экраны, не изменилась бизнес логика и т.п.) Даже если модель вдруг решит переписать всё с условного питона на rust ибо в новой версии она на нём мыслит, может оно и норм?
Автор поясните, а когда вы руками код написали и версии окружения зафиксировали, у вас код не перестает работать? А когда LLm то же делает- перестает. Я что-то не понял в чем фокус?
Единственный вариант вы когда руками пишете то версии жестко не фиксируете и оно типа работает.
так что-ли?
Раньше я ходил на Хабр, чтобы читать умные статьи и узнавать новое.
Сейчас Хабр заполонили такого рода писаки с журналистскими жёлтыми заголовками типа "я построил дом инструментами фирмы Х, и он развалился", а потом в статье выясняется, что гвозди он перфоратором забивал, а фундамент не построил.
Есть же известная фраза: если вам захотелось написать статью на Хабр - не пишите...
Проблема притянута за уши. Ну или от и незнания экосистемы, и неумения ставить задачи ии.
Lockfile с запиненными транзитивными зависимостями в момент генерации - это дефолт в npm (ну и любом другом менеджере пакетов для js). Как раз для воспроизводимости.
Нужен патч безопасности и обновления? Ну так милости просим:
npm audit fix, обновит в пределах, на которые согласны все зависимости, включая транзитивные.
npm update (ну или регенерация локфайла) тоже обновляет зависимости только до тех, на что согласны все остальные зависимости.
Хотите обновить на версию, которая выходит за эти ограничения? Подумайте 3 раза, надо ли оно, почитайте breaking changes.
Это вроде касается и разработки кожаными мешками. Как ии тут отличается?
Почему он будет переписывать код совсем по-другому? Вы не задали ему конкретную задачу? У вас нет контроля версий? У вас нет спеки проекта? У вас тесты уровня "статус 200 и ладно?".
Я пару раз делал большие апдейты на сгенерированном claude code пет-проекте (около 100к строк кода) - оно меняло только в пределах реально сломанных частей, не пыталось изобрести велосипед. Но я и при изначальной разработке заставлял его вести дизайн-док и историю сессий. Если я пытаюсь сделать что-то абсурдно трудозатратное (ну, например, поменять ui либу) - оно, наоборот, пытается меня остановить.
Странное ощущение, что описана проблема буквально высосанная из пальца. Ибо:
Код не может ломаться сам по себе. Ну вот нет такого, что он полежал месяц после "зелёных" тестов и внезапно испортился. Тут либо тесты косые, либо одно из двух
Мажорные версии пакетов не появляются внезапно. И перед любым таким upgrade просто обязательно вникнуть во все breaking changes, понять и поправить все то, что с новыми версиями несовместимо. И да, lock-файл к пакету - это то, без чего нормальная разработка в принципе невозможна (IMHO) (засада может быть и в минорных, но тут стоит подумать, надо ли с такими пакетами вообще связываться)
Но если код таки ломается, стоит не cicd наворачивать, а задуматься о том, не фигню ли я с помощью нейронки навайбкодил.
Гниение не в нейронках, а в заполоняющей социум иллюзии, что темерь напрягаться не обязательно, что теперь агенты будут кодить, а мы их будем просто попинывать
Об этом уже писали выше, но это проблема не нейронки, а js экосистемы. Я с этим сталкивался еще за годы до выхода нейронок, и тут было только два решения - фиксировать зависимости, а потом страдать раз в N месяцев, когда обнаружена критическая уязвимость/браузер перестал поддерживать старый движок итд; или же страдать каждый день по-чуть-чуть, держа зависимости всегда актуальными.
Характерно, что за пределами JS экосистемы таких проблем нет, что как бы говорит о том, что LLM ни при чем
Это не баг. Это фундаментальное свойство любого сгенерированного артефакта, у которого нет механизма адаптации.
Вы не делаете код воспроизводимым. Вы делаете окружение статичным. Это разные вещи.
Это не артефакт. Это тепловой шум.
Интересно, почему нейронки так любят противопоставления в своих текстах, кто-то в курсе?
Я просто хотел, чтобы код от Claude не поломался через месяц. Пришлось сделать runtime для воспроизводимости AI-кода