Обновить

Комментарии 209

Бред какой пишите.

T-9 (transformer) не кодит?

Кодят поди DreamCoder-ы или SMT Solver-ы?

Т9 это не трансформер, а статистическая модель не нейросетевая, а на алгоритмах.

Возможно вы имели ввиду модель T5 от Гугла?

Это происходит от мнения что LLM дополняет текст как Т9, но просто на гигантских гипертрофированных данных. Так что тут имелась в виду именно Т9, распространенное сравнение. Не то чтобы я его поддерживаю, но вот оттуда ноги растут и если встретите подобное ещё раз - это оттуда.

ну совсем ничего не понимающим людям поедающим нейрослоп при объяснении проще с Т9 сравнить, это хотя бы лучше чем они в какой-нибудь там интеллект уверуют

Очередной Руководитель Департамента решил пошутить поправить используя свои превосходные знания.

Однако, программирование - поиск в пространстве функций.

А трансформер(GPT/Bert/etc) - отображение одного множества на другом (c CoT или без. Кот кстати даже не выведен математически :) ).

Это происходит от мнения, что Сбер или Яндекс действительно занимаются R&D, а не перепечаткой публикаций ученых.

R&D, только ЗП как у индусов. И уровень...

Да нет, я написал именно то, что имел ввиду.

Советую почитать еще раз
(про seq2seq, T9, LSTM, Tansformer и прочее)
https://ebetica.github.io/pytorch-Deep-Learning/en/week06/06-3

И станет ясно, что seq2seq модели в кодинг не могут по определению :)

Потому что это (seq2seq, Transformer, etc) - отображение одного множества на другом (и используются seq2seq для перевода).

А от всего остального появляется декартово произведение (Напиши Зеленый модуль в стиле Барокко на C++ - цвета X стиль X язык). И бесполезные модели в триллионы параметров.

Программирование - разработка Алгоритма.

Это делают SMT solver-ы, A* и т.д.

P.S. (ответы на все остальные вопросы)

Я обосновал Multistep (thinking) за год-два до OpenAI.

(В отличие от "Экспертов" c habr и сбербанк, которые не смогли в предметную область и тем более в магию множеств и декартова произведения)

https://medium.com/@PushkarevValeriyAndreevich2/how-to-write-on-verilog-with-chatgpt-or-do-anything-else-796a63c17f9b

К сожалению, сбер не опережает, а отстает даже от OpenAI :).

Когда станете прибыльными и сможете платить хотя-бы 8-16к$ на удаленке (типичная ЗП PhD R&D) - пиши, не стесняйся.

Про нейросети и статистические модели думаю говорить не будем (интересно, почему?)

https://9gag.com/gag/aZZVK3n

И, да, Сбербанк не разбирается в трендах ИИ, Яндекс тоже (денег нет), а вот 9 хомяков с Habr - разбираются xD

https://coub.com/view/39aatk

Ничего не понятно, но очень интересно

На мой взгляд, главная проблема в том, что 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).

я написал: what a bullshit

Линус-режим дороже!

в ту же секунду "у тебя кончились лимиты, плати 20 баксов"
Чистой воды совпадение. Ругаться с машиной бессмысленно, т.к вы делаете это за свой же счет, а для нее все слова одинаковы. А вот несколько интенсивных рефакторингов подряд действительно могли потратить ваш лимит довольно быстро

У меня оплаченные ChatGPT, Claude и Perplexity до кучи. Стаж работы более 30 лет, архитектор ПО в очень крупной компании. Полностью согласен с автором.

Полноценную разработку ни одна из моделей, с которыми я работал, не тащит. Склероз, галлюцинации, потенциальные проблемы, которые можно отследить только человеку с большим опытом.

Всякие PoC, вспомогательные тулзы, покрытие тестами, код-ревью - вот это область применения ИИ сейчас. Но встраивать в полноценный процесс разработки продукта я бы поостерëгся.

Есть ещë нюанс корпоративной разработки - если у вас не open-source, то, скорее всего ваша служба ИБ не разрешит использование чужих моделей, а собственным ещë расти и расти, как в плане функциональности, так и быстродействия.

И ещë накину) Для нормальной разработки, того количества токенов, что есть пакетах за двадцать баксов не хватает ну никак.

У меня достаточно достойные (по моей оценке :))) ) результаты получаются при подключении к голому Курсору двух подходов - памяти (просто на .md файлах, по системе Cline Memory Bank) и новой фичи планирования Курсора - перед большими изменениями сначала задать мне вопросы, построить и обсудить со мной план работ и подходы.

Нарадоваться не могу - уже забыл, когда код руками писал.

В том числе все рефакторинги тоже делает ИИ.

Получается гораздо быстрее, чем если бы я писал сам.

Плюс заметил психологический эффект - стал меньше уставать, чем раньше, когда надо было весь контекст держать в голове самостоятельно.

"уже забыл, когда код руками писал"

Звучит очень даже неплохо, подскажите пожалуйста свой стек и направление в целом? Backend/Frontend или что-то другое? Правда интересно, потому что сейчас наблюдаю очень разный уровень "понимания" со стороны нейронок в зависимости от того, в каком направлении разработки и с какими фреймворками проект

Бэкенд, питон. Фреймворки все попсовые - telethon, fastapi, pandas, streamlit.

Если нужно использовать что-то новое (fastmcp) или редкое (vectorbt) - прошу спрашивать примеры применения у context7 или искать в веб.

Ну наконец-то встретил человека, который пошел тем же путем :)

ConPort + любой таск-менеджер MCP, сохранение/восстановление контекста почаще выведут вас на новый уровень

Посмотрел ConPort.

Понравилась структура сущностей (project brief, decisions, system patterns, links), но кажется, что он сильно жрет контекстное окно из-за длинной стратегии, обилия инструментов и необходимости многоступенчатой работы с инструментами.

Ты пробовал другие инструменты памяти?

Просто text-file based memory rules а ля cline memory bank?

Вот! Буквально смена парадигмы. Нужно нейросетку считать за рьяного джуна, или даже стажёра, просто очень быстрого. Ему нужно очень четко объяснять и с точки зрения желаний и с точки зрения пользовательского опыта и с точки зрения где именно в модулях в коде это искать. Он и сам может в коде пойти покопаться, но надо отслеживать когда начинает делать фигню.

И при прикладыванием должных усилий вы всегда на одной волне, и интуитивно начинаешь понимать, когда уже там гпт-5-кодекс путаться начнёт, сбрасываешь контекст и достаешь из-за пазухи дефолтный промпт инициализации, уходя в туалет, оставляя новую версию падавана разбираться.

Да, это больше похоже на менеджмент, но все таки не совсем. Нейросеть не поссорится ни с кем и не начнет требовать 1-to-1 или пойти закапучинниться.

Такой подход кстати
планирования перед решением и переключением автоматом между подходящими ролями
Применяют из коробки в агенте от яндекса sourcecraft.dev

на практике в итоге смог решить сразу одну задачу, что ставила в тупик Gemeni и Qwen CLI версии

Возможно вас порадует количество токенов на $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

Как раз недавно имел получасовую беседу в стиле "откуда метод - ваш- нет - да - нет - да"

Всё равно даже с багами и не самой мощной нейронкой выходит сильно быстрее, чем самому писать портянки кода (если задача не очень маленькая или не очень большая).

Вдобавок режим планирования в Курсоре во многом лишён таких недостатков, потому что действующий по нему агент отслеживает такие типовые ситуации вместо оператора.

Чтобы писать портянки кода умные люди из Индии ещё 29 лет назад придумали копипасту...

Во 1 не надо писать портянки, во 2 именно написание кода занимает ничтожную часть времени разработчика

>написание кода занимает ничтожную часть времени разработчика

Мнение чела, которого посадили тикеты закрывать на легасятине. И раз в квартал меняют проект. Зачем таким быть?

Чего чего простите?

Ps ... Хотел я написать, но в этот раз пожалуй иначе: чел, ты чё похавал?

Там парадоксальная ситуация, оно может дать результат, если:

а) нужна тривиальщина, в плане тривиальных технологий и тривиальных задач (что логично, на чём обучили то оно и умеет);

б) в задачу закопали кучу времени и усилий, например на объяснение и разжевывание всех деталей задачи/фичи, всего контекста системы и т.д.;

