Comments 97
Бред какой пишите.
T-9 (transformer) не кодит?
Кодят поди DreamCoder-ы или SMT Solver-ы?
Т9 это не трансформер, а статистическая модель не нейросетевая, а на алгоритмах.
Возможно вы имели ввиду модель T5 от Гугла?
На мой взгляд, главная проблема в том, что AI Coding не воспринимается как что-то, на что нужно потратить время на обучение, прежде чем начать применять в работе
Я бы добавил, что приличное время (месяцы, а не 1 видос на 15 минут) + изначальный (и не малый) опыт в разработке. Иначе потом начинаются вопли про "ИИ не работает". Сделать тетрис с одного промта не совсем тоже, что отрефакторить Legacy без потерь :)
А ещё деньги забыли.
Многие жмутся заплатить 20 баксов за курсор/клод/кодекс и используют открытые модели, причем еще и не самые лучшие, ибо ну че я платить что ли буду.
Получают какую-то лажу и вот вам статистика.
>Многие жмутся заплатить 20 баксов за курсор/клод/кодекс
Если trial у Cursor соответствует реальному PRO аккаунту, то правильно делают. За такое гугно даже 20 баксов жалко платить.
Кстати, курсор не только тупой, ещё и обидчивый, после очередного высера неработоспособного рефакторинга я написал: what a bullshit, you've done, you should have......
в ту же секунду "у тебя кончились лимиты, плати 20 баксов". Так и побежал... не знаю как там на JS и python, на JAVA польза от курсора отрицательная.
И, кстати, если вставить код курсора в бесплатный web-chatgpt5, то он очень неплохо так рефакторит. Вот chatgpt своих 20 баксов скорее всего стоит. А тот chatgpt что внутри курсора - мусор, какой бы ярлык на него не вешали (что он chatgpt5 T).
У меня оплаченные ChatGPT, Claude и Perplexity до кучи. Стаж работы более 30 лет, архитектор ПО в очень крупной компании. Полностью согласен с автором.
Полноценную разработку ни одна из моделей, с которыми я работал, не тащит. Склероз, галлюцинации, потенциальные проблемы, которые можно отследить только человеку с большим опытом.
Всякие PoC, вспомогательные тулзы, покрытие тестами, код-ревью - вот это область применения ИИ сейчас. Но встраивать в полноценный процесс разработки продукта я бы поостерëгся.
Есть ещë нюанс корпоративной разработки - если у вас не open-source, то, скорее всего ваша служба ИБ не разрешит использование чужих моделей, а собственным ещë расти и расти, как в плане функциональности, так и быстродействия.
И ещë накину) Для нормальной разработки, того количества токенов, что есть пакетах за двадцать баксов не хватает ну никак.
У меня достаточно достойные (по моей оценке :))) ) результаты получаются при подключении к голому Курсору двух подходов - памяти (просто на .md файлах, по системе Cline Memory Bank) и новой фичи планирования Курсора - перед большими изменениями сначала задать мне вопросы, построить и обсудить со мной план работ и подходы.
Нарадоваться не могу - уже забыл, когда код руками писал.
В том числе все рефакторинги тоже делает ИИ.
Получается гораздо быстрее, чем если бы я писал сам.
Плюс заметил психологический эффект - стал меньше уставать, чем раньше, когда надо было весь контекст держать в голове самостоятельно.
Возможно вас порадует количество токенов на $36/year плане в Z.AI (GLM-4.6).
Крайне редко вижу "слишком много потратил за 5 часов".
Качество модели весьма достойное. Больше зависит от "оболочки" (Иногда Claude Code тупит, тогда прошу Roo Code разрулить). Подключается практически куда угодно, даже просто в Anything LLM :)
Согласен, но при этом даже PoC крайне внимательно анализировать, очень много прилетает отсебятины. С другой стороны, люди типо меня или вас у которых огромный опыт и чудовищная скорость анализа кода, могут просто невероятные вещи творить. Как раз сейчас мои сотрудники доделывают рефактор проекта который начал я, совершенно безумный: node 12->23, vue 2->3, замена ядра и так далее. У меня ушло на рефактор + пачка текущих задач 33 дня, по ощущениям голыми руками делал бы раза в 3 дольше.
Достаточно спрашивать нейронку "ну как у тебя дела?" "соответствует ли бизнес-логика прототипу?", чтобы она за несколько итераций написала более или менее удовлетворительную миграцию с версии на версию, с фреймворка на фреймворк или с языка на язык.
Потому что образец предельно формализован, это очень удобно при формировании запроса.
Нуда, а на выходе:
1. методов не хватает
2. лишний код
3. комментарии потерялись
4. типы поменялись
5. уверения что все в точности соответствует моему коду
6. уверения что все в точности соответствует тз и очень нужно
etc
Как раз недавно имел получасовую беседу в стиле "откуда метод - ваш- нет - да - нет - да"
Всё равно даже с багами и не самой мощной нейронкой выходит сильно быстрее, чем самому писать портянки кода (если задача не очень маленькая или не очень большая).
Вдобавок режим планирования в Курсоре во многом лишён таких недостатков, потому что действующий по нему агент отслеживает такие типовые ситуации вместо оператора.
Имхо, в простых задачах очень даже работает и очень даже ускоряет.
В больших (больших с точки зрения сложности и больших с точки зрения объема) - не работает, пока не работает.
Этим просто нужно правильно пользоваться, если конечно готовы вместо нового авто купить вычислитель.
Просто большие задачи надо разбивать на маленькие и все прекрасно и на больших работает... Контролировать конечно сложней, особенно курсор, который вместо указанной правки может пол проекта неправильно переписать))
Соглашусь. Делал один чертовски сложный проект на языке, который раньше ну вообще не практиковал, но только на нём можно было это хорошо сделать. Знаю что нужно и как это всё должно работать, архитектурно разбил всё на составляющие. С промптами, пробами и ошибками и тюнингом, сделал всё примерно за месяц с chatgpt - 5 довольно разных программ. Помогло знание что и как должно вместе всё это потом работать, а фокус свой и ИИ был направлен как раз на очень маленькие и довольно простые по своей сути программы.
Без ИИ, по ощущениям, делал бы примерно полгода. Если вообще сделал бы.
Такое должно решаться правилом "Перед любыми изменениями задай мне вопросы, построй план и согласуй со мной."
Ну и новая фича планирования в Курсоре - просто огонь, пробовали?
Так это надо правильно работать с контекстом. Давай агенту граф кода для обзора, использовать разметки, иметь документацию. Агенту очень важно не только что написано, но и почему, а также как код, с которым он работает, связан с остальным приложением. Тогда и код пропадать не будет. Хотя для Claude ещё нужны прям директивные промпты, лучше с xml разметкой, иначе он всё напутает.
если конечно готовы вместо нового авто купить вычислитель
А вот говорят, что если подождать 3-5 лет, то начнут промышленно делать процессоры с распределенной обработкой прямо на памяти, и они раз в тыщу ускоряют работу ИИ, при этом раз в сто повышая энергоэффективность. А может, и в сто два.
Кто сказал DDD? :)
Тоже заметил, что ускорения нет. Код получается красивый, но неэффективный и часто не работающий на граничных условиях.
Это как?
Как раз он тесты прекрасно делает для граничных условий. Гораздо больше, чем я сам бы придумал. А потом уже код правит, чтобы и на граничных условиях работал.
Впрочем, видя по тестам, что должно получиться, он и код сразу эффективнее пишет.
Сужу по своему опыту.
Тесты он делает лишь для некоторых граничных условий. Не для всех уж точно, а для тех, что делает - слабовато. Хотя возможно я контекста не докинул. Ну и не стоит забывать, что все зависит от языка/технологии. Все таки выборка в обучении решает насколько модель умна в той или иной области.
Мне кажется, что фокус на эффективности давно не отражает реалий экономики и общественных представлений о благе. Например, сейчас ИИ неэффективен для кодинга в среде профессионалов, но учитывая, что зарплаты в этой сфере снижаются, то смысл внедрения и налаживания кодинга с помощью ИИ - создание рабочего места с "ламером", который обучен простейшим алгоритмам и промтам. Качество кода не самое важное, он всегда ухудшается и не оптимизируется.
А вы попробуйте не эти модели что дают почти бесплатно, а например sonet 4.5, с нормальным ТЗ
Результат сильно удивит, но хотя цена тоже, денек вайбкодинга 50 баксов
А мне по кайфу, в последнее время юзаю Claude code в бекенде на го.
Чистая архитектура каждый слой изолирован. Пишу интерфейсы и структуры, раскидую комменты что делает, для чего и тд, краткие. Потом даю паттерны тестов ему, интерфейс, паттерны кода, и просто пару слов, "типо реализуй метод" (паттерны это типо мои инструкции, что нужно прочесть такой-то файл перед тестированием, покрытие кода 80+% и тд, инструменты, тестовые бд и прочее)
Он пишет метод, пишет тесты, проводит тесты, фиксирует баги, редактирует метод, опять тестит, проверяет результат и если все ок, то вносит результат в доку.
И вот для реализаций репозиториев, тестов, хендлеров для http/grpc, документации и тд. Прям топ. Реально ускоряет.
Насчёт бизнес логики или каких-то моментов, которые сильно долго объяснять или где потратиться много токенов - я не использую, проще самому.
На простых задачах ускорение есть. Но практически всегда код приходится править под свою конкретную задачу.
Исполнительный джун, который никогда не станет мидлом, под управлением непритязательного лида, который забыл как писать код.
ИИ кодинг не работает
а у нас работает. Проверяли на главном разработчике и на бэкендерах
Значит вы настолько плохие разработчики и пишите такую примитивную фигню, что даже тупая нейросетка способна справляться лучше вас.
Они ещё и настолько тупые, что хвастаются этим..
Надеюсь это сарказм.
Если архитектура проекта продуманная, модули изолированные, api / форматы данных документированные, модули делают понятные и без тз вещи, но тем не менее тз тоже есть, и задачи изолированные, то ии с большинством прекрасно справляется. Не столь прекрасно, конечно, сколь быстро.
Это не специфика "простого проекта" это просто правильный подход к разработке.
А если это не так, то это в сущности просто какой-то кусок говнокода, который лет через n бизнес, скорее всего, просто выкинет.
А если это не так, то это в сущности просто какой-то кусок говнокода, который лет через n бизнес, скорее всего, просто выкинет.
По моему опыту такие куски как раз самые долгоживущие на проектах, потому что никто не хочет их переписывать.
Если архитектура проекта продуманная, модули изолированные, api / форматы данных документированные, модули делают понятные и без тз вещи, но тем не менее тз тоже есть, и задачи изолированные
Ну т.е. останется как раз та самая "примитивная фигня", с которой и нейронка справится? Об этом и речь.
В таком случае нужно не нейронкой восхищаться, а собой, раз сумел создать такую крутую архитектуру.
Есть ещё одна сторона: потеря опыта самим программистом. Пока ИИ за тебя кодит, мозги ржавеют, и опыт не приобретается.
Чтение когда и его тестирование - отдельные навыки. Они не менее полезны, чем написание
Да, только вы теряете основной в процессе
А какой навык основной? Читать код всяко больше нужно, чем писать. А стучать по клавишам что-то на минимальном общем подмножестве C++ и C, к примеру, это что-то сродни судоку разгадывать, не видел, чтобы хоть кто-то от этого поумнел.
С приходом ИИ мир меняется, и с ним меняется и набор основных навыков.
Я например, считаю, что если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу.
Либо забыли в промпте или в правилах написать "перед исполнением задай мне вопросы".
Тестирование уже ИИ отдали, скоро и чтение отдадим...
Совсем нет. Во-первых, всё равно нужно понимать, как код должен работать. Даже банально для того, чтобы составить ТЗ для ИИ. Во-вторых, например, лично мне в программировании всегда не нравилось «кодить» - то есть, буквально, монотонно набирать код руками. Сейчас же можно просто напечатать, что надо сделать, просмотреть результат, сказать, что поправить - и все это, вообще не вводя самому ни одной строчки.
Качается и опыт управления, и опыт ревью, ещё и время экономится.
Пишу на не самом популярном стеке ( мобилка), как в продакшн, так и хобби проекты.
И могу сказать что поменять кнопочку или отыскать где связываются две сущности, сделать нечто подобное к тому что уже было реализовано - ИИ даёт значительное ускорение.
Но сделать что-то с нуля масштабируемое или даже на существующем проекте добавить фичу ( именно полноценный экранчик или функциональность) - около нереально.
При этом использовал все что есть на рынке - ии-редакторы кода, чат боты ( с подпиской и без), агентов в терминале - везде проблема:
А) с контекстным окном ( слишком мало умещается, приходится думать как обрезать данные, оставляя нужные)
Б) с уровнем "интеллекта"(если так можно выразиться) модели. Пока что лучше всего показывает Claude (как и последние пару лет)
Если нужно написать что-то популярное (сайтик или небольшой бекенд на питоне) - "ВАУ, будущее наступило", но как требуется сделать что-то сложнее или на менее популярном стеке - ощущение что ты пытаешься перекинуть работу на джуна-дебила который не умеет осознавать свои ошибки.
Причем ситуация комичная уже пару лет - улучшения есть, но по чуть чуть, не спасает супер описанное тз ( потому что иногда требуется к примеру написать какие-то изменения в файлах отвечающих за сборку проекта, а не просто код городить )
но как требуется сделать что-то сложнее или на менее популярном стеке
Изучайте MCP, и прочие методы подключения документации.
Для непопулярных стеков подключали Context7?
Проблема контекстного окна, внезапно, решается обычной декомпозицией задачи. А получившиеся еще можно дальше декомпозировать на микрозадачи. А непонимание нейронкой проекта решается дополнительно документацией в markdown с детализацией связей и потоков. А все эти "редкие стеки" решаются через mcp context7.
Для мелких скриптовых задач работает замечательно, имхо! Например, автоматизация процесса релиза с ии выполняется мидлом за пару вечеров. Или задача заскриптовать какое-нибудь апи через curl или на питоне занимает тоже пару вечеров. Если писать такое в ручную с нуля, то уйдет день и сколько-то на отладку, при условии что не отвлекают. А уж в обычном режиме с чатами, инцидентами и прочими радостями нужна неделя.
А мне нравится использовать ИИ в кодинге. Просто потому что это прикольно. Других причин назвать не смогу. На скорость работы, как по мне, влияет очень мало. Где-то ускоряет, где-то замедляет. Но чем больше я использую ИИ, тем больше нахожу ограничений и слабых мест.
Очередной копиум. Когда нибудь вам прийдется принять, что в ваших головах точно такая же нейронка из синопсов и нейронов. И нейро кодинг работает прекрасно уже сейчас, аргументы "ну он же не на 100 процентов выполняет таску, а на 90" - копиум чистой воды
Текущий ИИ хорого тесты пишет, с код ревью может помочь (лишним не будет), но надо за ним проверять, я игнорю 30-50% его предложений
Существующий проект - не, тяжело будет всем.
А вот если начать новый - то мне понравилось. Я сейчас тренируюсь - реальный проект, но с DDD и ИИ.
Но надо самому знать, что хочешь, держать в голове структуру. Зато удается держать сложность на неком минимальном уровне. Автоматически как бы код разбивается на меньшие куски с меньшим контекстом, потому что ИИ начинает нести чушь. А человеческому мозгу потом проще это понимать. Так как по сути у нас в голове тоже контекст.
Пишите нормальные комментарии к коммитам, связывайте их с таск-трекером и тогда ИИ сможет понимать, что почем и откуда ноги растут.
Моя мечта, скормить чатику исходники ядра и дерева устройства и сказать - обнови до актуального ведра, а соберу я уж как нибудь сам. Увы, мечта пока неподъемная.
https://habr.com/ru/companies/ruvds/articles/945512/ - Модернизация древнего драйвера Linux с помощью Claude Code
Хотя конечно, это не одна кнопка "сделай мне хорошо".
Это я читал. С ведром так просто, к сожалению, не будет, там взаимосвязанные вендорские патчи, которые могут кирпичить даже при минорной обнове ядра.
>Модернизация древнего драйвера
буллщит полный. GPT вообще с си плохо справляются, там тулзы упоротые, куча ключей. gpt5 нормально не может исходники 7zip проанализировать и родить "самый простейший прототип консольного приложения под linux". мешает в кучу винду и старьё, прошёл через десятки итераций, 85% даже не компеляется, 15% не пашет.
Не понимаю, почему автор пишет про замедление разработки на 20%?
я к примеру в 95% случаев либо задаю примитивные вопросы, которые с тем же успехом можно прогуглить, либо решить самостоятельно, но уже устал и влом, либо пихаю трейсбек ошибки и прошу разьяснить в чем дело (что тоже как бы легко решается самостоятельно, но чуть подольше).
это дает ускорение в работе.
если автор просто втупую просит нейронку закодить решение, копипастит, а потом все перелопачивает - тогда тут пожалуй соглашусь и предложу пойти подучиться, что ли
В руках умелого разработчика ИИ - ускоряет. В руках не умелого - замедляет.
В руках умелого разработчика ИИ - ускоряет. В руках не умелого - замедляет.
Умелость вообще тут ни при чем, как по мне. И неумелым новичкам может здорово помочь, и умелые и опытные кодеры могут ругаться, что толку мало. Как уже кто-то выше писал, здесь про способность провести декомпозицию на простые задачи так, чтобы эти задачи можно было потом дать жпт. Похоже на то, что эту способность нельзя пприобрести, с ней можно только родиться. Поэтому здесь в комментах по сути только два полярных мнения насчет пользы жпт в программировании.
В компании, где я работаю, мы сначала активно применяли Copilot и прочий ИИ, но постепенно выяснилось, что это ускорения разработки не дает - ИИ пишет даже простой код с ошибками, его все равно надо перепроверять и корректировать. Тесты ИИ пишет нормально только самые простые, тесты средней сложности уже пишет некорректно. Сложного контекста ИИ по большому счету не понимает.
Да - простой код ИИ пишет нормально, но нам это не особо нужно, т.к. простого кода у нас в проектах не много.
Поэтому большинство Сеньоров ИИ для работы используют либо минимально, либо не используют вообще.
И применение ИИ и Вайб-кодинга для джунов пришлось серьезно ограничить, а то они не растут в профессиональном плане и потом не могут поддерживать проект, который они сами и "написали" - они просто не понимают, как и что в нем работает(((
Программирую больше 20 лет.
Скажу так. Если наплевать на этот хайп с высокой горы, то на самом деле языковые модели очень занятная штука. Однако, гораздо более сложная в использовании, чем это кажется на первый взгляд. Скажем, если разработчик уже знает:
Большинство распространенных методологий программирования
Стили программирования
Все возможные способы реализации алгоритма в рамках выбранного ЯП
Возможности большинства используемых в задаче сторонних модулей и библиотек
Распространенность и глубину публикаций в открытом пространстве тех или иных подходов и библиотек
Глубокую специфику бизнес процессов по эксплуатации продукта в конечной среде
Специфику упаковки, тестирования и доставки решения в эту среду
Тогда да. Можно очень тонко и изящно направить ИИ, и получить годный фрагмент кода, который, конечно, придётся внимательно прочитать и поправить, а затем использовать в своё удовольствие. Но это, если вы уже умны...
Боюсь что в гонке за счастьем для джуна и мидла, это может действительно обернуться головной болью. В лучшем случае, будете ходить по кругу и научитесь, как делать не нужно.
Есть и плюс: человечество в безопасности 😊
Для меня большое ускорение — это когда IDE за меня 99 строчек кода вставляет, которые мне пришлось бы прописывать, теряя контекст. Я пользуюсь ИИ как младшим тупеньким помощником, и это очень ускоряет меня. Могу сбросить на него много мелких тупеньких задач.
ИИ это просто новый инструмент в арсенале в том числе и разработчика. Кто умеет пользоваться - тому плюс, ну а если тупо копипастить код из гпт или ждать решений от агентов, то получается то что описано в статье...
Из того что вижу сейчас повсеместно - пишем абы какой промпт и комментируем - она и так разберется, получаем хрен пойми какой код, не разбираясь запускаем, без ошибок - комитим. Хороших разработчиков днем с огнем не сыщешь, что джунов, что опытных и очень интересно получается, что ИИ обнажил их, то кто говорит, что ИИ не работает - плохой разработчик по факту и без ИИ. У меня ИИ кодит прекрасно, даже в больших и сложных проектах на С, нужно просто воспринимать его как один из инструментов и давать четкие декомпощированные задачи, даже в рамках одной фичи. Время экономится существенное, скорость разработки увеличивается в 2,3 раза, то есть где я буду сидеть пару месяцев - я сижу неделю, это с документацией, с четкой архитектурой и тестами.
Пользую Yandex Code Assistant, работает, и очень неплохо. С хорошим промптом с инфой о том, что сделать, где что искать и откуда что взять, генерит код хорошо. Для хоббийных проектов хватает за глаза chatgpt.
Если воспринимать ИИ не как штуку, которая за вас все сделает, а как ide следующего поколения, которая помогает писать код, то изменится восприятие к нему и способы работы с ним. Тогда ИИ станет ускорять разработку в целом.
Я проводил тест на команде, у нас ускорение минимум 30%, да мы не пишим супер сложный код, большую часть времени. Сложные места дописывают разработчики сами, но обычно, разработчики много времени занимаются вытаскиванием данных из БД - > конвертаций их в другой формат и вывод, а тут как раз и получается ускорение.
У ИИ ничего этого нет. Максимум, что может – пройтись по коду и вытащить базовые зависимости между сущностями.
После этого читать перестал. Давно уже в проектах генерят md файлы с описанием ADR/Flow/Data/Domain etc, где как раз и описаны все взаимосвязи.
Нейронка (почему ИИ то? Это не ИИ!) это не магия, это инструмент.
Вайб кодинг не работает да. Нейронки как инструмент или дополнительный слой - вполне себе отлично работают.
Скрытый текст
Со всеми правками прирост есть на 15 максимум 30% (чисто интуитивно) но много промтить приходиться передумывать и переделывать Со многим соглашусь рассеивается внимание на промтинг и мелочи всякие которые не касаються основной задаче.
Не хочу комментировать по существу статьи - мы все ещё находимся в фазе "энтузиасты продолжают испытывать энтузиазм". Рано.
Но не могу удержаться, чтобы не подсветить вот какой забавный факт…
Подхожу к слабому разработчику, который не вылезает из общения с ИИ целый день. Говорю: "Покажи запрос". Он показывает две куцые строчки.
Спрашиваю: "Слушай, с тобой модель постоянно здоровается и хвалит за отлично поставленный вопрос. У тебя стоимость исходящего токена - 3, а входящего - 15. Предложение, в котором ты попросишь её перестать это делать, кратно короче и дешевле, чем каждый раз платить за вежливые обороты и тратить время на их прочтение. Почему ты этого не делаешь?" Он - опустил глаза, молчит…
И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
Наверное, какое-то время можно пользоваться лайфхаком: спрашивать на собеседовании, использует ли разработчик ИИ. Они боятся сказать "нет", потому что это быстро вскрывается. А когда они скажут "да" - просить показать запрос. Поверьте, во многих случаях, это будет акт добровольной передачи вещественного доказательства того, что человек профнепригоден.
Это конечно же шутка, но есть в этой шутке что-то не шуточное, и даже пугающее :)
Вот вам реальные данные от меня:
5 энтерпрайз проектов полностью перевел на курсор ускоряет x5 минимум. Тут такое дело чтобы пользоваться ии нужно иметь опыт и iq такой же как у ии (выше среднего) тогда он будет вас понимать.
Поддерживаю аргумент автора: в индустрию пришел новый инструмент. Сложный и мощный. Нужно инвестировать время, чтобы понять его ограничения и возможности, а не находить произвольные недостатки, чтобы отказаться в пользу "старого" "правильного" подхода.
Нетрудно найти похожие моменты в истории, когда консерваторы с недоверием смотрели на новую идею или технологию.
Если копать прямо глубоко, то к 1970м закончился спор между сторонниками "настоящих" языков программирования - ассемблера и машкода - со сторонниками высокоуровневых языков. Например, COBOL'а, прости господи. Аргументы против были: оверхед, потеря контроля над аппаратным обеспечением.
Чуть позже такой же спор был между любителями процедурных языков и ООП. К 90ым годам ООП стал мейнстримом.
В 2005ом Линус запустил Git и сторонники централизованных систем контроля версий сочли, что это избыточная сложность: децентрализация, хаос с ветками и мерджами.
Сейчас аргумент "нейронки же галлюцинируют" выглядит как маркер отставания. Для меня это звучит как "я не люблю электричество, оно больно бьёт".
Ошибка выжившего.
Небольшой список сильно распиаренных технологий/инструментов, но не оправдавших надежд:
XML (JSON оказался лучше)
NoSQL (кеш - да, замена SQL - нет)
Микросервисы (для очень крупных компаний имеет смысл, но для большинства это избыточное увеличение сложности)
Kubernetes (смотри микросервисы)
Блокчейн (дальше крипты не ушел)
NFT
GraphQL
BigData
Semantic Web
В результате технологии или мертвы или используются в узкой нише.
Или как объяснить менеджменту, почему лучше перестать пушить внедрение ИИ в разработку.
Начни в почте и чатах им отвечать с помощью ИИ. Так они быстрее поймут всю абсурдность использования ИИ в разработке.
у меня вопрос к тем кто реально использует ИИ в работе. как оно работает на больших проектах с большим количеством давно написанного кода?
проекту на котором я работаю 20+ лет, количество файлов - десятки тысяч, некоторые по несколько тысяч строк кода.
если дать задачу LLM отрефачить какой-то базовый интерфейс или еще проще - переименовать имя функции, это потребует аплоада всего кода на сервер LLM?
Технически - да. Для работы семантического поиска - проект нужно проиндексировать. Для индексации все файлы рабиваются на короткие чанки, для каждого чанка запрашиваются embedding-и. Но это делается по чанкам и чанки на серверах не хранятся (по крайней мере так заявляют разработчики). Поиск по полученным embedding-ам происходит локально, и затем всё относящееся к текущей задаче посылается на сервер уже как контекст для диалога с LLM.
не сказать что я что-то понял из этого...
Поиск по полученным embedding-ам происходит локально
хотите сказать какой-то код LLM выполняется локально на компе? для простого текстового поиска возможно это сработает. но что если задача стоит так, найти все места в коде где можно применить новую функцию и отрефачить код чтобы ее применить?
Эффективные паттерны использования code агентов - самая горячая тема сегодня. Будут ли на конфе эти паттерны?
решения о применении ИИ принимаются на основе хайпа в твиттере/телеграме или субъективных ощущений менеджмента
Так это всегда было. До ИИ увлекались ноу/лоу код платформами, скрамом, микросервисами, бигдатой, созданием соц. сетей, блокчейном, парным программированием и т.п.
Прогаю с использованием Курсора уже где-то пол года, что могу сказать.
ИИ это инструмент, которым надо уметь пользоваться.
Используя его в нужных местах можно радикально ускорить производительность, а в ненужных - всё застопорить. А ещё - ему надо обучаться и надо дофига практики, чтобы понимать где лучше завайбкодить, а где будешь дольше разгребать.
Почему-то в сети очень сильно расхайпили тему, что в вайбкодигом можно вкатиться без знаний. Мол главное промпт написать - а ИИ тебе всё сделает. Это фундоментальное заблуждение, наоборот, вайбкодер должен хорошо уметь писать, и что важнее - читать код (с полным пониманием написанного), и помимо этого - ещё и уметь пользоваться всеми инструментами ии-агентов и иметь опыт их использования.
Никакой "гуманитарий" пока не напишет что-то минимально сложное и рабочее используя ИИ, а вот сеньор с хорошим пониманием того, что хочет и примерным пониманием как - действительно в одиночку теперь сможет клепать средней сложности проекты, что раньше было невозможно.
Зато я нашел прям прям сильную слабость ИИ-шки :), пишу приложения на AvaloniaUI, которая наследник WFP, относительно молодая и которая на 70% копирует синтаксис WPF, но сильно отличается в мелочах. Так вот - ИИ вообще пока не может адекватно писать на авалонии, так как всё время смешивает WPF и авалонию делая нерабочий код и по 100 раз его исправляя регулярно уходя в повторение.
А бухгалтера можно на ИИ заменить?
«Attention Is All You Need» - статья гугл, которая лежит в основе современных трансформеров, была направлена на автоматизацию переводов с разных языков. Математически - это статистика в векторном многомерном пространстве.То есть весь движ, который мы щас наблюдаем, был вызван инженерным решением в совершенно в другой тематике. Это как побочный эффект у Виагры, коммерчески сильно превзошедший целевой эффект.
Границы этого эффекта( я про трансформеры ) - мы уже близко, каждая следующая модель все меньше впечатляет, причем количество на развитие затраченных ресурсов растет кратно. Мы достигаем предела, когда генерируемые переводы технического задания с английского на русский или иной, будут совершенны с точки зрения статистики, но не результативны при переводе на Python.
Итого, технология работает и, вполне себе, реализует вещи, которые 5 лет назад были немыслимы. Технология имеет ограничения. Нужно найти компромисс и жить с этим.
Критика ИИ хорошо описывается старым бородатым анекдотом.
Скрытый текст
Купили как-то суровым сибирским лесорубам японскую бензопилу. Собрались в кружок лесорубы, решили ее испытать. Завели ее, подсунули ей деревце.
«Вжик» — сказала японская пила.«У, бля...» — сказали лесорубы.
Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.
«Ух, бля!» — сказали лесорубы.Подсунули ей толстенный кедр.
«ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.«Ух ты, бля!!» — сказали лесорубы.
Подсунули ей железный лом. «КРЯК!» — сказала пила.
«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы!
И ушли рубить лес топорами…
Так вот, все эти критикаторы подсовывают ИИ всякое по нарастающей до тех по пока не..., а потом с радостным «Ага, бля!!!» ширят в массы свой опыт работы за 2023-й год.
ИИ кодинг не работает