Комментарии 29
И до ката сразу на картинке из чата мы видим грубую ошибку, хоть и грамматическую=)
По мне так надо как-то "заслужить" возможность кодить с помощью ИИ, иначе мозг не будет натренирован видеть дичь, которую может сгенерировать нейросеть. Но обучаться с его помощью интересно.
Промпт: "Создай функцию на Node.js для обработки HTTP POST-запроса /api/users, которая принимает JSON-объект с полями name (строка, обязательно), email (строка, обязательно, формат email) и age (число, необязательно, от 18 до 99). Функция должна валидировать эти поля, использовать библиотеку Mongoose для сохранения данных в коллекцию users в MongoDB. Обеспечь обработку ошибок валидации (возвращать 400 Bad Request с сообщением об ошибке) и ошибок базы данных (возвращать 500 Internal Server Error). В случае успешного сохранения возвращай сохраненный объект пользователя с кодом 201 Created. Мне нужен только код функции, без дополнительных пояснений."
Я одного не пойму: зачем мне писать эту простыню, еще и постоянно переключать раскладки, если кодить тупо проще? А потом еще простыню с уточнениями. А потом еще тысячу для других функций. А потом проверять.
Ок, для работы в незнакомой среде это хороший костыль. Но иначе это как предложение садиться в машину не через дверь, а через вайб-багажник. Или играть на гитаре не голыми руками, а в специальных вайб-варежках.
Еще иронично, что в массе своей разрабы ненавидят TDD и часто полоскают Роберта Мартина, как его главного апологета. А когда им продают тот же TDD в модной-молодежной вайб-обертке - так сразу ням-ням.
Ну это не очень хороший пример. если мы говорим о курсоре или клауд коде, то качественная подготовка правил в проекте с описанием инстурментария и правил разработки решают почти 80% вот этих проблем с расползанием контекста. Это надо сделать один раз, аккуратно собрав описание и документацию внутри проекта. Кроме того это очень полезно и для коллег и новичков - становится понятны и принципы работы и архитектура. Конечно это все отностится к небольшим проектам, а также микросервисам. Монолит на миллион строк пропихнуть в правила для контекста я пока не вижу возможности.
Вообще инструмент очень хороий, но расхолаживает. Если постоянно писать через ИИ, то начинаешь потихоньку ржаветь. Глазами код понимаеш и знаешь где нужно поправить и как правильно, но если вдруг надо что то переписать - требуется время чтобы руки вспомнили.
Впрочем это не беда, несмотря на некоторые минусы с помощью этого инструментария можно очень быстро попробовать несклоько гипотез и тут же вернутся к исходному поведению через git.
Никто так не пишет. Пишут агенту - добавить ендпоинты для такой то фитчи, в качестве примера смотреть модули такие-то. Потом правится вручную или рефакторится новым ароматом.
Не думаю что олдскулы против приведенных примеров. Скорее всего дело в другом, а не в приведенных примерах. Сколько займет времени у олдскула описать детально промт и его корректировать раз 50 под ИИ, если он за это время уже готовую фичу выкатит, даже если с багами.
Честно говоря, не знаю о чём тут вообще спорить.
Для меня изменение в рабочих процессах вполне очевидное: теперь можно код не писать, а читать. Как обыкновенное алгоритмическое автодополнение а-ля Intellisense, только генерящее на 2-3 порядка больше кода за один раз.
Программист не код пишет, а превращает описание задачи на бизнес-языке в описание задачи на языке программирования. Он прежде всего отвечает за адекватность этого превращения, для чего ему нужны знания не только в информатике, но и в предметной области, а ещё здравый смысл. Любой разработчик неизбежно знакомится с предметной областью в той или иной степени, иначе он просто не нужен в проекте.
Вот собственно эту «адекватность превращения бизнес-задачи в код» пока непонятно как возлагать на LLM. Это так же странно, как возлагать эту адекватность целиком на джуна, пришедшего в проект 2 недели назад, без какого-либо ревью его работы.
Десятки лет развития языков и методологий программирования были направлены на то, чтобы человек, как существо ненадёжное по своей природе, могло создать что-то БОЛЕЕ надёжное, чем он сам. Мы придумали для этого статическую типизацию, мы придумали для этого кучу различных видов тестирования, где-то даже используют формальную верификацию. И самое главное: код — эта такая штука, которую могут почитать НЕСКОЛЬКО человек (в том числе и сам автор через некоторый промежуток времени). Такая вот коллективная и итеративная работа над кодом даёт нам шанс делать системы более надёжные и продуманные, чем каждый человек может по-отдельности.
Не вижу чтобы нейросети тут кардинально что-то поменяли кроме того, что теперь «автодополнение» подставляет вам не название функции, а создаёт сразу PR. Но ответственность за соответствие этого PR задачам бизнеса по-прежнему лежит на вас.
было бы правильнее написать - борьба между кодерами и быдлокодерами.
но это не борьбп а обычный холивар - менеджеру проекта решать какой код он хочет видеть в проекте например в хависимости от того как потом этот код будет сопровождатся
Самое печальное, что ИИ уничтожает джунов, как класс.
А как появятся новые поколения мидлов и сеньоров, которые будут создавать высококачественный код для обучения LLM?
ИИ сама себя будет обучать)
На чём? На своих галлюцинациях?
Обученные на результатах сеток сетки показывают нарастающее ухудшение качества https://www.tomshardware.com/news/generative-ai-goes-mad-when-trained-on-artificial-data-over-five-times
Мне сильно не хватает какого-то стандартизированного языка постановки задач для LLM, навроде SQL, для формализации и уточнения промптов. Те, разраб набрасывает каркас решения на этом языке, а агент обмазывает его рабочим кодом по заданным, например в специальном дот файле формализированным параметрам. В текущем же состоянии вайб-кодинг напоминает попытки объяснить уделенному индийскому кодеру (пусть и умелому) задачу по телефону на ломанном английском, который вы оба плохо знаете. Задача решается, но с кучей ненужной отсебятины, которая тратит токены и требует очистки, без уверенной возможности рулить структурой.
Мне сильно не хватает какого-то стандартизированного языка постановки задач для людей, навроде SQL, для формализации и уточнения ТЗ. Те, аналитик или продакт набрасывает каркас решения на этом языке, а разработчик обмазывает его рабочим кодом по заданным, например на специальной страничке в Jira, формализированным параметрам. Задача решается, но с кучей ненужной отсебятины, рефакторинга, которая тратит бюджет компании и требует очистки, без уверенной возможности рулить структурой.
Извините, не удержался, чуть-чуть перефразировал то же, что и вы про индуса писали.
Ну нееет) Я говорю именно не о ЦЕЛИ кода (за которую отвечают аналитики и продакты), а его конкретной реализации, ЧТО пишет нейронка) Для верхнеуровневого постановщика задач, что разраб, что нейронка одинаковый черный ящик, возвращающий удовлетворительный или не удовлетворительный результат, ему плевать, что там внутри. Бить разрабов за лишнюю работу и трату ресурсов это работа тимлида) А разраб отвечает за техдолг, за содержимое кода и его поддерживаемость, и именно с этим у нейронок часто проблемы. Хотелось бы иметь возможность ограничивать формализированными рамками их полет фантазии и размах мысли.
Это кстати забавно, но уже есть подход когда задача пишется на условном псевдокоде и потом отправляется в LLM. Идея не такая уж и плохая. Мне кажется вы самостоятельно можете разаботать такеие правила конвертации языка постановки задач и потом каждый раз кормить его описание в контекст чтобы модель могла его использовать.
Из интересного - очень даже неплохо получается делать e2e тесты и даже фичи используя BDD Gerkin как основую. Модели хорошо его понимают, есть описания всех принципов в Context7, есть готовые инструменты конвертации тестов и исполнения тестов. Такой пошаговый сценарий неплохо позволяет работать в DDD или FSD и генерировать хороший бизнесс код.
Это не ответ на ваш вопрос?
Вот, нашел вот такое. https://sjgarstack.org/blog/20231102/introducing-sudolite
То о чем мечтали?
Еще есть вот такие приколы, но это кажется проще руками сразу реализацию писать.
Задача: Найти самую длинную подстроку без повторяющихся символов
ПСЕВДОКОД:
использовать скользящее окно
левая_граница = 0
максимальная_длина = 0
множество_символов = пустое множество
для правая_граница от 0 до длина_строки:
пока символ в множестве:
удалить символ на левой_границе из множества
увеличить левую_границу
добавить текущий символ в множество
обновить максимальную_длину
Мне сильно не хватает какого-то стандартизированного языка постановки задач для LLM
Скрытый текст
другие говорят, что код — это то, что написано руками
придумали глупость и приписали другим, отличный реторический прием. Код можно писать хоть задницей, важно кто модель этого кода создает - разработчик у себя в голове, или LLM. Если бы был способ быстро перегрузить созданную в голове разработчика модель в LLM, то и спора бы не было - никто же не спорит о полезности, например, зоны Брока. В таком случае это действительно был бы просто новый, очень полезный инструмент.
Лично я считаю, что ИИ полезна, но только в следующих случаях:
Генерация regex (для меня проблемно что-то жёсткое сделать самостоятельно в этом, а они вроде неплохо справляются)
Генерация учебных пособий (в качестве старта в какой-то технологии сложной - очень хорошо идёт)
Генерация документации и комментариев к коду (но это не особо безопасно)
В остальном (на моей практике) нейронка часто галлюционирует, пишет шаблонно и качество оставляет желать лучшего.
А классный ник. Тоже их люблю
Наблюдаем как о кодинге с АI пишут продакт менеджеры, ждём пока наконец об этом начнут писать синьор девелоперы.
Сам бы написал, если бы считал себя таковым. Утомляет читать чушь.
Простите, но я люблю писать код. За поддержку OSS проекта у меня есть бесплатный Copilot Pro и я периодически пытаюсь им пользоваться. Если обычно я пишу код и получаю от этого удовольствие, то с Copilot я делаю бесконечные code review. Он мне код, я ему комментарий. И так по кругу. Причем его изменения всегда непередсказуемые и приходится перечитывать весь код сначала. Раз за разом. Час за часом. Если человеку в ревью можно коротко написать, что не так, то ему нужно разжевать иначе его опять понесет ни туда. Удовольствия от работы ни остается от слова совсем.
Простите, я для этого не нанимался.
Для себя заметил что лучше всего результат получается если сначала заставить ии описать решение, а только потом разрешить трогать код. Промпт типа "не трогая код, опиши словами как бы ты сделал ...". Потом пяток уточнений чтоб поставить его на нужные рельсы - и потом уже "ок, теперь сделай то что описал".
10 промптов вместо споров об ИИ: как мы сэкономили недели разработки