Правда во втором случае получается зачастую столько работы, что проще в итоге сделать самому лол. Ну это если уметь, да. А если не уметь, то я правда даже хз с этим справиться, ибо оно теряет контекст, галюцинирует и т.д.

Хотел я поковоряться в ретро-разработке для которого нет 100500 примеров и реальных опенсорс проектов, которые можно было бы засунуть в модель на её обучение, и сразу выходит пшик - вроде понимает что-то про синтаксис и т.д., но полное непонимание того что реально доступно в API и девтулзах конкретных версий, путает это с более современныи версиями схожих технологий и т.д. В итоге никакого продуктивного прогресса, даже при понимании разработки как таковой.

Вот про собственные модели это прям беда, да беза не разрешает использовать ничего из не своего, а свое сильно проще, чем не свое.

В то же время, до топов уже докатилось, о ИИ делает продуктивнее на ХХ процентов, отлично увольняем нахрен ХХ работников.

Вы, как и автор статьи, как и большинство комментаторов с похожим посылом, начинают с преамбулы типа "я опытный специалист, и вот мой вывод".

Проблема в том, что средний программист в средней конторе этими словами не описывается. Вы пишете лучше LLM, окей. Сравнивать надо со средним разработчиком по больнице, от которого нам досталось крылатое выражение "индусский код".

У нормального менеджера нет задачи заменить вас нейросетью. Но вот выбрать между наймом вам помощника или покупкой инструментов уже вполне можно обсуждать. Да и должен же кто-то вам делать code review :)

Кстати, добавлю, ровно как все автомобилисты ещё и пешеходы, так и все опытные разработчики превращаются в "среднего индуса", если приходится иметь дело с малознакомой технологией и кодовой базой. Мне иногда приходится что-то подкрутить на вебсайте в Javascript, например. Это вот совсем не моё, LLM точно справится не хуже.

Много тестировал самые расхайпленые модели. Почему-то никто и близко не сравнится с обычным дипсиком, причем не кодером, а последним общем. По крайней мере, на дистанции доработки проекта неделями и контекстными окнами с нуля. Кими, квен умудряются начать творить дичь уже на третьей доработке, терять половину кода, сеять баги. У гпт та же проблема, даже с теми кодеропромптами, что по дефолту у них висят в панельке и призваны структурировать пошагово разработку.

А дипсик тупо пишет и пишет, дораьатыаает и ваяет, и даже на смену чата без переноса контекста ему плевать, читает свой код заново, тут же врубается во все тонкости и продолжает исправно трудиться. Ни одна модель из мною испообованых пока что так не смогла.

Я (системный архитектор и фуллстек с 30+-летним опытом) использую ИИ-шки преимущественно в качестве "подсказчика" и для автоматизации простой рутины. Кодинга в моих среднеразмерных проектах ИИ существенно не ускоряет, но сокращает фазу пре-кодинга, т.е. поиска и формализации решений, включая неочевидные варианты.

Думаю, у каждого специалиста, не отвергающего LLM из идейных соображений, есть свои паттерны использования имитационного интеллекта :)

А, прошу прощения, зачем это нужно? Если в конечном итоге результат по параметрам "скорость разработки + качество продукта" будет такой же, как если я просто напишу руками?

Во-первых, это просто интересно :)
LLM и их продукция - сами по себе вполне достойный предмет для исследований.

А во-вторых, полезно на практике выяснять слабые и сильные стороны этого ИНСТРУМЕНТА, который продолжает развиваться. И с результатами работы которого неизбежно придётся сталкиваться чем дальше, тем чаще.

В общем, "utile cum dulci".

С AI Writing совершенно такая же ситуация.
Чтобы получать внятный текст в нужном стиле и без ошибок - систему также нужно обучать

Имхо, в простых задачах очень даже работает и очень даже ускоряет.
В больших (больших с точки зрения сложности и больших с точки зрения объема) - не работает, пока не работает.
Этим просто нужно правильно пользоваться, если конечно готовы вместо нового авто купить вычислитель.

Просто большие задачи надо разбивать на маленькие и все прекрасно и на больших работает... Контролировать конечно сложней, особенно курсор, который вместо указанной правки может пол проекта неправильно переписать))

Соглашусь. Делал один чертовски сложный проект на языке, который раньше ну вообще не практиковал, но только на нём можно было это хорошо сделать. Знаю что нужно и как это всё должно работать, архитектурно разбил всё на составляющие. С промптами, пробами и ошибками и тюнингом, сделал всё примерно за месяц с chatgpt - 5 довольно разных программ. Помогло знание что и как должно вместе всё это потом работать, а фокус свой и ИИ был направлен как раз на очень маленькие и довольно простые по своей сути программы.

Без ИИ, по ощущениям, делал бы примерно полгода. Если вообще сделал бы.

Такое должно решаться правилом "Перед любыми изменениями задай мне вопросы, построй план и согласуй со мной."

Ну и новая фича планирования в Курсоре - просто огонь, пробовали?

Так это надо правильно работать с контекстом. Давай агенту граф кода для обзора, использовать разметки, иметь документацию. Агенту очень важно не только что написано, но и почему, а также как код, с которым он работает, связан с остальным приложением. Тогда и код пропадать не будет. Хотя для Claude ещё нужны прям директивные промпты, лучше с xml разметкой, иначе он всё напутает.

если конечно готовы вместо нового авто купить вычислитель

А вот говорят, что если подождать 3-5 лет, то начнут промышленно делать процессоры с распределенной обработкой прямо на памяти, и они раз в тыщу ускоряют работу ИИ, при этом раз в сто повышая энергоэффективность. А может, и в сто два.

Кто сказал DDD? :)

Тоже заметил, что ускорения нет. Код получается красивый, но неэффективный и часто не работающий на граничных условиях.

Это как?

Как раз он тесты прекрасно делает для граничных условий. Гораздо больше, чем я сам бы придумал. А потом уже код правит, чтобы и на граничных условиях работал.

Впрочем, видя по тестам, что должно получиться, он и код сразу эффективнее пишет.

Сужу по своему опыту.

Тесты он делает лишь для некоторых граничных условий. Не для всех уж точно, а для тех, что делает - слабовато. Хотя возможно я контекста не докинул. Ну и не стоит забывать, что все зависит от языка/технологии. Все таки выборка в обучении решает насколько модель умна в той или иной области.

Промты плохие. Вот всё, что вы тут написали - так LLM и скажите, исправится.

Когда пишешь большой блок, типа вытащить что-то и сделать обработку, то граничные условия в запросе полностью не описываешь, а иногда и задаешь противоречивую информацию. Получаешь процедуры и кажется даже все работает, пока не начинаешь конкретное тестирование. ИИ напоминает очень ленивого и туповатого сотрудника, который любое умолчание контекста, использует чтобы схалявить. Потому сначала приходится делать декомпозицию, и из того что использую (а используя я не так уж много), и только cursor ее делает более менее нормально и самостоятельно.

Мне кажется, что фокус на эффективности давно не отражает реалий экономики и общественных представлений о благе. Например, сейчас ИИ неэффективен для кодинга в среде профессионалов, но учитывая, что зарплаты в этой сфере снижаются, то смысл внедрения и налаживания кодинга с помощью ИИ - создание рабочего места с "ламером", который обучен простейшим алгоритмам и промтам. Качество кода не самое важное, он всегда ухудшается и не оптимизируется.

А чего неэффективен-то? Профессионалу как раз проще и ревью делать, и соломки где-то подстелить при понимании узких мест, и оптимизацию придумать-указать. Это джуны вайб-кодингом занимаются, не вникая в результат и напарываясь на техдолг

Я понимаю вашу логику, но повторюсь, наши с вами представления о логичности/эффективности могут видеться ошибочными из другого тира. Экономика вообще нелогична, а новаторства (прогресс) вообще не подлежат суду "здравого" (а вернее общего - common) смысла, поскольку все новое разворачивается в экономике и практиках жизни редко по плану, а чаще по хайпу. Вопрос только в количестве (выделенных) ресурсов игроками высших тиров для поддержания хайпа как можно дольше, чтобы новаторство прижилось и вросло в психологию масс и экономические проекты как данность, без которой никто уже и жить не может. Вспомните как представляли интернет 30, не говоря уж про 50 (время зарождения) лет назад и во что это вылилось сейчас. Или соцсети. Или крипту. Или еще сотни примеров новаторств, которые входили в хайп истекая часто с произведений футорологов или фантастов, а заканчивались каким-то обсессионным, лишенным изначальных семантик, роением масс вокруг какой-нибудь кнопки или блестяшки, будь то губастые куклы или "защита персональных данных".

