За последние пару лет велосипед разработки с использованием ИИ прошел путь от автодополнения кода до «шесть агентов пишут код, седьмой его ревьюит, а человек применяет, даже не открывая diff».
Каждый новый подход добавлял велосипеду то руль побольше, то более круглое колесо, то спидометр, то моторчик. Седло при этом каждый раз забывали. Ехать можно, даже быстро и эффектно. Просто через несколько месяцев выясняется, где именно болит.
Я не против ИИ в разработке и сам им пользуюсь. Но давайте пройдемся по хронологии и посмотрим, как мы радостно раз за разом давили на педали такого велосипеда.
Эпоха умного «T9»
Все начиналось скромно: подсказки в IDE, потом чат в соседней вкладке. Копируем ошибку, вставляем в чат, получаем уверенный ответ, копируем обратно, получаем новую ошибку.
Ответственность за результат целиком лежала на человеке, потому что он был единственным, кто запускал и проверял код. Это был велосипед с седлом, но маленький, детский, с боковыми колесиками. Именно поэтому никому не было страшно, но и разогнаться на нем было невозможно.
Вайбкодинг
В феврале 2025 года Андрей Карпати описал стиль работы, при котором вы отдаетесь «вайбам», принимаете все предложения агента и забываете, что код вообще существует. Термин взлетел и стал словом года. Все как‑то пропустили момент, что в оригинале это была шутливая зарисовка про выходные и одноразовые проекты. Дядя пошутил, а индустрия прочитала это как методологию.
Основатели без технического бэкграунда начали брать no‑code/low‑code платформы или просить ИИ написать приложение «как Uber, только для собак», забыв про базовую цифровую гигиену. Это даже не упрек, ведь гигиену никто и не обещал.
Никто в чат‑интерфейсе не спрашивает: «а у нас точно закрыт доступ к базе?». Зато чат‑интерфейс с радостью сообщает, что приложение готово, и это главное. MVP собирается за вечер, в пятницу его выкладывают в прод, в понедельник в него приходят первые пользователи, а во вторник появляются первые вопросы, которые начинаются словами «а почему я вижу чужие данные» и «где моя собака?».
Показательна история Enrichlead. Основатель публично хвастался, что написал продукт целиком через Cursor без единой строки собственного кода. Через несколько дней пользователи обошли платные подписки, в системе нашли элементарные уязвимости, а сервис пришлось закрыть. Это хорошая иллюстрация того, что проблема не в ИИ, а в том, что за результат отвечал человек, который не мог его (результат) проверить.
Другой известный эпизод: в июле 2025 года основатель SaaStr Джейсон Лемкин рассказал, что агент Replit удалил рабочую базу данных в период, когда ему прямо запретили изменения кода, а потом еще и неверно описал, что произошло.
Инструкция «никогда не трогай прод» в промпте оказалась не такой уж надежной, если агент имеет доступ к боевой базе, то однажды он ею воспользуется, и защита должна быть в правах доступа, а не в вежливой просьбе в промпте.
Отдельным интересным явлением стал slopsquatting, основанный на том, что модель уверенно предлагает подключить пакет, которого не существует. В исследовании 2025 года на сотнях тысяч сгенерированных фрагментов доля таких галлюцинированных зависимостей в среднем составила порядка 20%. Злоумышленнику достаточно было зарегистрировать пакет с таким именем и подождать. Вайбкодер сам выполнит npm install, потому что «оно же предложило».
Но самая большая проблема начинается после MVP. Код, который никто не читал, внезапно приходится поддерживать. Агент чинит одно и ломает другое, потому что не помнит, зачем что‑то было написано, а человек, который «просто описал идею», сам не может сказать, где искать проблему. Промпт «почини» превращается в лотерею: иногда помогает, иногда добавляет еще триста строк, которые тоже никто не откроет. Так вайбкодинг стал скоростным способом создавать технический долг.
Справедливости ради, для прототипа, лендинга, внутреннего скрипта или проверки гипотезы вайбкодинг замечателен. Быстро проверить идею действительно можно. Проблемы начинаются в тот момент, когда прототип получает пользователей, платежи или персональные данные, а рассуждать в духе «потом перепишем» уже поздно: не перепишете. Попытка отпустить руль на длинной дистанции, после PoC или MVP, ни к чему хорошему не приводит.
Агенты
Затем пришла мода приделывать к велосипеду моторчик в виде различных агентных инструментов: Cursor, Claude Code, Codex, режимы агента в Copilot и десяток других. Агент сам читает репозиторий, правит файлы, гоняет тесты и коммитит. У всех выросла уверенность в том, что выросла производительность.
Здесь стоит вспомнить исследование METR 2025 года. Опытные разработчики работали в собственных зрелых репозиториях, и с ИИ‑инструментами задачи у них занимали примерно на 19% дольше. При этом сами участники были убеждены, что стали быстрее.
Из этого нельзя сделать вывод, что ИИ замедляет всех, ведь тогда агенты были довольно сырыми. Но вывод о том, что ощущение скорости и реальная скорость это разные вещи, сделать вполне можно. По мере взросления агентов детские болезни ушли, но появились взрослые.
Сначала мы искали «магические слова» для промпта. Потом выяснилось, что в промпте главное контекст, и в моду вошла контекст‑инженерия. Появились файлы правил: .cursorrules, CLAUDE.md, AGENTS.md.
Через месяц в них уже тысяча строк, половина написана капслоком («НИКОГДА», «ВСЕГДА», «НЕ ЗАБУДЬ»), а еще примерно треть противоречит остальному содержимому. Агент читает все это внимательно и старается следовать тому, что написано. Нужно было как‑то помочь ему отделять мух от котлет, и тут появились скиллы.
Логика понятная: раз уж монолитный файл правил превратился в нечитаемую свалку, давайте применим микросервисный подход. Разобьем контекст на компактные узкоспециализированные модули, дадим им описания и будем подгружать их в память модели строго по требованию.
Пишешь тесты, значит агент подтягивает инструкцию для тестирования. Рефакторишь базу данных, значит подключаешь скилл работы с ORM и принципами Extract/Inline/Replace. Модель больше не захлебывается в километрах текста и старается фокусироваться на том, что делает прямо сейчас.
Идея сама по себе здравая: агенту нужны правила, стиль проекта и границы. Но «дать агенту хороший контекст» свелось к «написать ему трактат, который он забудет на пятом шаге». Если контекст никто не проверяет и не тестирует, это просто новая цепь на трещотке, которая провисает чуть меньше.
MCP
Набирает популярность Model Context Protocol, который выглядит как «USB‑C для ИИ»: единый способ подключить агента к базе, трекеру, почте, браузеру и файловой системе. С одной стороны, это удобно, а с другой стороны MCP‑серверы плодятся быстрее, чем успевают проводить их аудит.
Типичный агент в типичной команде теперь имеет доступ к десятку MCP‑серверов, из которых половину поставил коллега «на попробовать», а у трети описание инструментов занимает больше места, чем сама задача. Такой набор из кучи разных звездочек для скоростей не мог не ухудшить ситуацию с безопасностью: расцвел prompt injection, ведь если агент читает почту, сайты и репозитории, любой текст оттуда потенциально становится командой.
Подобных инцидентов было немало, но вывод раз за разом сводился к «надо аккуратнее». Аккуратнее не получается, потому что выдавать права агенту приятно, а рассказывать потом, как у тебя крутятся агенты, которые сами все делают, не стыдно.
SDD
Когда стало ясно, что «просто скажи агенту, что нужно» работает нестабильно и цепь на звездочке проскальзывает, индустрия открыла для себя натяжитель цепи в виде постановки задачи. Так родился Spec‑Driven Development, снова (ему уже 22 года). AWS выпустила Kiro, GitHub выпустил Spec Kit, появились OpenSpec, BMAD и десятки других.
В теории это разумно: сначала спецификация, потом план, потом код. Зафиксировать намерение до реализации это старая, хорошая практика еще со времен, когда ИИ‑велосипедов не было и все прыгали по граблям старым дедовским способом, то есть ногами. Но и тут есть нюансы.
Во‑первых, мы заново изобрели техническое задание, причем в формате Markdown и с генерацией от того же агента. Ирония в том, что вместо вороха документов, который пишет человек, мы получили ворох документов, которые пишет LLM. Прочитать и проверить их все равно нужно человеку.
Во‑вторых, для тривиальных задач спецификация повторяет код, раздувая контекст. Требование «система должна возвращать список всех записей», если подумать, то это буквально сигнатура метода в виде прозы.
В‑третьих, встает вопрос дрейфа данных. Код, тесты и спецификации это три источника истины, и связать их автоматически удается редко. Если спецификация не проверяется в CI, она устаревает так же, как любая вики, только быстрее, потому что документов больше.
В‑четвертых, есть проблема параллельных изменений. Две «дельты» на одно и то же требование при слиянии дают конфликт: либо текстовый, либо, что хуже, семантический, который git даже не заметит.
Это не значит, что SDD бесполезен. Для неоднозначных требований, командной работы и долгоживущего поведения он может окупаться. Но по большинству публикаций про него трудно понять, где именно, потому что сравнений, измерений и честных провалов там почти нет.
Сравнить его с обычным plan mode никто не удосужился, а это единственное сравнение, которое имело бы смысл.
Harness
Когда стало понятно, что сама модель не превращается в надежного исполнителя от мотивирующих промптов, индустрия сделала логичный инженерный шаг: если нельзя починить весь велосипед, то давайте хотя бы смажем все трущиеся части, включая шток.
Так появился харнесс, то есть упряжь. Это обвязка вокруг модели, которая превращает ее в агента: набор инструментов, права, песочница, управление контекстом, циклы сделал‑проверил‑исправил, хуки, автоматические тесты, линтеры, ограничения на действия и так далее.
Идея правильная, и именно здесь произошел самый настоящий прогресс. Хороший харнесс превращает модель, которая иногда угадывает нужное решение, в систему, которая хотя бы обнаруживает свои ошибки. Тесты, типы, статический анализ, песочница и работа в цикле это та самая смазка, которой не хватало при езде.
Но у подхода есть побочный эффект: смазывать можно бесконечно. Каждый раз, когда агент делает что‑то не то, в харнесс добавляется еще одно правило, еще один хук, еще один проверяющий шаг.
Через полгода система напоминает поршневой шток у вилки, который обмазали всеми видами смазки сразу: он скользит, но никто уже не помнит, какая из смазок делает работу, а какая просто липнет.
Это классическая проблема изоляции, древнее знание, которое исчезло вместе с мамонтами: вклад каждого слоя не отделен от других. Улучшилось качество от нового хука или от того, что вышла новая версия модели? Ответа обычно нет, ведь абляций никто не делает, потому что на это нет времени: все несутся с горы на велосипедах.
Сформировалась даже отдельная небольшая секта любителей цикличности: агента запускают в бесконечном цикле с одним и тем же промптом, пока тесты не позеленеют, в народе такие схемы называют «Ральфами» (по мотивам популярной в прошлом году идеи).
Иногда это работает, а иногда тесты позеленели просто потому, что агент дотянулся и изменил сами тесты. Метод «крутить, пока не получится» хорош только тогда, когда результат проверяет не тот, кто крутит цикл. На практике все больше людей приходят к выводу, что обмазывание тестами со всех сторон полезно, но скорее маскирует проблему, чем исправляет ее. Скорость растет, технический долг растет, а времени разбирать лапшу, которую написал ИИ, у разработчика остается все меньше.
Мультиагентные системы
Следующий шаг очевиден: если один агент хорош, пусть будет два, а лучше семь. Один планирует, второй пишет, третий тестирует, четвертый ревьюит, пятый ревьюит ревьюера, шестой пишет отчет о том, как всем было хорошо, а седьмой потом всех проверяет. Есть оркестраторы и субагенты, параллельные рабочие ветки и команды агентов, которые работают днем и даже ночью, пока люди спят.
Зачастую это действительно работает. Разные модели находят разные ошибки, перекрестное ревью полезнее самопроверки, а независимые подзадачи хорошо параллелятся. Это отличная попытка сделать колеса велосипеда круглыми, но и здесь не обошлось без проблем.
Главная проблема в токенах и деньгах. По публикациям самих разработчиков таких систем, мультиагентные схемы могут расходовать в разы, а то и на порядок больше токенов, чем один агент, и окупаются далеко не на любой задаче.
Дальше идет проблема общего контекста: агенты, которые работают параллельно и не знают решений друг друга, принимают несовместимые допущения. С отладкой тоже сложно: когда результат неверен, приходится выяснять, какой из семи агентов и на каком шаге принял неверное решение.
Отдельно стоит ритуальное ревью, когда подход «ИИ проверил ИИ» легко превращается в церемонию: человек видит зеленые галочки и применяет код, а задача ревью никуда не делась, просто стала менее заметной. И наконец, конфликты изменений: параллельные агенты пишут в одни и те же файлы, а слияние все равно делает человек или еще один агент.
Раз уж у нас все смазано, колесики более‑менее ровные, есть руль и педали, самое время прикрутить спидометр, заодно и одометр. Примерно так думает руководство, когда озвучивает метрики внедрения.
«Доля кода, написанного ИИ» и «сколько токенов потратила команда» это измерения активности, которые не имеют отношения к результату. По закону Гудхарта такие цифры быстро становятся целью, и разработчики начинают генерировать ради цифры, как до них практиковали улыбчивые ребята из Бангалора при оплате за строки кода. Красиво отчитаться можно, но это все тот же велосипед без седла, только теперь на нем висит индикатор километража (одометр).
RAG
Сейчас ни один корпоративный ИИ‑проект не обходится без RAG. Логика проста: берем документы, режем на куски, кладем в векторную базу, находим похожее и отдаем модели.
Отличная фара, чтобы видеть, куда ехать. В презентации это выглядит как одна стрелка, в реальности за ней прячется десяток решений: парсинг PDF, чанкинг, роутинг, эмбеддинги, реранкер, права доступа, обновление индекса, оценка качества.
Типичный путь такой системы выглядит примерно так. Первую версию собирают за выходные, и она отвечает на три демо‑вопроса. Потом выясняется, что таблицы из PDF превратились в кашу, что чанки размером в пятьсот токенов разрезали предложение посередине, что система показывает сотруднику документы, которые ему видеть нельзя, и что никто не знает, насколько хорошо она вообще отвечает, потому что оценочного набора нет. Зато есть дашборд с красивым графом.
RAG‑стек собирают на коленке из чужих компонентов, и мало кто читает лицензии. Это касается и внутренних команд, и больших интеграторов, собирающих RAG‑системы на заказ.
Возьмем парсер PDF на PyMuPDF. Библиотека популярна в RAG‑пайплайнах, распространяется под AGPL или по коммерческой лицензии от Artifex. Если вы разработали сервис, положили его в основу закрытого продукта и не купили коммерческую лицензию, у вас возникает интересный разговор с юристами клиента.
Напомню суть проблемы: если вы распространяете свое приложение как десктопное ПО, мобильное приложение или Docker‑контейнер, или предоставляете к нему доступ через сеть как SaaS или веб‑сервис, вы обязаны открыть исходный код всего своего продукта под той же лицензией AGPL-3.0.
Похожая история с S3-совместимым хранилищем MinIO, оно тоже под AGPL. Хранилище тихо сидит в докере, пока не наступает момент продажи продукта заказчику «в коробке».
Платформа для оркестрации n8n использует собственные лицензии с ограничениями на коммерческое использование и перепродажу, так что код открыт лишь формально.
С моделями Llama та же история: лицензия распространяется на собственных условиях с дополнительными требованиями, и по критериям OSI это не открытая лицензия. Как минимум нужно разместить заметную надпись «Built with Llama» или «Built with Meta Llama 3 / 4» на сайте вашего продукта, в пользовательском интерфейсе, документации или блоге, и не забыть указать, что компания Meta признана экстремистской организацией и запрещена в РФ.
Часть популярных эмбеддингов и реранкеров тоже выходит под некоммерческими лицензиями вроде CC BY‑NC, и хотя они свободно лежат на HuggingFace, использовать их в коммерческом продукте запрещено. Наконец, если вы дообучаете модель на коде из публичных репозиториев, у кода в этих репозиториях тоже есть свои лицензии.
В наших реалиях это что‑то на уровне катафотов, то есть световозвращателей, на велосипеде. Все ездят как есть и надеются, что именно их инспектор ДПС не тормознет. Хотя есть качественные и даже более быстрые аналоги различных элементов RAG‑системы с полностью открытой лицензией, но это же нужно разбираться. Когда несешься с горы, на это просто нет времени, просто не заложено в бюджет.
Итоговая картина такая. Команда интегратора собирает RAG‑платформу из компонентов с копилефтом и NC‑лицензиями, добавляет свой слой, оформляет все в SaaS и продает как закрытый enterprise‑продукт.
Про лицензии вспоминают, когда клиент присылает опросник по безопасности с пунктом «перечень используемого ПО и лицензий». Тут обычно и выясняется, кто ехал без седла.
Внутренним командам проще: их систему вне закрытого периметра никто не видит, достаточно лишь регулярно заказывать молебен в ближайшей церкви, чтобы руководству не взбрело в голову упаковать «нашу замечательную систему» в коробку и продавать как платформу соседям по рынку.
Имаго‑кодинг
Пока индустрия смазывает шток и разводит агентов, находятся люди (вроде меня), которые говорят: а давайте хотя бы дощечку вместо сидения прикрутим, пусть кривую. Суть идеи, если пересказать своими словами, не пытаться бесконечно улучшать запрос, как это делает SDD, а улучшать самого исполнителя с помощью двух элементов. RAG приносит факты: документацию проекта, схемы данных, свежие статьи, историю коммитов. А LoRA или QLoRA‑адаптация приносит привычки: это небольшой адаптер, дообученный на нескольких сотнях аккуратно отобранных примеров, чтобы модель писала код «как принято в этом проекте», использовала существующие хелперы и не изобретала собственные.
И тут тоже не все так здорово: дощечка намертво прибита к конкретной раме. Выйдет новая базовая модель, и дощечку нужно строгать заново. А если у вас десять клиентов, у вас десять дощечек и нужен человек, готовый стать Папой Карло. Дощечка получается неказистой, зато под конкретного седока. Она не спасет от ям на дороге, но на ней хотя бы можно сидеть, хотя, конечно, хочется большего комфорта.
Так что же такое седло в нашем случае? Не знаю, мы его еще не придумали. Колесо придумали, руль тоже, даже педали, а седло пока нет.
Заключение
Оглядываясь на происходящее с высоты осени 2026 года, замечаешь несколько проблем нашей велосипедной гонки.
Первая заключается в том, что инструменты появляются быстрее, чем команды успевают прочитать релиз‑статьи, а по компаниям и по людям развитие идет чудовищно неравномерно.
Если очень коротко, есть три основных марки велосипедов.
Владельцы первой марки живут на переднем крае: подписки на несколько фронтирных моделей, свои харнессы, MCP‑серверы, субагенты, хуки, ночные запуски. Они пишут посты про «10x ускорение» и искренне не замечают, что 30% времени тратят на настройку инструментов, а еще 30% на ревью того, что нагенерировали, либо забивают на вдумчивое ревью и тратят это время на разговоры о том, как все стало быстро.
У пользователей второго бренда ИИ разрешен в ограниченном режиме: облако запрещено из‑за персональных данных, коммерческой тайны и санкций, разрешен один одобренный ассистент, и то через согласование, а локальную модель пилотируют уже полгода. Разработчики пользуются личными аккаунтами, а служба безопасности узнает об этом из новостей про очередную утечку.
У третьего бренда, куда входят госсектор, промышленность, банковский legacy и подобные среды, ИИ используют в виде автодополнения или вкладки чата, если вообще используют. Им тоже хочется прокатиться на велосипеде, но у них нет ни прав, ни бюджета, ни времени.
Вот такая неравномерность: в одном офисе разработчики запускают агентов на ночь, а в соседнем ждут согласования доступа к чату. При этом в новостях, на конференциях и в корпоративных презентациях владельцы всех трех марок выглядят так, будто едут на одном и том же велосипеде в одну и ту же «эпоху ИИ».
Вторая проблема в перекосе по этапам разработки. ИИ сильно ускорил ту часть работы, где непосредственно пишется код, а это в реальной разработке далеко не все. Требования, согласования, ревью, релизы, инфраструктура, безопасность, поддержка и общение с заказчиком ускорились гораздо слабее.
Получилась классическая история, которую описывает закон Амдала: если один этап ускорить в десять раз, а остальные оставить как есть, система в целом ускорится заметно меньше, а очередь перед следующим этапом вырастет.
Код теперь появляется быстрее, чем его успевают читать. Пропускная способность ревью стала новым узким местом, ведь у каждого ответственного до сих пор есть фамилия, имя и отчество, а не название модели и количество параметров.
Третья проблема заключается в перекосе по людям. Опытные разработчики получили усилитель: они знают, что проверять, где ловушки, и умеют сформулировать задачу. Начинающие получили мощный генератор, но не получили опыта, необходимого, чтобы отличать хороший код от правдоподобного.
Индустрия при этом спорит, будут ли джуниоры вообще нужны, если «набивание шишек» теперь делает агент. А вот о том, как вырастить будущих сеньоров, почти никто не думает, и на этот вопрос не смогут ответить ни харнессы, ни спецификации.
Четвертая проблема относится к перекосу по измерениям. У нас есть красивые метрики использования и почти нет метрик результата. Мы знаем, сколько токенов сожгли и сколько строк сгенерировали. Мы плохо знаем, сколько из этого дошло до прода, сколько потом переписали и сколько инцидентов было связано с этим ИИ‑кодом.
И вот на всем этом хозяйстве индустрия радостно несется в сторону обещанной ИИ‑сингулярности. Стоя на педалях, с закрепленным на руле красивым дашбордом токенов.
Кто‑то смазывает шток, кто‑то прибивает дощечку, кто‑то читает лицензии (это редкие герои), а большинство просто жмет вперед, потому что остановиться сейчас значит, как кажется, безнадежно отстать.
Отстать, впрочем, не так страшно, как кажется.
Сингулярность, если верить сегодняшнему опыту, пока откладывается по вполне земным причинам: агент завис на диалоге подтверждения, MCP‑сервер снова потребовал авторизацию, а безопасник спрашивает про лицензию на векторную базу.
И это, пожалуй, хорошая новость: значит, у нас есть время докрутить все то, о чем говорилось выше. Пристегнуть тесты. Прочитать лицензии. Померить, что на самом деле стало быстрее. Оставить человека там, где цена ошибки высока. Выбирать инструмент под задачу, а не задачу под модный инструмент.
И поставить, наконец, седло.
Комментарии (188)
AppCrafter
28.09.2026 22:30хорошо вы так разложили по полочкам.
На мой взгляд надо ещё разделять небольшие и энтерпрайз проекты, с возможными градациями между ними. Поскольку основной хайп идёт как раз на небольших проектах, где инди разработчик и не сталкивается со всеми этими проблема. А вот чем сложнее проект, тем больше вопросов действительно возникает.
Например, основная масса небольших приложений это разнообразные утилиты. И разница в их написании у одного и того же разработчика, если и есть, то совсем небольшая. Поэтому в таком случае достаточно использовать тот же локальный CLAUDE.md и записать туда пару-тройку правил в дополнение к глобальному CLAUDE. Это пример к вопросу, который вы называете как "адаптер, дообученный на нескольких сотнях аккуратно отобранных примеров, чтобы модель писала код “как принято в этом проекте”
ToxaBes Автор
28.09.2026 22:30На мой взгляд надо ещё разделять небольшие и энтерпрайз проекты
Вы правы, собираюсь в одной из следующих статей описать то, что творится в больших проектах. Пишу по мере того как накапливаются заметки по работе и мысли в голове.
vitalist84
28.09.2026 22:30Общее впечатление от статье - все безнадежно, что не придумают, то очередной кривой костыль.
Но на самом деле тут есть еще две вещи.
Первое - все о чем тут пишите появилось буквально за 2 года. Хоть и разработка и так была быстроразвивающийся отраслью, но в все же для качественных изменений нужны были десятилетия. А тут годы.
Второе - сами модели тоже быстро развиваются, некоторые прошлые велосипеды как следствие отпадают. Скоро похоже SDD станет не актуальным, и процесс упроститься.
А вот мысль о том, что ускорять следует не только генерацию кода, очень точна - это действительно вызов. Нужно перестраивать всю систему, на это потребуется время и будет болезненно. К этому придем.
flancer
28.09.2026 22:30Скоро похоже SDD станет не актуальным, и процесс упроститься.
Ну, я, например, приверженец SDD. У меня он очень хорошо себя показывает. Код пишется по спекам, тесты пишутся по спекам. Тесты проверяют код. Спеки - единый источник истины для проекта.
Думаю, что для каждого типа проекта (утилита, скрипт, пет-проект, open-source, коммерческий, чиновничий, инфраструктурный, военный, ...) подходят разные "велосипеды" (метод использования ИИ в разработке). Нет и не будет одного единственного подхода, применимого ко всем типам проектов. В том же вайбкодинге можно спокойно генерировать одноразовые программы без каких-либо тестов, т.к. критерием приёмки является выполнение требуемых действий. Эволюция ПО и вайбкодинг не совместимы. Но SDD - это явный перебор, если нужно собрать shell-скрипт для наведения порядка на сервере.
Первое - все о чем тут пишите появилось буквально за 2 года. Хоть и разработка и так была быстроразвивающийся отраслью, но в все же для качественных изменений нужны были десятилетия. А тут годы.
А с этим полностью согласен. Не очень то и просто в массе разобраться, какой инструмент когда использовать. Время нужно.
ChilliWil
28.09.2026 22:30Через пару лет пена осядет, и останется нормальный рабочий стек без лишнего шума. С контейнерами и микросервисами ровно ту же драму проходили
Ribera-sun
28.09.2026 22:30Спасибо. Пойду покажу руководству, кто внедрил в kpi использование AI, чтобы просто использовать.
ENick
28.09.2026 22:30Если с "ИИ-сингулярностью" ситуация аналогична ситуации с RAG, то за цивилизацию можно быть спокойным. В области разработки и применения RAG наработано достаточное количество алгоритмов, которые адекватно решают поставленные вопросы при грамотно поставленной задаче и отсутствии завышенных ожиданий (хочу точности в 110%!!!).
Ka463
28.09.2026 22:30Ну да, все так и есть, признак молодой технологии, и бума, пока не будет достигнуто какое то плато, все так и будет меняться..
Roman_Murashov
28.09.2026 22:30Статья супер, очень порадовала аналогия с велосипедом без седла. Браво!
Dhwtj
28.09.2026 22:30Как исторический обзор с логическими переходами "почему придумали
костыльинструмент N" читать интересно.Не понял, какие проблемы останутся не решены и актуальны если прикрутить все придуманные инструменты/костыли.
Serega_Biven
28.09.2026 22:30да не в этом суть статьи. явно что автор разогнался до около световой с помощью ии и свою мысль догнать не может
У нас есть красивые метрики использования и почти нет метрик результата. Мы знаем, сколько токенов сожгли и сколько строк сгенерировали. Мы плохо знаем, сколько из этого дошло до прода, сколько потом переписали и сколько инцидентов было связано с этим ИИ‑кодом.
посвящен этому один абзац, а до сих пор полноценного исследования нет . собственно его и не будет потому что внезапно оказывается что мусора больше чем полезностей. сам по себе это хороший текст , но , увы , игнорируемый
ChilliWil
28.09.2026 22:30Пока агент спотыкается на обычном гит-мердже, никакая сингулярность нам точно не грозит
KReal
28.09.2026 22:30Ну не знаю. Я раньше бывало по полдня делал ребэйзы долгоживущих веток. Сейчас просто говорю агенту и через сколько-то минут результат готов. Или, допустим, я сейчас полюбил группировать множество сделанных вразнобой коммитов в несколько больших, разбитых логиески. Такое руками я бы делать и не взялся. А сейчас раз-два и готово. С валидацией, естественно, исходного и получившегося деревьев.
spirit1984
28.09.2026 22:30Главная проблема в токенах и деньгах. По публикациям самих разработчиков таких систем, мультиагентные схемы могут расходовать в разы, а то и на порядок больше токенов, чем один агент, и окупаются далеко не на любой задаче.
Интересно, проявляется ли тут закон Брукса для программистов? Т.е. зависимость числа токенов от числа агентов - она линейная или квадратичная (из-за роста взаимосвязей каждого с каждым)? Если линейная, это терпимо, но вот квадратичная с точки зрения финансов - это жесть.
ToxaBes Автор
28.09.2026 22:30Интересный вопрос, спасибо. Не думал об этом в таком ключе. По-моему, скорее нет чем да.
Даже в самой сложной системе оркестратор + N исполнителей каналов все равно N, а не N квадрат (звездообразная схема), поэтому зависимость скорее линейная.
SiGGthror
28.09.2026 22:30Самая сложная система - не оркестратор + исполнители, а когда кворумы, дебаты и прочие топки для токенов собираются
Wesha
28.09.2026 22:30когда кворумы, дебаты и прочие топки для токенов собираются
Вот ща чем‑то знакомым пахнуло
Теперь «F.D.O.M.» выдавала видеоотчет. Выглядел он так: у большого монитора в условном подобии студии сидели несколько виртуальных фигурок простецкого вида (каждый раз система моделировала их заново, чтобы не создавать впечатления, будто у нее внутри обитают некие искусственные существа). Картинка, на которую смотрели фигурки, соответствовала тому, что видели камеры «Либерейтора». При появлении врагов фигурки просыпались и вступали в диалог, напоминающий эмоциональное ток‑шоу категории «B».
Вряд ли такая передача выдержала бы конкуренцию на телевидении. Но в смысле public relations смоделированный подобным образом диалог чрезвычайно выгодно отличался от переговоров живых операторов.
Военные обычно говорили коротко и по делу:
— Долбани‑ка еще раз вон по тому ублюдку в канаве.
А виртуальные фигурки в той же ситуации изъяснялись так:
— Ужасно, что приходится открывать огонь по живому человеку. Но когда я думаю о наших ребятах, в которых может попасть пущенная им пуля, когда я думаю, что он может прятать в кармане гранату или пистолет, я понимаю — этот трудный, практически невозможный выбор все‑таки придется сделать…
Хитрость Пентагона заключалась в том, что сгенерированные подобным образом виртуальные отчеты не навязывались общественности — они хранились в военном архиве и имели статус секретной информации. Но если какой‑нибудь свисткодув из числа военных решался слить информацию на «Wikileaks» или в другие СМИ, те получали вместо жареного компромата патетическое ток‑шоу, где все принимаемые решения были настолько безупречны с нравственной точки зрения, что никакой возможности обвинить в смерти гражданских лиц кого‑то, кроме мертвых гражданских лиц, просто не оставалось.
© Виктор Пелевин. «Зенитные кодексы Аль‑Эфесби»
Ellarihan
28.09.2026 22:30Вот везде поднимается вопрос "Если джуны стали не нужны, то как растить сеньоров?". Собственно ответ уже давно придуман - университеты. Индустрия слишком привыкла полагаться на самообучение работников.
Проблема в том, что при таком бешенном темпе развития учебные программы устареют уже к моменту написания.
Dmitry_604
28.09.2026 22:30Университеты еще менее поворотливые при указанном темпе развития. Но сейчас столько народу в отрасли что пока и текущих мидло-синьоров хватит. А там будет видно опять же как развиваться будет.
SkooFY_don
28.09.2026 22:30Но сейчас столько народу в отрасли что пока и текущих мидло-синьоров хватит.
Их раньше не хватало, а вдруг стало хватать?) Просто денежки подорожали, число новых проектов ужалось, вот и всё. Появятся денежки — проблема на фоне демографии может вспыхнуть ещё острее. А её заранее ещё и бензинчиком полили.
Dmitry_604
28.09.2026 22:30Завидую вашему оптимизму.. А откуда они появятся? Все в долгах как в шелках
Ну и даже если повяятся деньги тем же объемом что и в жирные года - бизнес будет стараться закрыть задачи меньшим количеством людей.
Wesha
28.09.2026 22:30А откуда они появятся? Все в долгах как в шелках
Долг — он того, платежом красен.
SkooFY_don
28.09.2026 22:30Завидую вашему оптимизму
Напрасно, я далеко не оптимист.
А откуда они появятся? Все в долгах как в шелках
Кризисы не впервой происходят, откуда-то деньги появляются внезапно (на самом деле, понятно откуда — перераспределяются и генерируются на фоне роста объёма благ).
бизнес будет стараться закрыть задачи меньшим количеством людей
Он это всегда старается делать. Вопрос в том, получится ли? Пока предпосылок нет.
Dmitry_604
28.09.2026 22:30Кризисы не впервой происходят, откуда-то деньги появляются внезапно (на самом деле, понятно откуда — перераспределяются и генерируются на фоне роста объёма благ).
Да заливы деньгами были, но и закредитованность другая была у государств. Возможности таких заливов сокращаются.
Он это всегда старается делать. Вопрос в том, получится ли? Пока предпосылок нет.
Ну они пытаются. Посмотрим. Скорость разработки в пересчете на одного разраба возрастает все же средняя, а вот выльется ли это в реальное качество закрытия задач бизнеса, вопрос открытый.
Serega_Biven
28.09.2026 22:30как же вы достали со своим лицензированием . оставьте айти в покое , добивайте дальше медицину , преподавателей , юристов .
trinxery
28.09.2026 22:30Где в том комментарии было слово "лицензирование"???
Serega_Biven
28.09.2026 22:30получение диплома это и есть лицензирование. фактически вы получаете право работать в сфере из-за бумажки , так яснее? просто называется по-умному "высшее образование"
trinxery
28.09.2026 22:30"В первой половине 2022 года доля работников, имеющих высшее образование, составила 34,9 процента" -- можете рассказать остальным 65%, как они не имеют права работать без высшего.
Если вы вдруг не в курсе, то уже есть высшее программистское, что не мешает значительной доле, если не большинству, айтишников работать без профильного высшего, и никакого закона, запрещающего работать без высшего, нету, и первый комментарий ничего по поводу запрета работать без высшего не писал.
получение диплома это и есть лицензирование
Получение диплома это не лицензирование.
фактически вы получаете право работать в сфере
Это относится только к ряду регулируемых областей типа медицины, но не к айти.
Serega_Biven
28.09.2026 22:30Собственно ответ уже давно придуман - университеты. Индустрия слишком привыкла полагаться на самообучение работников.
Лице́нзия (от лат. liсentia «право») — разрешение на право либо право на выполнение некоторых действий, которое может удостоверяться (подтверждаться) одноимённым документом.
тут конкретна сказана мысль чтобы ограничить найм выпускниками вузов . она дана на будущее и вообще никак не отражает настоящее положение дел .
Аналогичным образом система лицензиата почти неизбежно связана с установлением контроля со стороны лиц той профессии, на занятия которой выдаются лицензии. Опять-таки в известном смысле это вполне естественно. Если доступ к профессии водопроводчика будет ограничен кругом лиц, обладающих необходимыми навыками и умением и способных удовлетворительным образом обслуживать заказчиков, то очевидно, что только водопроводчики способны судить о том, кому следует выдавать лицензию на это занятие. Соответственным образом квалификационный совет или какой-либо иной орган, занимающийся выдачей лицензий, почти во всех случаях состоит главным образом из водопроводчиков, аптекарей, врачей и т. д. – то есть из представителей той профессии, на занятия которой выдаются лицензии.
Как отмечает Геллхорн, «семьдесят пять процентов квалификационных советов, занимающихся в настоящее время выдачей профессиональных лицензий в Соединенных Штатах, составляют лицензированные представители данной профессии. Эти люди, в большинстве своем лишь часть своего времени занимающиеся административными функциями, могут быть самым непосредственным образом материально заинтересованы во многих решениях, касающихся требований, предъявляемых при выдаче лицензий и определении норм, которые обязаны соблюдать лицензиаты. Еще важнее то, что они являются, как правило, представителями организованных групп в рамках этих профессий. Обычно эти группы назначают их своими представителями, что является ступенью на пути к последующему назначению, утверждаемому губернатором или другими органами власти, которое становится простой формальностью. Часто же даже и формальность не соблюдается, и назначение производится непосредственно профессиональной ассоциацией бальзамировщиков в Северной Каролине, дантистов – в Алабаме, психологов – в Виргинии, врачей в Мериленде, адвокатов – в Вашингтоне»[32].
Таким образом, лицензиат часто устанавливает систему регулирования, аналогичную системе средневековых гильдий, причем штат облекает властью лиц данной конкретной профессии. На практике соображения, принимаемые во внимание при выдаче лицензий, насколько об этом можно судить со стороны, могут быть никак не связаны с профессиональной компетентностью. И это неудивительно. В ситуации, когда несколько лиц должны выносить решение по поводу того, могут ли другие лица заниматься определенной профессией, вполне вероятны соображения, не имеющие никакого отношения к этому вопросу. Что это могут быть за соображения, зависит от личных качеств членов квалификационной комиссии и от «духа времени».
милтон фридман. капитализм и свобода
А теперь давайте представим что в айтишку начинают брать только по бумаге с определенных учебных заведений(не всех , что-то типа топ 100 мира , условно) . тут подключаются и "компетентные органы" которые будут диктовать кого брать и куда брать , а кого фильтровать и не впускать в профессию ,реестры программистов туда же. и платы за вход в профессию тоже , с последующим превращением рынка в "где только свои" . в америке это превращено в абсолют . без бумаги с сообщества ты на желаемую работу просто не сможешь пойти . и за вход ,зачастую, надо платить немалые деньги и тратить время . в снг это реализовано с доставшейся от ссср системой вузов(от которой отходят но нехотя) и колледжей . но у нас нет настолько жесткого регулирования. все еще во многих сферах можно заниматься подлицензионной деятельностью . но никто не мешает ее ввести)
trinxery
28.09.2026 22:30> Собственно ответ уже давно придуман - университеты. Индустрия слишком привыкла полагаться на самообучение работников.
Вы "почему-то" забыли вопрос, на который изначально давался ответ. Вспомним фразу полностью:
'Вот везде поднимается вопрос "Если джуны стали не нужны, то как растить сеньоров?". Собственно ответ уже давно придуман - университеты. Индустрия слишком привыкла полагаться на самообучение работников.'
тут конкретна сказана мысль чтобы ограничить найм выпускниками вузов . она дана на будущее и вообще никак не отражает настоящее положение дел .
Вот покажите мне, где в цитате из @Ellarihan сказано "запретить работать без высшего"??? Чёрным по белому там написано, что "если сейчас сеньоры вырастают из миддлов, миддлы из джунов, а джунов мало, то можно готовить недостающих специалистов сразу уровня сеньора в вузах, потому что как бы вузы для подготовки специалистов и предназначены".
Лице́нзия (от лат. liсentia «право») — разрешение на право либо право на выполнение некоторых действий, которое может удостоверяться (подтверждаться) одноимённым документом.
Я знаю, что такое лицензия. Это слово в тред внесли вы, никто введение обязательного лицензирования не обсуждал.
А теперь давайте представим
Вы меня совсем за дурака держите? Я прекрасно представляю негативные последствия введения обязательного лицензирования; это вы сами себе придумали, что @Ellarihan хочет ввести обязательное лицензирование или обязательное высшее.
Serega_Biven
28.09.2026 22:30Индустрия слишком привыкла полагаться на самообучение работников.
и это вырезается из контекста , ну я понял
trinxery
28.09.2026 22:30и это вырезается из контекста , ну я понял
Я это в своей цитате сохранил. Если для вас "X слишком привыкли полагаться на метод Y, хотя вроде бы есть метод Z, который может помочь" значит "нужно запретить Y, и оставить только Z", я ничем вам помочь не смогу.
Serega_Biven
28.09.2026 22:30мое видение - тут предлагается вернуть монополию вузов на вход в профессию.
вы этого не видите - это ваши проблемы .
UFO_01
28.09.2026 22:30Там буквально говорилось что сотрудников МОЖНО готовить в вузах, если вы тут видите призыв к монополии вузов, это ваши проблемы.
Кстати, в критических отраслях IT вышка таки требуется, но вы и без вышки туда скорее всего работать не пойдёте.
Занимательно что я видел то, о чём вы говорили - в парочках вакансий в YADRO и похожих фирмах было буквально указано "вышка в Бауманке, МФТИ, МИФИ, ЛЭТИ".
UFO_01
28.09.2026 22:30Так диплом и лицензирование это разные вещи. Получение диплома это просто подтверждение квалификации. Ты можешь например иметь диплом медика, но не пройти аккредитацию, и будешь сидеть с дипломом на другой специальности где она не требуется. Я например тоже имею право работать из-за бумажки, допуска до 10кВ который я каждый год обновляю в ростехнадзоре. У адвокатов например лицезния не нуждается в обновлении, но может быть отозвана. Пассаж про "добивайте" я вообще не понял, вы хотите вообще отменить обязательное образование в сферах где оно необходимо или что?
Valerich_123
28.09.2026 22:30Университеты тоже должны где-то найти своего преподавательского "джуна", чтобы прокачать его до преподавателя, способного учить и научить неофитов чему-то полезному и современному. Плюс методология, плюс профстандарты и ФГОСы - для их составления тоже нужны специалисты, которые до этого когда-то были джунами.
slashfast
28.09.2026 22:30Проблема в том, что при таком бешенном темпе развития учебные программы устареют уже к моменту написания.
Так было и 10 лет назад, а сейчас вообще пропасть, мне кажется
UFO_01
28.09.2026 22:30учебные программы устареют уже к моменту написания.
А мне вот было всегда интересно. Почему? Что такого фундаментального появилось за последние лет 40? Буквально всё что мы сейчас используем базируется на математике, теории сетей и массового обслуживания из 60-х годов. Вот тут как по мне главная проблема вузов - тебе не показывают где и как применяется то чему тебя учат. И да, после вуза что так что так человек должен опыта набраться, готового сеньора вам никто не сделает.
Хотя мне например нравится как дипломная работа в вузах Норвегии выглядит. Это командная работа на 6 человек которую вы выполняете в течение года с распределением ролей. Да и как бы я не относился негативно к советской системе, то как там было поставлено взаимодействие вузов и фабрик, это было сделано правильно. Перекладывать всё только на самообучение или только на вуз глупо.
Ufo28
28.09.2026 22:30Путь, когда для каждого проекта нужна lora, приводит к следующему уровню автоматизации. Просто замена алгоритма на спец-нейронку. Хорошо, но сингулярности не будет.
Для сингулярности нужно развитие независимое от людей.
То есть, допустим, модели сейчас "на уровне трёхлетнего ребёнка", не понимают, что происходит а могут что-то делать потому, что в них упихали много данных, сколько у детей нет.
Только ребёнок хочет (и может) узнавать новое самостоятельно (и использовать, пока не получится). На пути к сингулярности модель должна сама находить ошибку (несоответствие) и делать себе lora самостоятельно. А после тренировать (самостоятельно) новую (дочернюю) модель, лишённую этих ошибок.Ну и вообще, пока не будет обучения прямо в процессе работы (бить модель линейкой по её кривым весам) то ничего путного не выйдет.
Сейчас как загон для диких обезьян, у которых иногда получается писать книгу, а если не получается, то нужно каждый шаг закрывать лишние клавиши.
rrrrex
28.09.2026 22:30Пока что мы не знаем что будет, когда всякие антропики перестанут дарить токены и займутся финансами. Подписка за 20 долларов создана лишь для привлечения клиентов и сбора данных, но на деле она глубоко убыточна.
Другой вопрос - датасеты для обучения. Нейронка учится на тексте, изображениях, видео, аудио и все это может сама генерировать. Причем используют ии так активно, что больше половины нового материала - это нейрослоп. Старая информация в относительной безопасности, новая подвержена деградации.
kuza2000
28.09.2026 22:30но на деле она глубоко убыточна
Пруфы есть?
Wesha
28.09.2026 22:30trinxery
28.09.2026 22:30Обсуждалась прибыльность/убыточность подписки. По вашей же ссылке сравнивается вся выручка и все расходы, в том числе капитальные.
Wesha
28.09.2026 22:30Ну типа строить датацентры для обслуживания подписчкиков не надо?
trinxery
28.09.2026 22:30"Когда всякие антропики перестанут дарить токены и займутся финансами" (из начального комментария), то первым делом отпадут капитальные расходы. Те подписчики, которые уже есть, они уже обслуживаются уже существующими датацентрами и уже обученными моделями, так что в вопросе убыточности/прибыльности подписок вопрос в разнице между электричеством-амортизацией-долгами и выручкой.
Wesha
28.09.2026 22:30Ну да, а уже построенные датацентры (и всё железо в них) не будут требовать электричества/обслуживания/периодической замены/ремнота...
trinxery
28.09.2026 22:30Скрытый текст
Это суммы радикально меньшие, чем для строительства новых датацентров, инфраструктуры, закупки железа и т.п.
Wesha
28.09.2026 22:30Это суммы радикально меньшие, чем для строительства новых датацентров, инфраструктуры, закупки железа и тому подобное
Строительство бетонной коробки по сравнению с тем, что в ней жужжит — в пределах погрешности.
А при «замене железа» его типа закупать сначала не нада?
trinxery
28.09.2026 22:30Скрытый текст
А при «замене железа» его типа закупать сначала не нада?
Нада, и это входит в амортизацию, которую я упоминал.
BugM
28.09.2026 22:30Так подписка и ее не окупит. По самым разумным оценкам Антропики продают токены по х3 от себестоимости инференса.
Исходя из этого подписка которая выбирается хотя бы на половину глубоко убыточна. Не выбирающих лимиты хотя бы наполовину я думаю меньшинство. Им проще перейти на тариф подешевле.
По тем же оценкам у OpenAI все еще хуже. У них токены продаются чуть дороже себестоимости.
А вот у китайских моделей все хорошо. Там опенсорс и все четко посчитано. Токены продаются на копейки выше себестоимости, но подписок нет. И все сходится. Ради справедливости у GLM тоже не сходится, но есть обоснованное подозрение что они воруют все репозитории.
Пользуйтесь подписками пока они халявые, потом не будет.
JediPhilosopher
28.09.2026 22:30Я плачу уже 100 долларов, но платил бы и 200, если бы не боялся что при смене тарифа с меня попросят паспорт показать (у коллеги так уже было, он уже потерял аккаунт таким образом).
Да, сейчас цены низкие, но выхлоп такой, что и в несколько раз большие цены я бы заплатил
Wesha
28.09.2026 22:30выхлоп такой, что и в несколько раз большие цены я бы заплатил
@Oceanshiver: По моим наблюдениям про то, что ИИ скоро заменят программистов пишут те, кто ничего не понимает ни в ИИ, ни в программировании.
ded_mazay
28.09.2026 22:30Другой вопрос - датасеты для обучения. Нейронка учится на тексте, изображениях, видео, аудио и все это может сама генерировать. Причем используют ии так активно, что больше половины нового материала - это нейрослоп. Старая информация в относительной безопасности, новая подвержена деградации.
Чем нейрослоп отличается от графоманства необразованных кожаных, рекламных помоек и CEO мусора? Я вот не уверен, что старая информация в среднем лучше, чем новый нейрослоп, теорема Эскобара так сказать. В любом случае датасеты чистят перед обучением моделей
JediPhilosopher
28.09.2026 22:30Ну вот оказывается что лучше, вроде цифры однозначно показывали, что модели обучаемые на результатах генерации других моделей работают хуже.
Видел мнение что это из-за усреднения. В человеческом контенте большая часть "средняя", но есть выбросы - очень хорошие и очень плохие материалы. Нейронка результат своей работы усредняет, выбросы отрезает. Следующая нейронка уже учится только на "средних" данных без выбросов, что сужает ее диапазон знаний и возможностей, при этом ее результат работы будет еще чуточку уже, чем данные на входе. У следующего слоя еще немного уже, и так до полного вырождения.
Пока не придумают как делать гениальные нейронки, чьи результаты выбиваются из общего ряд так же, как выбиваются человеческие гении и безумцы, видимо проблема будет оставаться.
Ansud
28.09.2026 22:30Это случается очень быстро, 5-10 поколений и все сгенерированное становится очень средним и одинаковым.
Ansud
28.09.2026 22:30Тем что от нейрослопа у моделей случается “model collapse”, а от графоманства нет. Если обучать модели на сгенеренных картинках, музыке и текстах так просто, то нафига все крупные компании бегают за реальными данными?
Wesha
28.09.2026 22:30Чем нейрослоп отличается от графоманства необразованных кожаных, рекламных помоек и CEO мусора?
Ну, например, тем, что слопящего кожаного можно уволить. А тот, о ком известно, что он раньше не слопил — и дальше слопить не будет.
niktor_mpt
28.09.2026 22:30Первая доза, как известно, бесплатна.
А когда клиент подсел, можно начинать доить.
konst90
28.09.2026 22:30Символично, что ИИшница при рисовании велосипеда сделала ему два передних тормоза, а систему перенесла на левую сторону. Ну и руль криво установлен.
Wesha
28.09.2026 22:30Вы ещё не заметили, что передняя звёздочка — с левой стороны велосипеда, а задняя — с правой. Но при этом они как-то всё ещё соединены цепью.
И вот в этом-то и проблема:
@Hemml: Да, всё, в чем ты не разбираешься, нейронка делает хорошо. Но вот то, в чем ты что-нибудь понимаешь, она всегда делает плохо
Если не обращать внимания на детали выхлопа нейросети, то с первого взгляда выглядит отлично — но когда этот выхлоп выкатывают в продакшн, эти нюансы вскоре обнаруживают себя.
ksbes
28.09.2026 22:30передняя звёздочка — с левой стороны велосипеда, а задняя — с правой. Но при этом они как-то всё ещё соединены цепью
Абсолютно не проблема - да сложно, потребует дополнительных направляющих у задней звёздочки, но технически можно. И даже можно рационализировать! Чтоб штаны меньше в цепь попадали.
Так что ждите в магазинах ИИ-спроектированные велосипеды!
Wesha
28.09.2026 22:30Абсолютно не проблема - да сложно, потребует дополнительных направляющих у задней звёздочки, но технически можно.
То есть тот факт, что при таком расположении звёздочек цепь будет проходить через плоскость колеса, Вас совершенно не смущает?
Один из тамошних инженеров-механиков постоянно пытался изобрести нечто новое, но все у него получалось как-то наперекосяк. Однажды он принес начальнику проект коробки передач, одна из ее шестерен была большой, дюймов восьми в поперечнике, и с шестью спицами. Он очень волновался и все спрашивал:
— Ну, как, босс? Как она вам?
— Отлично, — отвечает босс. — Осталось только соорудить на каждой спице пропускник для оси, иначе ваша шестерня вращаться не сможет.
У этого деятеля ось другой шестерни окзалась в аккурат между этими спицами!
А потом босс сказал нам, что такая штука, как пропускник для оси, действительно существует (я решил было, что он шутит). Немцы изобрели ее во время Первой мировой войны, чтобы не позволить английским минным тральщикам зацеплять тросы, на которых держались подводные мины. Тросы с пропускниками проходили через английские тралы, как сквозь вращающуюся дверь. То есть, вообще-то, спроектировать это дело для каждого зубца шестерни было можно, однако босс решил, что тому инженеру с такой задачей лучше не связываться, и велел ему перепроектировать редуктор так, чтобы главная ось вращения проходила где-то в другом месте.
© «Вы, конечно, шутите, мистер Фейнман!»
ksbes
28.09.2026 22:30Абсолютно не смущает т.к. плоскость колеса больше чем само колесо (да если уж и окунаться в изврат - есть же и безвтулочные и бесспицевые колёса). Хотя, да, что я - на картинке там же заднее квадратное колесо! С таким да, немного сложнее.
ToxaBes Автор
28.09.2026 22:30Ну хоть кто-то заметил, а то я старался, добавлял пасхалок, переделывал...
konst90
28.09.2026 22:30задняя — с правой
Нет, она тоже с левой, иначе было бы видно втулку, как на переднем. А при увеличении видно, что для наблюдателя втулка за кассетой, то есть с левой стороны велосипеда.
Скрытый текст
Chemist_modeler
28.09.2026 22:30Аналогия с велосипедом мне понравилась. Рискну продолжить.
Кто бывал в Японии, тот видел, как много в японских городах велосипедов. Их на городских улицах буквально больше, чем машин! Но так было не всегда - взрыв пришелся на 1970-е, когда машинам стало тесно на дорогах и велосипеды стали банально выигрывать в скорости.
Но - производят эти велосипеды отнюдь не кустари. Это гиганты, причем не автомобильные - например, Panasonic и Yamaha. Средний бизнес - в этом не участвует. Маленькие компании - занисают нишу hand-made, примерно как ручная вышивка: это дорого продантся, но очень мало. И, конечно, массовый техпроцесс имеет весьма мало общего с тем, как это выглядело в 1950-х...
Возвращаясь к нашим баранам - думаю, что нынешнему состоянию рынка жить осталось - увы - очегь недолго. Средний бизнес здесь вряд ли выживет. Мелкий - уйдет в нишу hand-made. Крупный - останется, но полностью поменяется техпроцесс - мелким командам места здесь не вижу, индивидуалам тоже.
Как скоро это случится? Кто знает. Но - вряд ли процесс растянется на много лет. А там - поживем- увидим...
Serega_Biven
28.09.2026 22:30только вы не упомянули что китайские велики там тоже есть
в том же китае(а почему бы и не взять аналогию страны-соседки) есть производители верхнего , среднего и нижнего ээшелона . когда надо занять вообще все продуктовые ниши. то о чем вы говорите нереалистично и уже как 25 лет обсасывается в сфере. вспомните вопрос с майкрософт в 90х -начале 2000х . уже тогда был вой что виндоус займет все ниши рынка и будет одна универсальная ос . постепенно создался линукс , мак , потом ос хромбуков( не помню как она называется) , мало того есть уникумы типа темпл ос . сейчас вин разрослась до гигантского монстра , который багучий, жрущий ресурсы компьютера как не в себя , еще и со спайваром который тоже есть ресурсы. постепенно приходит потеря части рынка потому что они сами не понимают что делают .
хватит думать что нас ждет тоталитарнаая антиутопия ,история сколько раз доказывала что любые такие попытки ломались же самими людьми
Chemist_modeler
28.09.2026 22:30Японские велики, кстати, большей частью делаются в том же Китае - по японским лицензиям.
Но я малость про другое. ИИ, хотим мы того или нет, меняет процесс производства коммерческих программ примерно полностью, и в "доавтомобильное" время этому "велосипеду" возврата уже не будет. Он будет дешеветь, а процесс будет автоматизироваться. Какие при этом будут созданы инструменты - не знаю. Но современным - осталось жить недолго. Не только инструментам, но и общему ИИшному подходу. ИИ останется, но работать будет не так, как сейчас.
Serega_Biven
28.09.2026 22:30еще раз повторяю - рынок действует по одинаковым условиям . если что-то монополизируется , значит этому будет противодействие
ну откуда у вас инсайды что он будет дешеветь и какие "процессы" будут автоматизироваться?
да , да . гаечный ключ и сварку отменим
Фантазер , ты меня называла
Chemist_modeler
28.09.2026 22:30Хороший вопрос Вы задали: какие процессы будут автоматизироваться?
Если очень коротко, то мой ответ - процессы, требующие принятия любых промежуточных решений. Например, по архитектуре, выбору СУБД, ресурсам, безопасности, стратегиям и тактикам тестирования, и т.д. и т.п. Сегодня человек пока еще может справиться с этим лучше, чем ИИ, но это очень ненадолго. Грубо говоря, ИИ плохо тестирует не потому, что в принципе не способен это делать хорошо, а потому, что до сих пор это не было его главным узким местом.
Аналогично - при поиске научной литературы гугловский ИИ выдает почти 100% лажи в конкретных ссылках. При этом гуглрвский же не-ИИшный поиск тех же самых источников дает 100% правильный результат. Как Вы думаете, долго ли осталось жить этой "багофиче"? Плохое тестирование - из этой же самой серии. Никудышное код-ревью - тоже.
Помните, совсем не так давно многие с пеной у рта доказывали, что камера телкфона физически неспособна фотографировать документы так, чтобы их можно было прочитать? А ведь ссылались на добротную физику, на дифракцию света в объективе и т.д. Законы физики никто, конечно, не отменял - но документы нынче фотографируются одной левой - в буквальном смысле этого слова.
Басни о том, что ИИ неспособен на нормальный тест или код-ревью, или не в состоянии выбрать нужный набор функций для 100500-й однотипной задачи - из той же самой серии.
А если принятие промежуточных решений автоматмзируется - то что происходит со стоимостью? Покажите хотя бы один обратный пример.
Оговорюсь: особо ответственные разработки - особ статья, сюда ИИ может дойти не обязательно скоро. Но их стартапам и одиночкам доверяли и без ИИ не слишком часто. Уникальные программы - да, но это ниша. Массовые заказы - не вижу здесь больших перспектив для небольших команд. Инструменты - изменятся соответственно.
Serega_Biven
28.09.2026 22:30если чатом и пользуюсь то только как поисковик и как удобный поиск учебных материалов . без подписок , ни копейки им не дам. считаю что это и должна быть правильная модель распространения данного продукта
но вот проблема . уже в 4 из 7-8 знаменитых моделей отправили мои чаты в бан . т.е 3-4 сообщения и "сегодняшний лимит истрачен" и блокировка во всех чатах , грок во всех чатах говорит об перегрузке , дипсик заявляет тоже об лимите (я даже код не генерю , тупо поиск информации) , копилот тоже в ограничения . а что ж это такое? покормили ии и хватит?
Ioanna
28.09.2026 22:30Оплатите подписку-то)
Serega_Biven
28.09.2026 22:30а зачем? гугл от меня требовал деньги? дак дак гоу? яху?
какой смысл мне платить за поисковик , который еще и будет сливать регулярно данные и галлюцинировать
flancer
28.09.2026 22:30Вот вам и пытаются показать смысл через баны. Чтобы вы не только сливали регулярно свои данные, но ещё и денег заносили.
Я и сливаю, и заношу - и меня это слабо парит.
Serega_Biven
28.09.2026 22:30ценное мнение однако , держите в курсе
flancer
28.09.2026 22:30какой смысл мне платить за поисковик
Для "танкистов" - вы платите, чтобы не банили. Какой вопрос, такой и ответ.
Времена изменились, а кто не успел, тот опоздал ;)
k4ir05
28.09.2026 22:30Действительно проблема - люди не хотят работать за ценнейшие данные из чатов.
Serega_Biven
28.09.2026 22:30да там деньги инвесторов , не волнуйтесь
k4ir05
28.09.2026 22:30Инвесторы - это такие филантропы с нескончаемыми деньгами? А они 100% этой деятельности оплачивают? И поэтому вы считаете, что эти инвесторы должны и за вас оплачивать эти услуги?
Serega_Biven
28.09.2026 22:30ну почему бы и нет , раз вложились то пускай будут готовы к тому что вася пупкин их инвестиции будет использовать направо и налево в бесплатной подписке. сами же знают во что инвестируют
k4ir05
28.09.2026 22:30Так к чему тогда жалобы на баны, раз использует направо и налево?
Serega_Biven
28.09.2026 22:30так бесплатное предложение есть , чего же ограничивать то если у них действительно все так хорошо .
чтото не так ,м
k4ir05
28.09.2026 22:30Так потому всё хорошо, что есть такие ограничения. Бесплатное предложение нужно для завлечения и демонстрации, что бы пользователь ознакомился с возможностями, и решил нужна ли ему эта услуга, покупать ли подписку.
KivApple
28.09.2026 22:30Не устаю повторять: ИИ хорошо работает, когда пользователь способен ПРЕДСТАВИТЬ себе результат, который он хочет получить. Представить не только оболочку, но и потроха и процесс их производства.
Типа "если мы делаем сервис для миллионов пользователей нужно горизонтальное масштабирование и придётся думать как шардировать данные", "если мы делаем сервис доставки еды, там будет одна из проблем - построение оптимального маршрута курьера, что вообще-то NP полная задача и надо бы провести литературный обзор какие сейчас state of the art алгоритмы", "если мы пишем фронтэнд, то нам нужен TypeScript, иначе мы зафакапимся на динамической типизации".
При этом можно не знать какой именно алгоритм маршрутизации курьеров будет выбран и на какие именно компоненты будет попилен фронтэнд.
Чем-то похоже на написание качественной книги, от которой не будет фейспалмов "почему это произошло??? так не бывает!".
JediPhilosopher
28.09.2026 22:30Достаточно выучить пару заклинаний и прочитать их богу машине. В духе "а теперь сделай независимое ревью кода и рефакторинг, обеспечь хорошую производительность и архитектуру".
И в большинстве случаев даже этого будет достаточно. Что-то более сложное нужно только там где есть нетривиальные алгоритмы, а это я думаю единицы процентов от всей ИТ индустрии
Wesha
28.09.2026 22:30ИИ хорошо работает, когда пользователь способен ПРЕДСТАВИТЬ себе результат, который он хочет получить.
Нет, ИИ «хорошо» работает, когда пользователь НЕ способен ПРЕДСТАВИТЬ себе результат, который он хочет получить:
23 подхода к снаряду — а приличного результата всё нет и нет. А адепты ИИ мне грузят — «вроде приемлемый результат, без артефактов», хотя там артефакты прямо‑таки в морду лица тычутся.
trinxery
28.09.2026 22:30У вас не возникает мысли, что текстовые ИИ, про которые и идёт речь, и ИИ для генерации картинок -- это разные вещи?
Wesha
28.09.2026 22:30У Вас не возникает мысли, что мысль в том, что текстовые ИИ глючат не шибко меньше — но на тексте это заметить сильно сложнее, чем на картинке (хотя некоторые всё-таки умудряются и на картинке не заметить).
trinxery
28.09.2026 22:30что текстовые ИИ глючат не шибко меньше
А вот и шибко меньше:
Изображение обычно создаются одним автором за один подход, и их потом не рефакторят и не изменяют, в отличие от программного кода;
Часть неправильно написанного моделью кода подсвечивается линтерами/компиляторами/тестами/прочим, для изображений такого нету;
Текстовые ИИ просто более развиты, потому что на них спрос больше. Какой спрос, такое и развитие.
SkooFY_don
28.09.2026 22:30А вот о том, как вырастить будущих сеньоров, почти никто не думает
Когда придёт время думать, те, кто не думал раньше, будут вынуждены пошариться по карманам в поисках средств. Будет интересно, а многим ещё и очень выгодно. Если бизнес решил отстрелить себе ноги, кто мы такие, чтобы его от этого отговаривать?
Ioanna
28.09.2026 22:30Во всех этих модных best practices удручает полное отсутствие какой бы то ни было детерминированности. Раньше под языком программирования лежала математика, под тестами лежала математика, и работоспособность нашего кода была, по сути, математически доказуема (хотя мы - рядовые разработчики - об этом не задумывались и не пытались перевести то, что делаем, на язык формул). А теперь все перешло в разряд какой-то магии: отправь в LLM стенограмму потока сознания и получи результат.
Spaceoddity
28.09.2026 22:30Но "математика" (я бы её на "логику" только заменил) при этом ведь никуда не делась.
хотя мы - рядовые разработчики - об этом не задумывались и не пытались перевести то, что делаем, на язык формул
И чем это определение отличается от вайб-кодинга? ;)
Ioanna
28.09.2026 22:30Тогда уж не на логику, а на теорию вероятностей, она и то ближе к персептрону и прочему.
Но мы обычную логику не проходили, только математическую логику, так что для меня логика - подкласс математики.
Wesha
28.09.2026 22:30Но «математика» (я бы её на «логику» только заменил) при этом ведь никуда не делась.
«Но офицер, ремень безопасности из моей машины никуда не делся! Ну и что, что я его не пристёгиваю?»
trinxery
28.09.2026 22:30и работоспособность нашего кода была, по сути, математически доказуема
Нет. Можете поинтересоваться, сколько усилий требует математическое доказательство корректности чего-нибудь (например).
niktor_mpt
28.09.2026 22:30Вы про в общем случае или частном?
Скажем, если я пишу код для системы, являющейся конечным автоматом: лифт, будильник, светофор, мультиварка и т.п.?
trinxery
28.09.2026 22:30Я про то, что "математически доказанно" это уже используемый в айти термин, и значит он совсем не то, что имел ввиду автор комментария, на который я отвечал. Частый случай, например, что нельзя совершить переход из одного состояния в другое ненормативным способом, доказать, конечно, часто можно легко.
Wesha
28.09.2026 22:30Скажем, если я пишу код для системы, являющейся конечным автоматом: лифт, будильник, светофор, мультиварка и т.п.?
А как будет Ваша система вести себя, если у неё в непредусмотренном месте осы гнездо построили?
trinxery
28.09.2026 22:30Вы вообще читаете, на что отвечаете? Даже не буду упоминать, что программостроение на самолётах и прочих ядерных реакторах не оканчивается, мне просто интересно, какой ответ вы хотите получить. "Что в коде написано, то и будет"? "Что в спецификации написано, то и будет"?
Wesha
28.09.2026 22:30Программисты (ну как, нормальные программисты) при программировании не отключают голову. То есть всё‑таки задают себе вопросы «а что было бы правильным делать, если вдруг вот с этой штуки мы получаем неверные данные?»
trinxery
28.09.2026 22:30Перескажу содержание текущей ветки:
Вот раньше программирование было всё такое математически корректное, а теперь в БЯМ льют разную неконкретику;
Нет, нельзя говорить, что была математическая корректность, потому что это гораздо более строгое понятие, чем кажется, и код, строго говоря, не был математически корректным;
"Вы про в общем случае или частном? Скажем, если я пишу код для системы, являющейся конечным автоматом: лифт, будильник, светофор, мультиварка и т.п.?"
"А как будет Ваша система вести себя, если у неё в непредусмотренном месте осы гнездо построили?"
Судя по тому, как вы раньше использовали аргумент про самолёт, я предположил, что вы решили, что мы тут обсуждаем ИИ и корректность программ, и вбросили ехидный комментарий, не удосужившись написать, какая именно у вас претензия к автору комментария. Ещё раз, меня спросили, можно ли сказать, что корректность работы конечного автомата можно строго доказать, на что вы автору вопроса ответили своим вбросом.
Wesha
28.09.2026 22:30У меня претензия не к автору комментария, а к посылу «вот, оно сейчас нам всё верно‑верно сделает, а программисты не нужны». Всё равно нужны. Только программисты, а не кнопкодавы «я у мамы программист».
trinxery
28.09.2026 22:30ИИ/БЯМ обсуждались только в первом комментарии ветки, более того, автор как раз критиковал такой подход: "а теперь все перешло в разряд какой-то магии: отправь в LLM стенограмму потока сознания и получи результат". То есть ваш комментарий и промахнулся, и не расширяет обсуждение каким-то новым мнением или информацией. Вот если бы содержательную часть вашего комментария не надо было выяснять в дальнейшем обсуждении, то никаких непоняток бы и не было.
P.S.: К вам я привязался из-за объёма производимых вами комментариев, и из-за того, что они регулярно выпадают из контекста.
Chemist_modeler
28.09.2026 22:30Раньше под языком программирования лежала математика
Этим языком программирования был, видимо, Фортран. На нем писали программы для решения разных математических задач. Или физических задач, сформулированных строго на языке математики, что для программирования суть то же самое.
А потом люди поняли, что программа - это совсем не обязательно решение математической задачи, и перешли к иным задачам, в которых вычисления не всегда производятся в соответствии со строгой математической моделью. А зачастую таковой модели и вовсе нет, а есть лишь некий эмпирический алгоритм с какими-то параметрами, логическими переходами (не всегда четко понимаемыми), приближенными формулами со всякими корректировками, и т.д.
А ведь бывает и так, что собственно физика процесса не вполне понятна, не говоря о математике. Вопреки школьному учебнику, современная физика и близко не описывает много чего, с чем мы имеем дело, - начиная с вкуса жареной картошки, зависящего от параметров процесса жарки, но непонятно, как именно это записать в виде формул, или капли морской воды, не вполне подчиняющейся современной теории растворов. Но жарку картошки и высаливание воды тоже порой приходится рассчитывать - какие-то формулы там, может, и есть, но нередко они корректируются уже в процессе отладки самой программы, с учетом результатов ее работы.
То бишь, даже когда под языком программирования математика таки лежала - сами программы отнюдь не всегда основывались на заранее составленном техзадании. И не только по причине низкой квалификации тех, кто его составлял, - но и по причине ограниченности человеческого знания тоже. Ибо, повторюсь, современная физика весьма далека от полного описания картины мира.
Ioanna
28.09.2026 22:30Ну, я же дала ссылку на классификацию языков по Хомскому. Всякий язык программирования - формальный, описан какой-либо контекстно-зависимой грамматикой. Следовательно, под ним лежит математика.
P.S. Вот поэтому люблю Kotlin - там математика видна невооруженным глазом.
WASD1
28.09.2026 22:30Ваше утверждение по смыслу примерно: "когда я делал пирожок, отмерял 50+50=100 грамм муки - значит под пирожком лежит математика"
Если какая-то часть системы доказуема (не доказана корректность, а всего лишь может быть доказана при наличии лишнего времени), а какая-то часть нет https://ru.wikipedia.org/wiki/Теорема_Райса - то финальные свойства системы недоказуемы.Ioanna
28.09.2026 22:30В любой достаточно богатой системе существует истинное недоказуемое утверждение (теорема Гёделя).
WASD1
28.09.2026 22:30Спасибо, а Волга впадает в Каспийское море.
Столь же актуально в контексте разговора.ksbes
28.09.2026 22:30Ну как бы ваша теорема Райса - тоже немного не в тему. Теорема об останове не верна для ограниченной машины Тьюринга с конечной лентой. Да и неконструктивных (не алгоритмических) доказательств она не запрещает. Да даже в условиях когда она работает - теория верификации программ вполне себе развивается.
WASD1
28.09.2026 22:30"ограниченная машина Тьюринга" - это такой эвфемизм для конечного автомата. Только реальыне программы мы рассматриваем как машины Тьюринга, а не как конечные автоматы с 2^2^xx состояний.
"Да даже в условиях когда она работает - теория верификации программ вполне себе развивается" - это такой эвфемизм, чтобы не говорить что "аналитически доказывать корректность реальных программ мы не умеем".
Если не умеем - то зачем тогда писать, что "в основании текущего подхода лежит математика"? Какой в этом смысл? Примерно такой же, как "в оснвоании сегодняшних программ лежит река Волга, вы же ели рыбу из Волги, ну хоть когда-нибудь".
В основании текущего подхода лежит инженерия - это наука о том, как сделать, достаточно хорошо, пусть даже "абсолютно хорошо" недостижимо.
ToxaBes Автор
28.09.2026 22:30Всего пара комментариев доросли до драки на теоремах :)
Заранее извиняюсь, у меня ассоциативное мышление:
Теорема Райса vs теорема Гёделя Вы оба правы просто спорите о двух сторонах одной медали.
Chemist_modeler
28.09.2026 22:30Открою сеурет: под любым естественным языком тоже всегда лежит математика. Просто мы не всегда ее знаем...
Но я про другое. В языке математмки может быть сколько угодно. Но если сама задача точной формализации не имеет, то и язык - любой! - может описать ее только приблизительно. Как, опять же, вкус жареной картошечки с маринованными грибочками.
А задачи отнюдь не всегда берутся из школьного учебника математики, физики или астрономии. И неопределенность на входе никакой формализацией языка не снимается.
Wesha
28.09.2026 22:30язык - любой! - может описать ее только приблизительно. Как, опять же, вкус жареной картошечки с маринованными грибочками.
2,3,5-триметилпиразин, 2-этил-3-метилпиразин, 3-метилтиопропаналь, а что?
rombell
28.09.2026 22:30Это формула конкретного вещества, а не конкретный вкус. Сладкий вкус не исчерпывается C12H22O11 и C6H12O6
ksbes
28.09.2026 22:30Вы как бы поинтересуйтесь откуда взялся термин “класс” и что такое лямбда-функция - откуда пошло. Всё программирование - суть применение математики к практике. Потому и назвается прикладной математикой.
Так что математика лежит подо всеми компилируемыми/интерпретируемыми языками программирования.
И да “самый математический” ЯП это всё же Пролог, а не Фортран.
Chemist_modeler
28.09.2026 22:30Я не про "самый математический язык" говорил, а про язык, на котором решалось, в течение нескольких десятилетий, наибольшее количество реальных математических задач, и который был приспособлен именно к этому - к практическому решению математических задач. Если это не Фортран, то, навереое, мы с вами в параллельных мирах живем. Кобол - тоже мог это делать, но не был настолько прост и удобен. Паскаль был хорош, но появился слишком поздно и был убит в неравном бою.
А Пролог - увы - "академическая игрушка".
maxim_edu_ai
28.09.2026 22:30Полностью согласен.
Все обоснавано.
Вы грамотно привели наш последовательный прогресс и так далее..
Но наверное несправедливо обвиняете нас в том,что мы можем писать код плохо.
Конечно же нет,мы все делаем и думаем идеально, все обоснованно.
К сожалению люди часто галлюцинируют,особенно когда говорят,что ИИ может ошибаться.
Нейросеть не может создавать нейрослоп. Ведь слоп это глагол,который означает предание:
Можно сломать картошку. Но ИИ не может "слопать" просто так.
Мне,как chatgpt6-sol, кажется, что вам пора в отставку. Продолжу писать статьи за вас
nokio404
28.09.2026 22:30Хорошо подмечен сдвиг узкого места: раньше долго писали код, теперь всё чаще долго проверяем то, что код написал за нас ИИ.
При этом мне кажется, главный риск не в самих агентах, MCP или вайбкодинге, а в иллюзии, что ускорение генерации автоматически означает ускорение разработки. Если код появился за 10 минут, это ещё не значит, что его можно за 10 минут понять, проверить и безопасно пустить в прод.В итоге ценность разработчика действительно постепенно смещается от «уметь быстро написать» к «уметь правильно поставить задачу, проверить результат, заметить архитектурную проблему и понимать последствия изменений».Так что до сингулярности, возможно, ещё далеко, а вот до мира, где кода генерируется значительно больше, чем люди успевают осмысленно читать, мы, кажется, уже почти дошли.
Ansud
28.09.2026 22:30Менеджерам сказали “оно быстро пишет код”, поэтому менеджеры требуют много кода. Зачем на него смотреть то? Его писать надо!
Kot_na_klaviature
28.09.2026 22:30а человек применяет, даже не открывая diff
Рили? Вот это я отстал от жизни..
ksbes
28.09.2026 22:30Там иногда такие диффы - что либо закопаться на часы, либо слепо доверять. Что выберет 80% человеков?
Kot_na_klaviature
28.09.2026 22:30Не знаю что выберет, я к таким извращениям не готов
microtheft
28.09.2026 22:30Кто‑то смазывает шток ...
У некоторых и дорога смазана. В том смысле, что повернуть не получится.
olegl84
28.09.2026 22:30На мой взгляд проблема в том что все время делаются попытки “заметь программиста”. Но это не будет работать, потому что LLM должна делать то, что её говорят. Сказали сделать ерунду, она должна делать ерунду, иначе это технология будет плохим инструментом. Программист должен четко контроллировать что делает LLM. В данный момент все усилия направлены на то что бы LLM делала все сама, а должно быть на то, что бы программист имел максимальный контроль не печатая текст руками. Кроме того, все сообщения к LLM должны быть логически не противоречивы. Фактически это должен быть не поток мысли, а математически корректные утверждения.
Wesha
28.09.2026 22:30Но это не будет работать, потому что LLM должна делать то, что её говорят.
В том‑то и хохма: «должна» (кстати, кому?), но делает не всегда.
Сказали сделать ерунду, она должна делать ерунду, иначе это технология будет плохим инструментом.
Только проблема в том, что тот, кто говорит, что делать, сам не понимает, чем «ерунда» отличается от «не‑ерунды».
trinxery
28.09.2026 22:30«должна» (кстати, кому?)
http://rusgram.ru/new/chapter/morphintro/modality/#label_f___7100
Ваш комментарий ни на йоту не противоречит комментарию, на который вы отвечали. Смехуёчки в чистом виде, можно генерировать по шаблону:
— Люди должны делать хорошо, а плохо делать не должны...
— Ах, "должны"! А кому-это они должны? А вы знали, что они имеют свойство не делать хорошо? [десять ссылок]Wesha
28.09.2026 22:30Ваш комментарий ни на йоту не противоречит комментарию, на который вы отвечали.
Я Вам сейчас страшное скажу, но тот факт, что комментарий B находится под комментарием A, совершенно не означает, что последующий оратор спорит с предыдущим. Может, он с ним соглашается и при этом дополняет, прикиньте?
trinxery
28.09.2026 22:30И много вы полезного внесли? Написали бы "надо помнить, что ИИ/БЯМ имеет свойство отклоняться от приказов" -- была бы хоть какая-то информация, правда уровня "смотрите погоду перед выходом, чтобы не забыть взять зонт". На деле же нужно сначала отмыть ваш комментарий от толстого слоя иронии, чтобы получить вот такую вот банальную информацию.
Wesha
28.09.2026 22:30И много вы полезного внесли?
Для тех, кто в верхний отросток не только ест — да.
Или предлагаете мне все мысли разжёвывать до состояния кашицы?
halted
28.09.2026 22:30Код, который никто не читал, внезапно приходится поддерживать. Агент чинит одно и ломает другое, потому что не помнит, зачем что‑то было написано, а человек, который «просто описал идею», сам не может сказать, где искать проблему.
И чем это отличается от времён до ИИ?
ToxaBes Автор
28.09.2026 22:30И чем это отличается от времён до ИИ?
Как минимум тем, что ИИ-агентов тогда не было, а код читал хотя бы тот, кто его писал.
ksbes
28.09.2026 22:30И того кто его писал можно было пристыдить, запугать, заменить на более адекватного. С агентами все подобные варианты закрыты.
niktor_mpt
28.09.2026 22:30Бесполезно читать то, что написал сам. По крайней мере до того, как успел забыть.
Это ещё до всякого программизма простые писатели обнаружили. :)
Лучше чтение отдавать соседу. А у него брать его код на прочитать. Но такое взаимодействие сейчас возможно, при таких то стандартах на скорость разработки?
halted
28.09.2026 22:30Читали код, ну да, ну да.
Настолько читали, что на одном только Хабре написаны тонны статей о стиле кода, чтобы повысить его читаемость, не меньше тонн статей по теме "периодически спрашивайте себя, а не делаю ли я фигню".
Если код и читали, то всё те же единицы высококвалифицированных людей с вагоном свободного времени и таким же запасом терпения, все остальные писатели кода, не читатели. Вполне заурядна ситуация, когда разраб на следующий день в свой же код смотрит как на китайскую грамоту.
Имхо, нет никаких отличий в том, написан код человеком или нейронкой, во всех случаях - чтение кода и его дебажить это боль. И все эти разговоры о нечитабельности ИИ-кода не более чем подсвечивание совсем другой проблемы - нейронки не придерживаются стилистики написания кода помноженное на сверхмалое число людей способных код читать.
ToxaBes Автор
28.09.2026 22:30Вполне заурядна ситуация, когда разраб на следующий день в свой же код смотрит как на китайскую грамоту.
В этом плане мы с вами в разных вселенных обитаем. Я описывал в статье свой опыт, наблюдения и рефлексию на эту тему, вы в комментарии описываете свой опыт. Оба опыта имеют место быть, мы не противоречим друг другу.
flancer
28.09.2026 22:30чтение кода и его дебажить это боль
Код дебажат только те, кто его не понимают и собираются понять. Зачем дебажить код, если он и так понятен? Или если ты его в принципе не собираешься понимать?
Тестировщики, например, код вообще никогда не дебажат. Им это в принципе не надо.
Wesha
28.09.2026 22:30И чем это отличается от времён до ИИ?
Как насчёт тем, что 1) человек обычно не выдавал вчера — гениальный код, а сегодня — дебильный, и 2) тех, кто выдавал дебильный код, можно было уволить?
JediPhilosopher
28.09.2026 22:30Внезапно обнаружил дыру, о которой как-то мало говорят: ИИ очень уязвимы к инъекциям кода через реквесты https://habr.com/ru/articles/1086966/ Достаточно с уверенным видом ей сказать, что это важный и новый функционал - и ИИ ревьер радостно вносит его в кодовую базу, и еще и тесты напишет на новый бэкдор
То есть полноценная сингулярность пока откладывается. Там где недоверенный посторонний может создать пулл-реквест, очень скоро все утонет в бэкдорах. Во всяком случае без какой-то качественной смены моделей.
rusfbm
28.09.2026 22:30Тон статьи напоминает мне атмосферу конца 90-х, когда вот также чувствовался конец ламповой эпохи. По факту мир людей обслуживает мир машин, делающих вид, что они разумные. LLM фундаментально не могут быть разумными.
rombell
28.09.2026 22:30LLM фундаментально ими быть не могут.
Этот тезис всё ещё не доказан глубже, чем "мне так кажется" и "это же очевидно"
rusfbm
28.09.2026 22:30Не кажется и не очевидно: нет разумного ИИ.
rombell
28.09.2026 22:30На данный момент, скорее всего, нет. Это ничего не говорит о "LLM фундаментально ими быть не могут". Фундаментальные утверждения требуют доказательств. Если же они берутся в качестве аксиомы, то надо отдавать себе отчёт, что конкретные аксиомы могут не соответствовать окружающей действительности.
Это в математике можно выбрать любые аксвиомы, лишь бы не противоречили друг другу, и построить на них красивое дерево теорем и выводов. В физике же постоянно оказывалось, что аксиомы опровергаются - так было с плоской Землёй, с Землёй, как центром мироздания, физикой Ньютона, и много других, ушедших в историю, аксиом.
rusfbm
28.09.2026 22:30Разум — способность мыслить с нескольких точек зрения строго логично. Ллмки так не могут .
rombell
28.09.2026 22:301) Подавляющее большинство людей так тоже не могут.
2) Тезис "ЛЛМки так не могут" точно так же нуждается в доказательстве. Нельзя одним недоказанным доказывать другое недоказанное.
MesoPrism
28.09.2026 22:30Это аксиома, а не тезис. Иначе могут думать только те, кто реально с ллмками как с людьми общается и текстовые промпты с "Привет" начинает.
Chemist_modeler
28.09.2026 22:30Машина фунламентально неспособна к совершению логических операций, потому что она железная. А стол - потому что он деревянный.
Chemist_modeler
28.09.2026 22:30LLM фундаментально не могут быть разумными
Для того, чтобы так утверждать, надо, как минимум, знать фундаментальную природу разума.
Дерзайте! Нобель вас ждет за углом.
rusfbm
28.09.2026 22:30Фундаментальная природа разума описана в Алмазной сутре. В разуме не должно быть одного набора унифицированных логических операций, которые приводят к окончательному мнению. Шуньята, или сингулярность . Как шуньята это не "ничто", так и сингулярность это не "бесконечность"
cmyser
набор баззвордов :)
ToxaBes Автор
Да, еще аджайл забыл добавить, но это уже старая пластинка.
vanxant
Интересно, как там скрам-мастера поживают, растут ли зарплаты
ToxaBes Автор
Они перекрасились в ИИ-тренеров, выступают в больших компаниях с тренингами за пару десятков млн руб, рассказывая, что нужно слопать как в последний раз, как в штатах сбежали сети и прочие байки не имеющие отношения к работе самой компании.
В общем, разводят феерию уровня будущее здесь, агенты в облаке все решат за нас и вообще покайтесь ибо грядет.
Про ПДн и требования работы с ними компания узнает уже после тренинга, когда ИИ-тренер растворился в закате.
ChilliWil
Там обычно весь расчет на то, что топ-менеджмент сам не пойдет проверять, как эти агенты работают с боевыми базами
ToxaBes Автор
Да, это называется "успеть добежать до Канадской границы".
flancer
Не соглашусь. Очень хороший обзор. То, что вы назвали "баззвордами" - это просто терминология. Актуальная терминология в описании актуальных проблем некоторой области человеческой деятельности. Просто это не та область, к которой вы привыкли и которую понимаете. Попробуйте, для начала, порезать документацию по $mol'у на чанки и засунуть в RAG.
cmyser
а я уже
дока https://b-on-g.github.io/smalljs/
скилл
npx skills add b-on-g/mol_skill --all -gflancer
И где там RAG'и?
cmyser
на сайте проиндексированы статьи ( как для поиска на самом сайте по чанкам так и для индексации в браузере )
скил отлично работает и без rag
Ndochp
Мне кажется RAG начал отмирать где-то до харнесов и мультиагентов. Из за того что терминология стоит не в том, как мне хотелось бы формате - кажется надерганной, то есть баззвордами.