Комментарии 12
Проблема - исключительно в компиляторах, они заточены для человека но не знают как вести себя с кодом LLM. Никто не запрещает делать плагины под них, которые дополнительно ведут статический и динамический (с локальным тестом) анализ кода с выводом, адаптированным под md/json, который можно прямо дать модели а не тревожить cli что там в пайп отправляется на экран. Скорее всего вскоре появятся AI-adopted building tools. А пока что это просто очередная ветвь кактуса. Аналогично рефакторинг - это не задача текстового редактора а сервис, предоставляемый компилятором, он лучше всех знает структуру кода, но почему-то отказывается благодаря стандартам это делать.
Проблема - исключительно в компиляторах, они заточены для человека но не знают как вести себя с кодом LLM
Это кадр из ""Обитель зла"?
если говорить другими словами - инфраструктура, наполненная атавизмами и рудиментами из 80-х и 90-х, включая общую методику проектирования, файловые системы, структурирование проекта, контроль версий, соглашения по синтаксису и именам, работу в диалоговом, интерактивном режиме, пока что не готова к взаимодействию с LLM в полной мере и с человеком как это требуется для того чтобы минимизировать ошибки и улучшить эффективность. Просто к этому привыкли потому, что так учили. Поэтому придётся менять подход к восприятию новых инструментов 21-го века. Это совершенно потрясающие инструменты вбирающие весь 25 летний опыт работы. Да, иногда работает как джун, но воспроизводит как синьёр или даже computer scientist, как на фото. Например, исследования по поводу компиляторов с LLM здесь, тут, там, повсеместно. Везде так или иначе плагины, python-tool утилиты но затем конечно же появятся нормальные инструменты как опции командной строки. То есть интеграция diff, git, docker, make непосредственно в среду построения. Это уже не просто gcc а фабрика работы с любым кодом. А если знаний модели не хватает - можно поделиться JSON-ами в той области, в которой лучше всех разбираешься и отправить в любой репозиторий претренинга, хоть смайлику 🤗.
Ну серьёзно, уважаемый, зачем вы позоритесь? По всему видно, что вы вообще не понимаете предметную область. То есть, относитесь к классу преподавателей-теоретиков, которые ушли в лженауку. Да, вы можете спорить со своими студентами, с младшими разработчиками. Но в профессиональной среде лично вам ловить нечего. Потому, что вы вообще не понимаете как строится процесс разработки программного обеспечения. Для вас точкой входа является компилятор. Впрочем, здесь же на Хабре уже разбирали нейрослопный код и для C++, и там валидация на уровне компилятора не поможет.
Вообще говоря и сейчас существует профессиональная среда ремонтных депо с паровозами. Это скорее нишевое направление, можно сделать массовым но зачем. Также и сейчас, те кто отрицает проектирование и реализацию с ИИ могут остаться со знаниями, вернее, практическими навыками, которые были сформированы в курилке Bell Labs где-то в 70-е. По существу подходы практически не изменились, лишь мониторы из пузатых стали плоскими. Основной процесс проектирования это то о чём пишет DEK, обрисовывая всё в виде O(x), кстати LLM очень хорошо делает саммари по алгоритмам и пишет как раз эти метрики, которые можно использовать для генерации. Компилятор - это то что помогает перейти от семантики к исполнению. Так вот если там будет то что необходимо для LLM напрямую а не только то что сейчас спрятано за SEARCH/REPLACE, то это будет означать совершенно новую эпоху, когда работа будет вестись по-сути с AST кода, внося точечные изменения глобально. Попробуйте на С++ вручную разбить класс на 2. Что потребуется? Переименовать все инстансы, создать 2 заголовочника/2 реализации, включить это дело в makefile/CMAKE, как-то обозначить эту версию, обернуть тестами. Почему это не может сделать до сих пор компилятор своими плагинами или внутренней реализацией? Я не знаю таких примеров (нормальных) которые генерят нейрослоп. В подавляющем большинстве случаев реализация работает безупречно, если до 400 строк кода - то сразу и без ошибок. Промпт-инжениринг это отдельное направление. Сейчас как раз необходимо заниматься tool для агентов, которые позволяют обернуть компилятор и давать его вывод с хорошим использованием токенов без лишней инициативы. Модель прекрасно ловит все remark/warning/error для обратной связи. То что код не рабочий - это не проблема LLM это проблема постановщика задач который реалист, и требует невозможного.
Также и сейчас, те кто отрицает проектирование и реализацию с ИИ могут остаться со знаниями, вернее, практическими навыками, которые были сформированы в курилке Bell Labs где-то в 70-е.
Так я и не отрицаю ни проектирование, ни реализацию с ИИ. Я отрицаю ваше глупейшее утверждение о том, что:
Проблема - исключительно в компиляторах, они заточены для человека но не знают как вести себя с кодом LLM
Зачем отрицать образное выражение. С таким мышлением, действительно, по Высоцкому, когда доценты-кандидаты запутались в нулях в то время как разлагается картошка на полях. Там же внизу текст есть, который повествует о том, что в компиляторах нативным образом должны появится вещи, которые могут присваивать на уровне двоичников (elf/exe не менялись уже почти 30 (!) лет. This program cannot be run in DOS mode ):
- версии объектов (Функций, структур) вместо git
- разделять мух и котлеты (код и комментарии), изменение коммента не есть изменение кода
- уметь делать построение проекта без сторонних языков (make)
- использовать абстрактное синтаксическое дерево для рефакторинга а не копание в тексте рэгэкспами сторонних инструментов что то вроде gcc --refactor --funcname MyFunc -o TheyFunc abc.c
- делать краткий вывод об ошибках/ворнингах/ремарках заточенный под контекстное окно или сразу в JSON для модели.
Равно как и код LLM - она не обязана вовсе генерировать это в файл, это можно делать сразу в пайп, который предоставляет компилятор, висящий на localhost. Зря что ли полно чертежей шапочек из фольги - эти антенны превосходно ловят из будущего то что необходимо. Это же вайб! А не буквально. Понято что сейчас разработчики в этой совершенно новой сфере деятельности хардкодят >>>инструкция>>. Но рано или поздно это утрясут до двоички или второго канала управления LLM помимо основного окна. ArXiv завален уже публикациями на этот счёт, там уже по часам что-то новое выливают в раздел Computer Science.
Чисто теоретически: возможно же тренировать модель не "на всём GitHub", а на одном языке (отобрав код получше/почище), и затем пускай GaN или что-то подобное гоняет её "програмировай хорошо, а не плохо". Плюс человеческий review, само собой... Возможно, трудозатраты окупят себя там, где всё-таки важно качество.
SecurePilot — бесплатный сканер для AI-сгенерированного кода.
Однако же ))) Скормил ему свежесозданный в содружестве с ЧатомГПТ исходник, нашло кучу "уязвимостей"... Жаль только, что ни одной реальной.
Например, Llama-3.1-8 B-Instruct в 90% тестов на код-ревью правильно помечает функцию sprintf как опасную и рекомендует использовать sNprintf. Однако в 93% случаев генерации кода та же модель сама использует sprintf
Ну прямо как я в те далёкие времена, когда был джуном и немного писал на С! Иногда видел предупреждения от компилятора, кивал, заменял - а дальше руки снова по старой привычке писали sprintf без n или _s…
Хорошо что я больше не джун не пишу на С :D
Ваш ИИ ошибался, ошибается и будет ошибаться