Вы с естественным подозрением относитесь к нонешней форме роения масс вокруг ИИ, обосновано видя в этом роении слепоту и отсутствие разумной цели. Но высшие тиры знают, что со временем все хайпы приводят к монетизации и их личному усилению, поэтому их не смущает текущая неэффективность и нелогичность внедрения новаторства, рынок отблагодарит тех, кто идёт против конвенциональной логики и традиций.

А вы попробуйте не эти модели что дают почти бесплатно, а например sonet 4.5, с нормальным ТЗ

Результат сильно удивит, но хотя цена тоже, денек вайбкодинга 50 баксов

Если вы это мне, то не удивит – рекомендую дочитать статью:)

Судя по тому, что там речь была про курсор, статья не актуальная. Из курсора уже почти все поуходили в клод код и сидим на 100 баксах подписке, ничего лучше в данный момент не существует, я пробовал все инструменты. (Еще можно в килокоде на бесплатных моделях кстати вполне успешно работать)

Я про свою хабр-статью выше. Кажется, человек просто не дочитал дальше первой трети. С клод кодом согласен, но Cursor в целом тоже быстро подтягивается плюс есть еще codex-cli - у меня не взлетело, но знаю людей, у кого работает лучше, чем клод код

за 50 баксов в день я просто выучу еще один язык программирования

с нормальным ТЗ

Нормального ТЗ в 99% случаев просто нет. А так где есть - оно устарело на момент старта.

А мне по кайфу, в последнее время юзаю Claude code в бекенде на го.

Чистая архитектура каждый слой изолирован. Пишу интерфейсы и структуры, раскидую комменты что делает, для чего и тд, краткие. Потом даю паттерны тестов ему, интерфейс, паттерны кода, и просто пару слов, "типо реализуй метод" (паттерны это типо мои инструкции, что нужно прочесть такой-то файл перед тестированием, покрытие кода 80+% и тд, инструменты, тестовые бд и прочее)

Он пишет метод, пишет тесты, проводит тесты, фиксирует баги, редактирует метод, опять тестит, проверяет результат и если все ок, то вносит результат в доку.

И вот для реализаций репозиториев, тестов, хендлеров для http/grpc, документации и тд. Прям топ. Реально ускоряет.

Насчёт бизнес логики или каких-то моментов, которые сильно долго объяснять или где потратиться много токенов - я не использую, проще самому.

Это значит лишь то, что для выполнения твоих задач не требуется какой-то серьезной компетенции.

Очень возможно, но таких задач может быть в проекте не так уж и мало

Ровно как и для 99% вакансии на LinkedIn и HH. Не думаю, что даже тут, на Хабре, много кто пишет новые типы индексов в БД или патчит ядро Linux.

Или что у ребят просто хорошая архитектура и документация

Вы праву, по референсу он делает здорово к илево решает проблему чистого листа.

Какой размер кодовой базы у вас?

На простых задачах ускорение есть. Но практически всегда код приходится править под свою конкретную задачу.

Исполнительный джун, который никогда не станет мидлом, под управлением непритязательного лида, который забыл как писать код.

Лид забыл или джун забыл?

bot.giper.dev к вашим услугам.

Когда не знал, да еще и забыл.

ИИ кодинг не работает

а у нас работает. Проверяли на главном разработчике и на бэкендерах

Значит вы настолько плохие разработчики и пишите такую примитивную фигню, что даже тупая нейросетка способна справляться лучше вас.

Надеюсь это сарказм.

Если архитектура проекта продуманная, модули изолированные, api / форматы данных документированные, модули делают понятные и без тз вещи, но тем не менее тз тоже есть, и задачи изолированные, то ии с большинством прекрасно справляется. Не столь прекрасно, конечно, сколь быстро.

Это не специфика "простого проекта" это просто правильный подход к разработке.

А если это не так, то это в сущности просто какой-то кусок говнокода, который лет через n бизнес, скорее всего, просто выкинет.

А если это не так, то это в сущности просто какой-то кусок говнокода, который лет через n бизнес, скорее всего, просто выкинет.

По моему опыту такие куски как раз самые долгоживущие на проектах, потому что никто не хочет их переписывать.

Если архитектура проекта продуманная, модули изолированные, api / форматы данных документированные, модули делают понятные и без тз вещи, но тем не менее тз тоже есть, и задачи изолированные

Ну т.е. останется как раз та самая "примитивная фигня", с которой и нейронка справится? Об этом и речь.

В таком случае нужно не нейронкой восхищаться, а собой, раз сумел создать такую крутую архитектуру.

Так в рядовом случае разработка не то что бы очень сложная штука. Потому с подозрением читаю всякие штуки, когда люди жалуются, что мол нейронка то не может, сё не может, одно правит и кучу всего ломает, - вероятно в таком проекте и людям не сладко живётся, но ставить себе в заслуги, что героически преодолеваешь сложности, которые сам и создал, я бы не стал.

Очень небольшое количество проектов я видел, где есть хоть как-то оправданная сложная архитектура, чаще просто на архитектуру со временем просто принципиально забивают и начинают где-то локально что-то патчить, мимо api какие-то важные данные пробрасывать, и так далее. Где-то в прошлом веке ещё можно было это понимать, как борьбу за каждый байт и такт, но сейчас абсолютному большинству проектов это в принципе не нужно.

Сразу видно, человек не разобрался, но оценку дал

Есть ещё одна сторона: потеря опыта самим программистом. Пока ИИ за тебя кодит, мозги ржавеют, и опыт не приобретается.

Чтение когда и его тестирование - отдельные навыки. Они не менее полезны, чем написание

Да, только вы теряете основной в процессе

А какой навык основной? Читать код всяко больше нужно, чем писать. А стучать по клавишам что-то на минимальном общем подмножестве C++ и C, к примеру, это что-то сродни судоку разгадывать, не видел, чтобы хоть кто-то от этого поумнел.

Ну смотрите. У меня в голове:
- Архитектура приложения
- Планы на будущее переиспользование кода
- Требования стиля
- Знание подводных камней системы
- Опыт работы с платформой

Чтобы мне получить хоть сколько-нибудь пригодный код от ИИ мне нужно:
- Уточнить продуктовые требования и пройтись по существующей документации
- Описать ему платформу
- Впихнуть как-то codestyle
- Передать задачу
- Описать дополнительные требования
- Разобраться как это всё работает
- Отревьюить код ИИ и пнуть его на исправления
- Исправить оставшиеся проблемы

Чтобы решить задачу самостоятельно:
- Уточнить продуктовые требования и пройтись по существующей документации
- Написать код и возможно тесты... ииии всё?

Единственная категория задач где это всё как-то работает - это конвертация чего-то, во что-то, и то только если вы можете автоматически провалидировать результат (потому что ИИ может посреди задачи вставить "// and so on"). Причём этот тип задач зачастую автоматизируется без ИИ макросами.


И знаете, при основной задаче ускорять работу ИИ парадоксально делает её медленнее. И работы по факту больше. У меня складывается впечатление, что эти лыжи таки не едут.

При работе в команде, особенно неоднородной по скиллам разработчиков большинство пунктов так же имеются. Ну и "разок что-то в проект довайбкодить" и постоянная разработка с ИИ это несколько разные процессы. В первом случае, есть существенный шанс, что никакого выигрыша по скорости вы не получите, а во втором требуется время на настройку и некоторые изменения подходов, которое окупится не прям вот сразу.

Но самое главное, пожалуй, даже не ускорение разработки, а повышение качества, потому что код после ИИ обязательно надо ревьювить и часто рефакторить, а при ручной разработке нередки случаи, что вот фичу написал, время почти вышло, рефакторить будем как-нибудь потом. Ну и по нагрузке на мозг, многие вещи при разработке с ИИ в голове не обязательно держать.

потому что код после ИИ обязательно надо ревьювить и часто рефакторить,

Ну проревьюить собственный код в момент создания мерж-реквеста - это само собой разумеющееся.

> а повышение качества

Не смешите мои тапочки. Я лично могу написать какую-то фигню от невнимательности, ИИ напишет её гарантированно от полного отсутствия такого концепта как "понять задачу".
А если рефакторинг в команде не случается, возможно что-то с этим нужно делать, это ненормально.

С приходом ИИ мир меняется, и с ним меняется и набор основных навыков.

Я например, считаю, что если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу.

Либо забыли в промпте или в правилах написать "перед исполнением задай мне вопросы".

С приходом ИИ

С приходом LLM, который хорошо продается (пока) под лейблом ИИ, изменилось только то, что можно генерить невероятное количество неопределенного качества текста за пол минуты.

если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу

Мантра промоутеров. Ага, галлюцинации тоже из-за меня, не умею работать в команде.

если у вас ИИ плохо пишет - значит вы дали мало контекста и плохо поставили задачу.

Правильно и детально расписать контекст и поставить задачу - это 90% работы программиста, а код писать это дай бог 10%. С таким же успехом можно посадть джуна и хэндхолдить его 90% времени — можно, но зачем? Где тогда экономия на использвании ИИ? И если квалифицированные разработчики многое могут понять тупо из своего опыта и обрывчатых данных, включив режим бабы-ванги, то ИИ здесь в пролёте.

Тестирование уже ИИ отдали, скоро и чтение отдадим...

чтение чужого почти всегда сложнее, чем написание собственного

именно поэтому ничего с тем ИИ ты не выигрываешь, если не будешь нормально разбираться с тем, что он тебе выдает

Совсем нет. Во-первых, всё равно нужно понимать, как код должен работать. Даже банально для того, чтобы составить ТЗ для ИИ. Во-вторых, например, лично мне в программировании всегда не нравилось «кодить» - то есть, буквально, монотонно набирать код руками. Сейчас же можно просто напечатать, что надо сделать, просмотреть результат, сказать, что поправить - и все это, вообще не вводя самому ни одной строчки.

Качается и опыт управления, и опыт ревью, ещё и время экономится.

Я наоборот, за 2 месяца изучил технологий больше, чем за 7 лет работы. Просто читая рассуждения модели во вреия выполнения задач.

Ага. Кто-то жалуется, что разработчики тупеют из-за использования ИИ, а для кого-то наоборот по-максимуму использует новые возможности. Все как всегда

Многие высокоуровневые языки переписывают ваш код на ассемблер. Вполне хорошие разработчики даже не знают как на нём писать. Так же и с ИИ-кодингом: это просто переход на новый уровень абстракции.

Выглядит скорее как регресс: вместо формализованного языка программирования — естественный (а значит, полный неоднозначностей) язык промптов. А каждая "перекомпиляция" может выдать разный результат. Нечто противоположное тому, к чему шло развитие программирования цифровых вычислительных машин.

Пишу на не самом популярном стеке ( мобилка), как в продакшн, так и хобби проекты.

И могу сказать что поменять кнопочку или отыскать где связываются две сущности, сделать нечто подобное к тому что уже было реализовано - ИИ даёт значительное ускорение.

Но сделать что-то с нуля масштабируемое или даже на существующем проекте добавить фичу ( именно полноценный экранчик или функциональность) - около нереально.

При этом использовал все что есть на рынке - ии-редакторы кода, чат боты ( с подпиской и без), агентов в терминале - везде проблема:

А) с контекстным окном ( слишком мало умещается, приходится думать как обрезать данные, оставляя нужные)

Б) с уровнем "интеллекта"(если так можно выразиться) модели. Пока что лучше всего показывает Claude (как и последние пару лет)

Если нужно написать что-то популярное (сайтик или небольшой бекенд на питоне) - "ВАУ, будущее наступило", но как требуется сделать что-то сложнее или на менее популярном стеке - ощущение что ты пытаешься перекинуть работу на джуна-дебила который не умеет осознавать свои ошибки.

Причем ситуация комичная уже пару лет - улучшения есть, но по чуть чуть, не спасает супер описанное тз ( потому что иногда требуется к примеру написать какие-то изменения в файлах отвечающих за сборку проекта, а не просто код городить )

но как требуется сделать что-то сложнее или на менее популярном стеке 

Изучайте MCP, и прочие методы подключения документации.

Для непопулярных стеков подключали Context7?

Проблема контекстного окна, внезапно, решается обычной декомпозицией задачи. А получившиеся еще можно дальше декомпозировать на микрозадачи. А непонимание нейронкой проекта решается дополнительно документацией в markdown с детализацией связей и потоков. А все эти "редкие стеки" решаются через mcp context7.

На определенном уровне декомпозиции становится самому проще написать

Декомпозиция задачи это само собой разумеется - уже на этапе планирования спринтов все задачки разбиваются достаточно удобно, но проблемы возникают когда нужно понять не "что" делать, а "как" делать. Ближе всего к хорошему результату подходят агенты (например google CLI), которые могут пошарится по проекту и найти нужные примеры кода, но с ними беда возникает на этапе тестирования - оказывается что код который они написали не работает как нужно :(

И вот агент уже всеми известными способами пытается заставить работать свой код, но в большинстве случаев у него заканчивается контекст ( окно не бесконечно и нельзя в него впихивать сколь угодно).

Я отлично понимаю восторженные отзывы тех кто смог на конкретном стеке решить конкретную задачу - но мой опыт и опыт моих коллег позволяет судить о том что не во всех сферах LLM могут делать задачи достойные работы разработчика грейдом мидл и выше.

Конкретно в мобилке я думаю за один запрос ллм или агент смогут сделать приложение с заучиванием карточек или игрушку 2048, но если там требуется более серьезная навигация / использования локального хранилища / взаимодействие с сетью (не просто получение одного Jason, а логин пользователя) - фенита ля комедия.

Если я знаю как точно сделать работу, описываю как ее сделать достаточно подробно - почему бы мне самому не сделать эту работу ?)

Экономия возникает на мелких задачах когда на промт тратишь минуту-три, а потом слегка шлифуешь решение.

Когда же промт нужно составлять час и потом несколько часов исправлять решение ( и не факт что исправишь) - выгоднее делать самому ( с точки зрения экономии времени в долгосрочной перспективе)

Для мелких скриптовых задач работает замечательно, имхо! Например, автоматизация процесса релиза с ии выполняется мидлом за пару вечеров. Или задача заскриптовать какое-нибудь апи через curl или на питоне занимает тоже пару вечеров. Если писать такое в ручную с нуля, то уйдет день и сколько-то на отладку, при условии что не отвлекают. А уж в обычном режиме с чатами, инцидентами и прочими радостями нужна неделя.

А мне нравится использовать ИИ в кодинге. Просто потому что это прикольно. Других причин назвать не смогу. На скорость работы, как по мне, влияет очень мало. Где-то ускоряет, где-то замедляет. Но чем больше я использую ИИ, тем больше нахожу ограничений и слабых мест.

Очередной копиум. Когда нибудь вам прийдется принять, что в ваших головах точно такая же нейронка из синопсов и нейронов. И нейро кодинг работает прекрасно уже сейчас, аргументы "ну он же не на 100 процентов выполняет таску, а на 90" - копиум чистой воды

Спасибо, посмеялся. Советую копнуть поглубже и разобраться, что на самом деле представляет из себя ИИ, если ваш мозг работает схожим образом, могу только посочувствовать))

Он у всех так работает, вы ровно так же подбираете букву за буквой основываясь на опыте, просто не замечаете

ну правда он еще может что то изобрести, открыть, изучить, вывести, может в творческий процесс, а не только подбирать букву за буквой или подставлять пиксель за пикселем на основе залитого в него объема размеченных данных.

Когда-то в ШАД'е за сравнение только одной модели синтетического нейрона с настоящим больно били, чего уж там про различия в макроструктуре говорить

Я тоже учился в ШАДе и супер уважаю ребят оттуда, но все же важно понять, что большинство людей по природе консерваторы (и это круто, иначе бы энтузиасты разнесли все к чертям). Так то раньше и за мысли про круглую землю сжигали на кострах.

Хоть искусственные нейроны в сетках и отличаются от естественных, у них и общего тоже достаточно много. Как пример, если изучить зрительные нейроны в наших глазах, то идея CNN начинает казаться очень интуитивной

Так то раньше и за мысли про круглую землю сжигали на кострах.

Вроде как за мысли про множественность миров спалили, за мысли про круглую землю под домашний арест только. Да и сейчас в некоторых религиях можно заработать наказаний за пропаганду, что миров и, соответственно богов, бесконечно много.

Текущий ИИ хорого тесты пишет, с код ревью может помочь (лишним не будет), но надо за ним проверять, я игнорю 30-50% его предложений

Существующий проект - не, тяжело будет всем.

А вот если начать новый - то мне понравилось. Я сейчас тренируюсь - реальный проект, но с DDD и ИИ.

Но надо самому знать, что хочешь, держать в голове структуру. Зато удается держать сложность на неком минимальном уровне. Автоматически как бы код разбивается на меньшие куски с меньшим контекстом, потому что ИИ начинает нести чушь. А человеческому мозгу потом проще это понимать. Так как по сути у нас в голове тоже контекст.

Пишите нормальные комментарии к коммитам, связывайте их с таск-трекером и тогда ИИ сможет понимать, что почем и откуда ноги растут.

Моя мечта, скормить чатику исходники ядра и дерева устройства и сказать - обнови до актуального ведра, а соберу я уж как нибудь сам. Увы, мечта пока неподъемная.

https://habr.com/ru/companies/ruvds/articles/945512/ - Модернизация древнего драйвера Linux с помощью Claude Code

Хотя конечно, это не одна кнопка "сделай мне хорошо".

Это я читал. С ведром так просто, к сожалению, не будет, там взаимосвязанные вендорские патчи, которые могут кирпичить даже при минорной обнове ядра.

>Модернизация древнего драйвера

буллщит полный. GPT вообще с си плохо справляются, там тулзы упоротые, куча ключей. gpt5 нормально не может исходники 7zip проанализировать и родить "самый простейший прототип консольного приложения под linux". мешает в кучу винду и старьё, прошёл через десятки итераций, 85% даже не компеляется, 15% не пашет.

А мне в ядре числа с фиксированной точкой на флоаты предлагал заменить. Аргумент, что fpu в ядре не используется его не убедил.

Не понимаю, почему автор пишет про замедление разработки на 20%?

я к примеру в 95% случаев либо задаю примитивные вопросы, которые с тем же успехом можно прогуглить, либо решить самостоятельно, но уже устал и влом, либо пихаю трейсбек ошибки и прошу разьяснить в чем дело (что тоже как бы легко решается самостоятельно, но чуть подольше).

это дает ускорение в работе.

если автор просто втупую просит нейронку закодить решение, копипастит, а потом все перелопачивает - тогда тут пожалуй соглашусь и предложу пойти подучиться, что ли

Возможно, вторая часть поста даст ответ

В руках умелого разработчика ИИ - ускоряет. В руках не умелого - замедляет.

Умелость вообще тут ни при чем, как по мне. И неумелым новичкам может здорово помочь, и умелые и опытные кодеры могут ругаться, что толку мало. Как уже кто-то выше писал, здесь про способность провести декомпозицию на простые задачи так, чтобы эти задачи можно было потом дать жпт. Похоже на то, что эту способность нельзя пприобрести, с ней можно только родиться. Поэтому здесь в комментах по сути только два полярных мнения насчет пользы жпт в программировании.

В компании, где я работаю, мы сначала активно применяли Copilot и прочий ИИ, но постепенно выяснилось, что это ускорения разработки не дает - ИИ пишет даже простой код с ошибками, его все равно надо перепроверять и корректировать. Тесты ИИ пишет нормально только самые простые, тесты средней сложности уже пишет некорректно. Сложного контекста ИИ по большому счету не понимает.

Да - простой код ИИ пишет нормально, но нам это не особо нужно, т.к. простого кода у нас в проектах не много.

Поэтому большинство Сеньоров ИИ для работы используют либо минимально, либо не используют вообще.

И применение ИИ и Вайб-кодинга для джунов пришлось серьезно ограничить, а то они не растут в профессиональном плане и потом не могут поддерживать проект, который они сами и "написали" - они просто не понимают, как и что в нем работает(((

Посмотрите на CodeAlive.ai, мы как раз проблему сложного контекста решаем.

Программирую больше 20 лет.

Скажу так. Если наплевать на этот хайп с высокой горы, то на самом деле языковые модели очень занятная штука. Однако, гораздо более сложная в использовании, чем это кажется на первый взгляд. Скажем, если разработчик уже знает:

  1. Большинство распространенных методологий программирования

  2. Стили программирования

  3. Все возможные способы реализации алгоритма в рамках выбранного ЯП

  4. Возможности большинства используемых в задаче сторонних модулей и библиотек

  5. Распространенность и глубину публикаций в открытом пространстве тех или иных подходов и библиотек

  6. Глубокую специфику бизнес процессов по эксплуатации продукта в конечной среде

  7. Специфику упаковки, тестирования и доставки решения в эту среду

Тогда да. Можно очень тонко и изящно направить ИИ, и получить годный фрагмент кода, который, конечно, придётся внимательно прочитать и поправить, а затем использовать в своё удовольствие. Но это, если вы уже умны...

Боюсь что в гонке за счастьем для джуна и мидла, это может действительно обернуться головной болью. В лучшем случае, будете ходить по кругу и научитесь, как делать не нужно.

Есть и плюс: человечество в безопасности 😊

По мне, так наоборот, если ты всё это уже знаешь, то быстрее самому написать. ИИ больше полезен как раз там, где у тебя опыта или знаний не хватает. Если нужно для решения задачи гуглить или читать доки, то агент может справиться быстрее. Правда хуже, но иногда или этого достаточно (скрипт на выброс, например), или можно быстро допилить.

Вот пример скрипта, который мне понадобился однажды. Микросервис с логированием, мониторингом, защитой от ДОСа, упаковкой в докер и даже дашбордом. Суммарно более 300 полезных строк за час общения. Это пример из разряда "я всё и так знаю, зачем самому писать?" :)
https://chatgpt.com/share/68ef4c12-aa98-8003-9c3b-d447d1ebbf5c

Скрипты с нуля и желательно на выброс - это сильная сторона ИИ

Для меня большое ускорение — это когда IDE за меня 99 строчек кода вставляет, которые мне пришлось бы прописывать, теряя контекст. Я пользуюсь ИИ как младшим тупеньким помощником, и это очень ускоряет меня. Могу сбросить на него много мелких тупеньких задач.

Если эти 99 строчек настолько просты, то можно их обобщить и их проекта вообще убрать. Разве что у вас не принято так, как например, в го - принято копипасту писать ))

ИИ это просто новый инструмент в арсенале в том числе и разработчика. Кто умеет пользоваться - тому плюс, ну а если тупо копипастить код из гпт или ждать решений от агентов, то получается то что описано в статье...

Абсолютно согласен! Чтобы использовать инструмент по назначению, нужно сначала хотя бы разобраться: а в чем его назначение?.. а потом потратить время на обучение. А большинство товарищей, не мудрствуя лукаво, берут перфоратор, забивают им гвозди и жалуются, что как-то хуже выходит, чем молотком...

Из того что вижу сейчас повсеместно - пишем абы какой промпт и комментируем - она и так разберется, получаем хрен пойми какой код, не разбираясь запускаем, без ошибок - комитим. Хороших разработчиков днем с огнем не сыщешь, что джунов, что опытных и очень интересно получается, что ИИ обнажил их, то кто говорит, что ИИ не работает - плохой разработчик по факту и без ИИ. У меня ИИ кодит прекрасно, даже в больших и сложных проектах на С, нужно просто воспринимать его как один из инструментов и давать четкие декомпощированные задачи, даже в рамках одной фичи. Время экономится существенное, скорость разработки увеличивается в 2,3 раза, то есть где я буду сидеть пару месяцев - я сижу неделю, это с документацией, с четкой архитектурой и тестами.

Пока декомпозируешь уже сам напишешь быстрее. Да и с декомпозицией всё равно косячит временами, приходится очень внимательно код ревьюить. Но субъективно, может, казаться что ускоряет.

Есть, конечно, специфика проекта и стека. Где-то работает лучше.

Ещё может весь выигрыш из-за борьбы с прокрастинацией. Так бы полдня тупил потом сделал за пару часов, а потом дальше тупил. А так за полдня с агентом плодотворно работал. В зависимости от того, как на это смотреть можно сказать стал и в два раза быстрее, и два раза медленнее.

Хороших разработчиков днем с огнем не сыщешь

огласите стек, на котором вы не можете разработчиков "днём с огнём" не найти

...И зарплату.

Пользую Yandex Code Assistant, работает, и очень неплохо. С хорошим промптом с инфой о том, что сделать, где что искать и откуда что взять, генерит код хорошо. Для хоббийных проектов хватает за глаза chatgpt.

Если воспринимать ИИ не как штуку, которая за вас все сделает, а как ide следующего поколения, которая помогает писать код, то изменится восприятие к нему и способы работы с ним. Тогда ИИ станет ускорять разработку в целом.

Я проводил тест на команде, у нас ускорение минимум 30%, да мы не пишим супер сложный код, большую часть времени. Сложные места дописывают разработчики сами, но обычно, разработчики много времени занимаются вытаскиванием данных из БД - > конвертаций их в другой формат и вывод, а тут как раз и получается ускорение.

В прошлом месяце видел, как нейросетка ускорила один проект, сгенерировав код работы с БД содержащий взаимоблокировку. Проблема как раз в том, что нагаллюцинировать она может в коде любой сложности, а трудозатраты на выявление всех этих мин соизмеримы с написанием кода без нейронки. Так что на 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

В результате технологии или мертвы или используются в узкой нише.

  • XML живее всех живых, те-же офисовские документы, например да и вообще много различных форматов файлов используют XML. Для Веба да, уже редко где используется.

  • NoSQL живее всех живых: спектр задач хранения данных не ограничен реляционными данными.

  • Микросервисы мертвы???

  • В каком выдуманном мире кубер мертв?

  • Про блокчейн ничего не знаю, поэтому не скажу.

  • NFT это же какой-то скам? причем здесь технологии?

  • GraphQL, да вроде тоже жив, статистики не знаю, но знаю полно мест где люди используют и довольны. У нас тоже работает.

  • Что под бигдатой вы имеете ввиду? Объемы данных растут, растут и инструменты работы с такими объемами. Что именно у вас умерло?

  • Semantic Web вот это не знаю что за зверь и гуглить лень.

XML живее всех живых

  1. Офис в 2007 перешел на XML, JSON тогда только набирал популярность.

  2. Сколько новых проектов сознательно выбирают XML вместо JSON/YAML/что-то другое?

NoSQL живее всех живых: спектр задач хранения данных не ограничен реляционными данными.

Его продавали как замену SQL - "смотрите, это быстрее SQL и с динамической схемой данных". Поддавшиеся на хайп и перешедшие на NoSQL, потом с болью осознавали, что в реляционных базах данных, "реляционные" это не просто красивое слово.

Микросервисы мертвы???

В каком выдуманном мире кубер мертв?

написал же

для очень крупных компаний имеет смысл, но для большинства это избыточное увеличение сложности

Что под бигдатой вы имеете ввиду? Объемы данных растут, растут и инструменты работы с такими объемами. Что именно у вас умерло?

У подавляющего большинства нет бигдаты. Подробнее

А какой формат сейчас модно использовать для форматирования документов?

Зависит от цели.

Чтобы читался везде - pdf.

Чтобы редактировать везде - markdown.

Для документации rst.

В науке LaTeX.

Для веба HTML.

Для книг epub.

Для бытовых целей и неспециалистов docx, odt.

Отдельно Google Docs, Notion, и прочие облачные сервисы - для пользователя документ есть, а какой там внутри формат...

Порой мне кажется, что вокруг одни чат-боты с контекстным окном в одно сообщение..

У человеков в среднем так. Иначе они болеют, страдают, выгорают, да и вообще жизнью не живут.

Вот потому с LLM и бесятся.

В целом, @Politura уже все расписал – большая часть перечисленных инструментов вполне заняли свои серьезные ниши.

А даже если бы не заняли – то странно приводить их как аргументы против ошибки выжившего – всегда можно найти штуку, которая не оправдала ожиданий – это такая же ошибка выжившего.

Кстати, полезный практический лайфхак:

LLMки лучше работают с XML разметкой на вход, чем с JSON, особенно, когда большой комплект данных.

Или как объяснить менеджменту, почему лучше перестать пушить внедрение ИИ в разработку.

Начни в почте и чатах им отвечать с помощью ИИ. Так они быстрее поймут всю абсурдность использования ИИ в разработке.

у меня вопрос к тем кто реально использует ИИ в работе. как оно работает на больших проектах с большим количеством давно написанного кода?

проекту на котором я работаю 20+ лет, количество файлов - десятки тысяч, некоторые по несколько тысяч строк кода.

если дать задачу LLM отрефачить какой-то базовый интерфейс или еще проще - переименовать имя функции, это потребует аплоада всего кода на сервер LLM?

Технически - да. Для работы семантического поиска - проект нужно проиндексировать. Для индексации все файлы рабиваются на короткие чанки, для каждого чанка запрашиваются embedding-и. Но это делается по чанкам и чанки на серверах не хранятся (по крайней мере так заявляют разработчики). Поиск по полученным embedding-ам происходит локально, и затем всё относящееся к текущей задаче посылается на сервер уже как контекст для диалога с LLM.

не сказать что я что-то понял из этого...

Поиск по полученным embedding-ам происходит локально

хотите сказать какой-то код LLM выполняется локально на компе? для простого текстового поиска возможно это сработает. но что если задача стоит так, найти все места в коде где можно применить новую функцию и отрефачить код чтобы ее применить?

Это называется семантический поиск. LLM по фрагментам текста / кода генерирует числовые векторы. Ближайшие по смыслу фрагменты получают ближайшие векторы. Условно "где происходит движение персонажа" и "if key == "right": person.x += 10" получат достаточно близкие векторы, например (0.1, 0.4, 0.3) и (0.13, 0.39, 0.31).

Генерация векторов делается удаленно, дергается API которое по тексту возвращает embdding-и. Поиск делается локально, но это не LLM код - это обычный поиск ближайшего вектора в векторной БД которая запущена локально.

Вот в рамках эксперимента "создать проект даже не разу не посмотрев в код" пилю прямо сейчас. aihubnews.ru через помощник хиппи кодер, голосовым управлением через приложение в телефоне. На продакшене стоит gemini cli, занимается администрированием сервера и деплоем, дома на компе клод код cli. Там уже 70+ тыс строк, под капотом - конвейер с множеством этапов по автоматическому созданию статей (поиск источников, парсинг, сортировка по теме, рерайт, присваивание категории и тегов, контроль качества, seo оптимизация, верстка, все выполняется с помощью ии без моего участия), проект наполняет сам себя. В работе сейчас система аналитики, личные кабинеты на сайте и в тг боте и рекомендательная система. Как допилю MVP и пойдёт первый трафик - залезу в код и начну кусками переписывать.

Вся работа идёт так. Я голосом общаюсь с нейронкой в режиме диалога, обсуждаем реализацию, нейронка создаёт файлы документации и план разработки. Далее я просто прошу его взять в работу документацию и там уже все задачи описаны. После того как основной агент заканчивает писать код, подключается субагент для код ревью, еще один субагент для тестирования и третий субагент для написания документации. И так блоками за 2 недели создал это чудовище, там уже есть супер дашборд, куча логики, но это только для меня, админа, чтобы я следил за этапами обработки и мог наглядно наблюдать что стоит улучшить.

Пишите пост! Это же прям супер уникальный опыт

Я бы написал такой сервис за 3к строк. И без таких вот косяков:

Минута загрузки облака из 20 тела и списка из 50 статей.
Минута загрузки облака из 20 тела и списка из 50 статей.
иногда вылезает черно-черное меню.
иногда вылезает черно-черное меню.
Верстка в целом никуда не годится.
Верстка в целом никуда не годится.

Фронт прямо сейчас дописыввется ежедневно семимильными шагами. Главная цель была выгрузить это на домен, для ускорения старта индексации. (Ссылка и ваши скрины уже в индексе гугла, например, так что продвижение обещает быть быстрым) Каждый день много чего исправляется и добавляется новый функционал, так что можете заглянуть буквально через недельку, и увидеть много улучшений и исправлений старых проблем. Те что вы описали, уже пару дней назад исправлены, на днях вышружу на прод, но, в любом случае, спасибо что заглянули! В 3к строк у меня только документация по работе системы аналитики, так что не торопитесь с выводами :)

Эффективные паттерны использования code агентов - самая горячая тема сегодня. Будут ли на конфе эти паттерны?

решения о применении ИИ принимаются на основе хайпа в твиттере/телеграме или субъективных ощущений менеджмента

Так это всегда было. До ИИ увлекались ноу/лоу код платформами, скрамом, микросервисами, бигдатой, созданием соц. сетей, блокчейном, парным программированием и т.п.

Что не означает, что стоит это принимать 🤷‍♂️

Прогаю с использованием Курсора уже где-то пол года, что могу сказать.

ИИ это инструмент, которым надо уметь пользоваться.
Используя его в нужных местах можно радикально ускорить производительность, а в ненужных - всё застопорить. А ещё - ему надо обучаться и надо дофига практики, чтобы понимать где лучше завайбкодить, а где будешь дольше разгребать.

Почему-то в сети очень сильно расхайпили тему, что в вайбкодигом можно вкатиться без знаний. Мол главное промпт написать - а ИИ тебе всё сделает. Это фундоментальное заблуждение, наоборот, вайбкодер должен хорошо уметь писать, и что важнее - читать код (с полным пониманием написанного), и помимо этого - ещё и уметь пользоваться всеми инструментами ии-агентов и иметь опыт их использования.
Никакой "гуманитарий" пока не напишет что-то минимально сложное и рабочее используя ИИ, а вот сеньор с хорошим пониманием того, что хочет и примерным пониманием как - действительно в одиночку теперь сможет клепать средней сложности проекты, что раньше было невозможно.

Зато я нашел прям прям сильную слабость ИИ-шки :), пишу приложения на AvaloniaUI, которая наследник WFP, относительно молодая и которая на 70% копирует синтаксис WPF, но сильно отличается в мелочах. Так вот - ИИ вообще пока не может адекватно писать на авалонии, так как всё время смешивает WPF и авалонию делая нерабочий код и по 100 раз его исправляя регулярно уходя в повторение.

Хотя бы посмотри сначала на spec-kit, а так обычный кандидат на увольнение. У нас так принято, все лучшее, а главное ничего не менять, только рынку на это на ать.

Зато я нашел прям прям сильную слабость ИИ-шки :), пишу приложения на AvaloniaUI

Подключите к нему context7 MCP сервер и в промпте пропишите чтоб сверялся с документацией прежде чем начинать кодить. В context7 есть документация по Avalonia.

Спасибо попробую через context7, может получше будет, я обычно стандартным инструментарием курсора документацию подгружал.

Неа. Не помогло :). В авалонии нет свойств Selected\DisplayValuePath, там другой подход и есть свойства Selected\DisplayValueBilding, зато они есть в WPF. Всё таки пока ИИ плохо работает с ситуациями, когда языки/фреймворки очень похожи, но отличаются в мелочах
Можно попробовать разные модельки потыкать, это sonnet 4.5

ps. gpt5 справился лучше, при том без context7, почему то не смог через неё сделать запрос...

А бухгалтера можно на ИИ заменить?

Даже генерального можно. Если не интересует результат

Пока нет. Есть исследование, которое показывает, что количество ошибок в задачах бухгатерии систематически накапливается

https://accounting.penrose.com/

При этом, оно все равно очень маленькое, а это значит, что с human-in-the-loop, который валидирует результаты, оно может работать уже сейчас

«Attention Is All You Need» - статья гугл, которая лежит в основе современных трансформеров, была направлена на автоматизацию переводов с разных языков. Математически - это статистика в векторном многомерном пространстве.То есть весь движ, который мы щас наблюдаем, был вызван инженерным решением в совершенно в другой тематике. Это как побочный эффект у Виагры, коммерчески сильно превзошедший целевой эффект.
Границы этого эффекта( я про трансформеры ) - мы уже близко, каждая следующая модель все меньше впечатляет, причем количество на развитие затраченных ресурсов растет кратно. Мы достигаем предела, когда генерируемые переводы технического задания с английского на русский или иной, будут совершенны с точки зрения статистики, но не результативны при переводе на Python.
Итого, технология работает и, вполне себе, реализует вещи, которые 5 лет назад были немыслимы. Технология имеет ограничения. Нужно найти компромисс и жить с этим.

Использую нейронку для перевода доки и комментов, так они и перевести с одного раза не могут, иногда нужно раз пять мордой ткнуть в куски, которые она "забыла" перевести, и которые находятся только вдумчивой вычиткой.

Скорее всего у вас просто плохой пайплайн перевода выстроен. Я делал цикл переводов AI-2027, текст целиком написан LLM без редактуры

Оно все меньше впечатляет на большей части банальных задач. Но это нормально – они и так уже решаются достаточно хорошо. Весь прогресс – на узком хвосте распределения сложных задач, требующих серьезного ризонинга и надежности. Если вас не впечаляют возможности gpt-5 и sonnet-4.5, то мб у вас просто мало таких задач

Критика ИИ хорошо описывается старым бородатым анекдотом.

Скрытый текст

Купили как-то суровым сибирским лесорубам японскую бензопилу. Собрались в кружок лесорубы, решили ее испытать. Завели ее, подсунули ей деревце.

«Вжик» — сказала японская пила.«У, бля...» — сказали лесорубы.

Подсунули ей деревце потолще. «Вж-ж-жик!» — сказала пила.

«Ух, бля!» — сказали лесорубы.Подсунули ей толстенный кедр.

«ВЖ-Ж-Ж-Ж-Ж-Ж-Ж-ЖИК!!!» — сказала пила.«Ух ты, бля!!» — сказали лесорубы.

Подсунули ей железный лом. «КРЯК!» — сказала пила.

«Ага, бля!!!» — укоризненно сказали суровые сибирские лесорубы!

И ушли рубить лес топорами…

Так вот, все эти критикаторы подсовывают ИИ всякое по нарастающей до тех по пока не..., а потом с радостным «Ага, бля!!!» ширят в массы свой опыт работы за 2023-й год.

Проблема в том, что "уровень разработчика" определяется не медианной сложностью задачи которую он выполняет в каждый момент времени, а самыми сложными кусками работы - которые могут вылезти в процессе выполнения почти любой задачи.

Это, к стати очень глубоко сидит во всём процессе разработки о довольно сильно связано с особенностями человеческого интеллекта - ну например если джун начинает закапываться, в процессе решения задачи лучшее что он может сделать - своевременно обратится за помощью.

И вот нам завезли "джун*" (не + или минус, а именно ) - под ход мыслей и интеллект которого весь процесс разработки не подстроен.
Поэтому одни концентрируются на том, что "джун*" даже до джуна не дотягивает по ряду задач. Другие - на том, что он и миддла (да и любого человека по скорости печатания какого-нибудь заведомо понятного кода) по другим метрикам перебивает.

Проблема в том, что для полноценного внедрения ИИ как минимум весь процесс разработки должен быть перестроен под именно его сильные / слабые стороны.

Сначала , я думал, что ИИ кодит как джун(и заменит их), но это оптимистично оказалось, я с помощью ИИ транслировал код из одного языка в другой, и как оказалось, больше 50% ошибок может и джун даже исправить. Следовательно есть смысл давать задание не непосредственно ИИ, а джуну , который даст задание ИИ и исправит его ошибки.

Меня если честно удивляет убежденность людей в том, что нужно научиться и тогда работает. Я вчера делал очередной рант и это был рант не на тему того, как нейросетка с аркестрацией и прочей ерундой забывает, что сделала 10 файлов, в рамках одной задачи.

Это был рант на тему того, что нейросетки делают все гораздо хуже. С приходом нейросетей я привык читать код гораздо быстрее, чем когда-либо, научился принимать плохой код или дизайн, сдаваться, прежде, чем на улучшение уйдут часы.

Но боги, стиснув зубы, я принимаю, что 900 строк за 2 минуты мне не написать.
Вот только я бы я написал 200. А код у меня перед глазами невозможно поддерживать, невозможно читать, невозможно переиспользовать. И это меня не огорчало бы, если бы это была проблема меня через 2 года.

Но ИИ и правда делает процесс разработки быстрее. К этому бесполезному файлу мне придется вернуться уже через пару дней.

Я кодер-одиночка(геймдев), был сеньором. ИИ дает неплохой буст в производительности. Да, архитектуру придется писать самому, но вот отдельные части можно задавать нейросети. Например, я сказал ИИ сделать FPS уровень в духе Doom(у меня 2D-движок). Он взял и сделал! Правда пришлось немного корректировать результат. Но чтобы мне самому это сделать, мне пришлось бы лезть в дебри технологии рейкастинга и высшей математики. А тут бац - и готово. Еще очень помогают автокомплиты целых функций. Пишешь название метода и он в 80% случаев предлагает код, который я хотел написать.

ИИ кодинг будет мертвым до тех пор пока на одинаковую задачу не перестанет писать разный код, да даже в рамках одного контекста ИИ переписывает один и тот же код по разному.

"разработчики не нужны, пока на одну и ту же задачу не перестанут писать разный код"

Видится как повод применить абстракцию (макрос, функция, объект, фреймворк), а не "писать разный код".

"разработчики не нужны, пока на одну и ту же задачу не перестанут писать разный код"

Очень смешно. В Гугле 50% кода пишет ИИ. И тут на сцену выходит икспэрд, который щас нам всё объяснит :-)))

В Гугле 50% кода пишет ИИ.

Это так говорит гугль. Сколько реально - не знает никто. Им надо нарисовать цифирь чтобы оправдать вкинутые в пузырь деньги.

В теории можно и поверить, но ключевой вопрос сколько времени разработчики тратят чтобы дописать/изменить оставшиеся 50%, и есть соменения что это время уменьшилось существенно.

I mean, достигнуть этих значений элементарно.
Банально, включить LLM как автоматический пулл реквестер и можно помечать все файлы, которые были изменены им, как ИИ-файлы.

Конечно, икспэрду из ниоткуда мы верим гораздо больше, чем какому-то гугелю! У икспэрда-то инсайды ого-го! А эти смешные клоуны нас надурить хотели! :-)))

"- А мой сосед говорит что у него 30см..."
"- Так и вы говорите!"

Ставить в пример Google в 2025 году как что-то хорошее это прямо мда.

Свой опыт. Стаж-25 лет, в основном machine vision и все с этим связанное, но и в распределенные системы тоже иногда приходится играть. Сам пишу на и люблю(именно люблю) с++, но также неплохо знаю шарп и в последнее время разобрался с пайтоном.

Никогда не занимался ии кодингом, ну не нравится, но дали безголового стажера в команду и в процессе отучения последнего от Qwen решил сам погрузиться в тему, да и начальство постоянно ноет что мол не идем по самому cutting edge технологий. Итак, опыт.

  1. Приложение на pyqt для аннотации специфичных данных. Написано qwen, в несколько итераций, потом немного подпилено напильником. Неоптимальненько, но главное работает. Ушло со всеми заморочками где то 2 часа. Ручками наверное денек точно заняло. С точки зрения профита-однозначный плюс, уложились в спринт, +1.

  2. Немного подзабодвшись в чтении доки решил смастерить сэмпл, скормил задачу ии. Результат-сразу видны ошибки. Указал ей, не помогло. Одни баги фиксит, усиленно добавляя другие. В результате задачу решил, но профита по времени почти не было. +-.

  3. Небольшой вопрос по математике, скорее даже не для решения, а для понимания, можно ли использовать в качестве справочника, чтобы уменьшить время на поиск инфы. Результат-грубая ошибка в самом начале и полная потеря доверия. Однозначный минус.

  4. Давно хотел позаниматься с одной библой, ну чтож, свободный вечер, чашка кофе, поехали, смастерим сэмпл. Работаем как с хорошим джуном, ставим задачу, все обговариваю. Спрашиваю давайй попробуем эту задачу решить с помощью libxyz. Язык-плюсы. О, я знаю эту библу, тарампампам, шеф щас все будет. Результата нет, куча нагенеренного, на вид нормального, но по факту плохого кода. Неработоспособно, пытаясь починить и выяснить в чем проблема добился что сетка сама стала себе противоречить. Хорошо, я это вижу, а джун увидит? - сильно вряд ли. Однозначный минус, потерянное время.

    Итого, в моем случае 1.5 из 4. Не выше тройки. Да, определенные задачи ускоряет сильно, но это шаблонные задачи, и по большому счету, разумным копипастингом и руками могущие быть решены примерно за то же время с сохранением контроля над процессом.

 в процессе отучения последнего от Qwen решил сам погрузиться в тему, ... Итого, в моем случае 1.5 из 4. Не выше тройки. 

Платный ChatGPT не пробовали?

мне кажется, все дело в ограничениях контекста. сужу по своему опыту - средненький проект уже 30 000 строк кода. это 1,5 млн слов или 4,5 млн. токенов

когда размер контекста станет 5 млн токенов, тогда ИИ с легкостью проведет идеальный рефакторинг всего проекта за раз. пока же - приходится "все сама, все сама".

ну а серьезные проекты - это миллионы строчек и 150 млн токенов. вопрос даже не близкого будущего

Как минимум два спикера конфы решают эту проблему в своих тулах. Вам может быть интересно

Использую Junie (Claude). Проекты в среднем до 6.000 файлов.
ИИ-агент удовлетворительно работает при наличии архитектуры. 1-2 промпта, допиливание диффа, коммит.
Если делать что-то с нуля - пишет мусорный код, который сложно расширять.
Ещё один вид удачного применения - неизвестная кодовая база. Вкидываем реальную задачу в промпт и читаем получившийся дифф. Тем самым за 3-5 минут получаем первое понимание взаимосвязей между модулями.
Коллеги и друзья отмечали так же вполне приемлемое написание документации с использованием ИИ-агента для публичных инструментов.
Ещё моё наблюдение - ИИ-агент неплохо срабатывает в задачах, где программист обычно сталкивается с затруднениями и начинает переваривать условия в голове, скатываясь в прокрастинацию. Один промпт - и у тебя появляется "какое-то" решение, сдвигая весь процесс с мёртвой точки.
На мой взгляд, хороший инструмент, пользуюсь, рекомендую)

Генеративный ИИ - это инструмент, который в каких то задачах работает хорошо, в каких-то все портит. Мне он помогает, избавляет от рутины, ускоряет разработку. Такое чувство, что все рассматривают ИИ как панацею, а потом разочаровываются, ожидание и реальность расходятся и начинается холивар.

За два дня сделал на DeepSeek аналог известной платной программы для каталогизации накопителей — под себя. Сам не из IT, а из медиа. Так сказать, пример из жизни.

Любой инструмент-- Это всего лишь инструмент. Им надо уметь пользоваться, знать его ограничения и чётко определять область применения.

Если код не работает в самолётах, автомобилях, кардиостимуляторах и прочих жизненно-важных вещах, и при этом приносит доход бизнесу, то вменяемый бизнес сможет оценить отношение прибыли к возможным убыткам из-за багов. Оценить какое влияние на прибыль окажет более ранний выход продукта на рынок, даже в сыром состоянии. Если их это устроит, то ничего не помешает внедрить говнокод в прод.

Программист часто забывает, что он для бизнеса точно такой же инструмент, как для него язык программирования или LLM.

И нам надо всего лишь дождаться, когда бизнесу понадобится новые фичи, внедряемые в этот же самый продукт написанный искусственным интеллектом. И вот тогда мы сможем применить наши знания на полную катушку, и получить неплохой доход от этого. Надо всего лишь переждать этот перегрев рынка, освоить новый инструмент, и научиться использовать его в свою пользу. Ведь даже если искусственный интеллект позволяет получить всего лишь ощущение ускорения работы, то это уже большое дело, учитывая как болезненно для некоторых людей проходит выгорание. С помощью искусственного интеллекта мы можем сильно снизить вероятность выгорания программиста

Я бы сказал, что при нормальном применении AI назвать этот процесс вайб-кодингом очень сложно, ибо никакого особого вайба тут нет. Ты сидишь и добиваешься от него того, что тебе надо. Тем не менее это очень помогает.

Но понятно, что до того, чтобы обойтись без программистов, пока далеко. Как раз для того, чтобы выжать из ИИ-помощника что-то нормальное, нужно много опыта. Не уверен, что это под силу какому-то джуниору. Джуниор напишет примерно то, что писал до ИИ — то, что придётся доводить до ума.

В общем, ИИ, наверное, повышает производительность разработчика, но точно не повышает качество его кода. Что он мог написать сам, то же он выжмет из ИИ. Это если не ударится именно в вайб-кодинг, тогда результат будет даже хуже.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации