Язык, который придумали, чтобы программисты стали не нужны, породил профессию, которая жива до сих пор и неплохо оплачивается, а другой язык назвали «структурированным английским», и думали, что на нем сможет писать любой бухгалтер, и он тоже породил новую специальность со своей зарплатной вилкой. А еще была попытка сделать «программирование без программистов к двухтысячному году», но и он дал обратный результат.
Думаю вы узнали COBOL, который по сей день ежедневно эксплуатируется и по разным оценкам стоит за 80% обычных (магазинных) банковских транзакций, а его кодовая база тянет на пару сотен миллиардов строк и до сих пор кормит десятки, если не сотни тысяч разработчиков. Правда, если копнуть эти красивые цифры, почти все они восходят к одному опросу конца девяностых, который потом бесконечно переэкстраполировали на весь мир, так что честнее считать их порядком величины, а не точными данными.
SQL породил особую касту DBA (Database Administrators) и Data Engineers и сегодня человек, который пишет «простые запросы», может легко зарабатывать на уровне мидла, а сам язык стал настолько сложным, что современные диалекты (PostgreSQL, Oracle) — это полноценные языки программирования с процедурной логикой, где можно написать всё что угодно, от генератора фракталов до игрового движка.
Семейство 4GL оказалось «золотой клеткой» и прекрасно работали, пока нужно было сделать типичную форму «ввод‑вывод», но как только требовалась нестандартная бизнес‑логика или интеграция с внешним сервисом, инструмент упирался в свои границы и программистам приходилось дописывать «костыли» на низкоуровневых языках, что превращало разработку в адский коктейль из визуального дизайна и грязных хаков. И вместо исчезновения программистов, 4GL создали «архитекторов корпоративных систем», которые (например, SAP ABAP), стали невероятно дорогими специалистами, и тоже не устранил программирование, а просто переместил его из зоны «универсальных языков» в зону «дорогих и капризных инструментов», привязывающих компанию к конкретному вендору.
Каждые десять‑пятнадцать лет индустрия торжественно объявляет, что писать код руками больше не придётся, продавая новый способ «объяснить машине задачу на нормальном человеческом языке». И каждый раз через несколько лет выясняется, что программистов стало не меньше, а больше, просто теперь они называются иначе. Предположу, что сейчас мы проживаем очередной виток этого цикла, и новое название таким людям будет вайбкодеры, и думаю этому инструменту, уготована та же судьба, что и у предыдущих попыток.
Идея «говорить с машиной на человеческом языке» старше самого понятия компьютера, ей полна фантастика первой половины двадцатого века, от «Метрополиса» Фрица Ланга, которому будет сто лет в обед, с его механическим двойником человека до рассказов, где машине отдают приказы голосом и она послушно их исполняет. Но как только в сороковых появились настоящие вычислительные машины, выяснилось, что проблема не в машине.
Конрад Цузе, который построил Z3 в сорок первом году и придумал один из первых высокоуровневых языков (Plankalkül), сформулировал эту проблему как «опаснее не то, что компьютеры станут как люди, а что люди станут как компьютеры». Многие знакомые мне разработчики на полном серьезе считают языки программирования просто худшей версией английского, не буду с ними спорить... Это не «плохая версия английского», а инструмент с принципиально другими свойствами, не хуже естественного языка и не лучше, просто он про другое.
Что на самом деле делает язык программирования
Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мире и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
Программа, именно программа, код... так не умеет. Каждое из этих решений должно быть где‑то зафиксировано, подперто, написано процедурой, иначе результат получится недетерминированым, а недетерминированная бухгалтерия это уже не бухгалтерия, а повод для разговора с налоговой. И часто даже опытные бухгалтеры не все могли учесть сразу, поэтому короткая фраза на естественном языке разворачивается в вот что‑то такое:
"посчитай премии за квартал" ▼ - за какой именно квартал (календарный? финансовый? от даты найма?) - кто попадает в расчёт (штат? совместители? уволенные в середине?) - база начисления (оклад? оклад + переработки? средний за период?) - формула (процент? фикс? прогрессивная шкала?) - пропорция для неполного квартала (по дням? по месяцам? вообще нет?) - округление (математическое? вниз? до рубля? до копейки?) - валюта и курс (на какую дату берём курс?) - отсутствующие данные (пропустить? считать ноль? упасть с ошибкой?)
Восемь других вопросов из одного, и это я ещё поленился, и каждый вопрос порождает еще вопросы, а когда вопрос перестает порождать другие вопросы, то его можно описать терминами язков программирования.
Язык программирования существует не вопреки этой занудной точности, а ради неё, потому что даёт синтаксис, в котором двусмысленность физически невыразима, и семантику, в которой одна и та же программа всегда означает одно и то же. Программист, который «переводит» пожелание менеджера и бухгалтера в код, на самом деле занят не переводом техзадания в код, но принимает вот эти восемь или больше вопросов и берёт на себя ответственность за ответы.
Просто скажи по‑...
не работает. Есть причины, по которым «естественный язык вместо кода» упирается в потолок, они про нас... человеков, не про тулы, компиляторы, стандартные библиотеки или ограниченность существующих языков программирования, и основная будет в неустранимой двусмысленности естественных языков.
Что вы сделаете если вас попросят «удалить все файлы старше 30 дней в этой папке»? Скорее всего вы просто выделите файлы по дате изменения и удалите их... кажется, что это простое действие, но вы своим опытом ответили на 90% подвопросов. А этих подвопросов очень немало, если начать формализовать базовый вопрос:
— Старше по дате создания или по дате изменения?
— Подпапки и файлы там трогаем?
— А скрытые файлы удаляем?
— А симлинки, ссылку удалим или сам файл?
... и тд
Чтобы убрать двусмысленность, надо либо задать кучу уточняющих вопросов и тем самым фактически написать спецификацию (код программы) словами, либо принять решения за того кто спросил и возможно сделать не то, что он хотел. Языки программирования решают возникающие подвопросы грубой логикой, потому что у каждой конструкции есть ровно одно значение, и mtime никогда внезапно не станет ctime.
Но даже ответив точно на все вопросы и связные вопросы мы упираемся в теорему Райса, довольно скучный математический трактат 1953 года с невесёлым практическим следствием для нас человеков, который звучит так: никакое нетривиальное семантическое свойство программы нельзя проверить алгоритмически в общем случае. Т.е. нельзя автоматически гарантировать, что сгенерированный код делает именно то, что просили, и значит, кто‑то должен проверить, что получилось. А чтобы проверять, надо читать код, а чтобы читать код, нужен формальный язык. Круг замкнулся.
Косвенно вылезает ещё одно свойство, уже не про Райса, а про сам естественный язык. Чем более сложную композицию мы хотим построить, тем хуже она ложится на слова. По‑русски это звучит так, что маленькую функцию описать словами можно, получится даже неплохо и понятно, а вот систему на миллион строк словами описать нельзя, и дело не в том, что слов не хватит, просто естественный язык не композируется, а смысл может накладываться, перетекать от предложения к предложению или зависеть от соседних предложений, захватывая абзацы, а иногда и более крупные участки произведения.
Дальше будет сложный блок, я спрячу его под спойлер, и если лингвистика вам не заходит, можете пролистать до следующего раздела, мысль там повторится через понятные для разработчика вещи и сравнения.
Но если интересно, откуда вообще берётся эта «несводимость к словам», то её давно и подробно описали лингвисты, задолго до всякого ИИ. Они пытались формально записать и посчитать значения обычной человеческой фразы, и обнаружили, что значение предложения нельзя посчитать, глядя только на само предложение. Любой текст на естественном языке не может быть переложен как есть в другие формы представления без потери контекста или значения отдельных частей. Процесс переложения требует выполнения некоторой работы по разделению общего контекста на части, оценка сущностной сложность задачи (essential complexity).
В этом состоянии пребывает программист перед написанием любого кода, называется оно... барабанная дробь... аналитический паралич (иногда еще называют ступор Брукса, как процесс превозмогания той самой essential complexity). Об это состояние спотыкается и идея «просто скажи машине словами» и спущенное сверху «вот тебе ТЗ словами, напиши программу на...», поэтому имеет смысл заглянуть, что там нарыли за сорок лет.
Про Райса, Кампа и DRT
Но у естественного языка есть другая беда, это уже не про Райса. Могут быть сами предложения нелогично устроены, утроены, смазаны да наперёд‑задом напридуманы, перекручены‑перепутаны, шиворот‑навыворот скроены и вкривь да вкось заплетены, так что дорожек не одна в том словеном саду, а что есть расходятся середь фразы, и вы понимаете это, только дочитав до конца, а то и перечитав с начала. Не то, чтобы я был великим лингвистом, но в конце десятых пришлось дописывать матерный фильтр в одном из приложений, а уж в великом и могучем послать по матушке можно было очень разными способами, так что пришлось немного коснуться и этой темы. Но вернемся к нашим баранам... то есть словам.
Пока мы говорим маленькими фразами вроде «удали файл», всё в порядке и фраза целиком помещается в голове и не тянет за собой хвост контекста. Но стоит попробовать описать словами что‑то посложнее, и выясняется, что слова начинают «мешать друг другу» или «зависеть друг от друга» через границы предложений, а переменная в нормальном языке программирования зависеть должна только от четкого контекста, где используется.
Классическая фраза «каждый крестьянин, у которого есть осёл, бьёт его» понятная, любому русско‑говорящему человеку, читается обычно без запинок. А теперь попробуйте разбить её на части и сохранить значение каждой части отдельно, как это делает компилятор с выражением.
«У которого есть осёл» теперь просто утверждает существование осла у некоторого крестьянина, а «бьёт его» отдельно от всего остального вообще непонятно кого бьёт, потому что «его» появляется уже после того, как «осёл» успел мелькнуть и с формально вышел из области видимости.
Человек это не замечает, потому что держит в голове весь кусок целиком и достраивает эту связь на лету, а вот функция, которая вычисляет значение предложения по кусочкам слева направо, как это делает любой нормальный парсер, будет ломаться, либо будет настолько сложной, что о её практическом применении речь уже не идет.
Для программиста это будет переменная, которая объявлена внутри одной функции, а видна она и в следующей, без явной передачи и без global, потому что где‑то зацепили контекст применения. Ни один язык такого не разрешает и области видимости придуманы именно затем, чтобы подобное было невозможно by design, а естественный язык только этим и живёт, у него «осёл» протекает сквозь границу предложения, и это считается нормальным поведением.
Утечку контекста описали лингвисты задолго до всякого ИИ, Ханс Камп в начале восьмидесятых в работе про динамические семантики и почти одновременно Ирен Хайм в диссертации про file change semantics, оба независимо упёрлись в то, что значение предложения нельзя посчитать, не притащив с собой то, что было сказано раньше.
Так родилась дискурсивная теория репрезентации, DRT, чей единственный практический вывод для нас программиста звучит скучно и неприменимо, потому что он в «естественной среде обитания» работает вне DRT. Нельзя формально гарантировать, что кусок текста можно понять в отрыве от соседних кусков, а значит нельзя и требовать от языка, которым вы объясняете машине задачу, чтобы он вёл себя как код, оставаясь при этом естественным языком.
Естесвенная среда программиста это Код, а Код от этой болезни избавлен и вызов calculateAge(1985, 2026) означает одно и то же, воткните вы его в игровой цикл или в отчёт для налоговой, и за ним не тянется невидимый хвост из предыдущих строк, которые меняют его смысл.
И задача программиста собрать Большую Систему из независимых кусков, и это можно только если куски не меняют своё значение от того, куда их поставили, а естественный язык на это принципиально не способен, у него состояние маленького предложения плывёт от размера контекста, в который его засунули. Вряд ли кому‑то понравится, если результат sum(a + b) вдруг начал бы зависеть от длины вызывающей функции.
Надеюсь я вас не сильно утомил этим дискурсом?
Если все еще интересно про DRT
Для начала можно посмотреть статьи Stanford Encyclopedia of Philosophy, “Discourse Representation Theory” и «Dynamic Semantics», они бесплатные, вычитанные специалистами и написаны доступным языком, а не как оригинал Кампа.
Следующий уровень это первоисточники, работа «A Theory of Truth and Semantic Representation» и диссертация Ирен Хайм «The Semantics of Definite and Indefinite Noun Phrases». Их полезно хотя бы полистать, чтобы увидеть, что это не эзотерика, а попытка в до ИИ эпоху построить ту самую «функцию над контекстом».
Вся эта литература действительно трудная, и неспециалисту кажется водяной водой в ведре с водой, но обратите внимание, чего стоило формально описать всего лишь один уровень мысленных представлений (DRS) семантики естественного языка и даже это не закрывает теорию языка целиком.
Современные большие языковые модели на DRT не построены, это статистические трансформеры, а не теория Кампа, поэтому это не фундамент ИИ, а история почему функции над контекстом упираются в такую сложность и терабайты оперативной памяти, чтобы вы могли спросить у модели день рождения Ленина. Ну и для понимания, почему идея сделать естественный язык точным языком спецификаций, выглядит наивно. Это то, что сейчас продают вайбкодеры в качестве мечты «английский вместо кода»
Это уже пробовали. И не раз...
История знает несколько крупных заходов на тему «избавимся от программистов через язык, близкий к английскому». Забавно, что каждый из них давал один и тот же побочный эффект, когда старые программисты оставались, но рождались новые специализации, давая работу новому поколению программистов.
COBOL (1959) создавался с целью дать возможность менеджерам и бизнес‑аналитикам читать и писать программы. Поэтому и синтаксис специально сделали похожим на английские предложения, ADD SALARY TO TOTAL GIVING NEW-TOTAL, читается как почти обычное предложение, ну им в Америках... обычное. В результате появилась профессия COBOL‑программиста, которая жива до сих пор и на которой всё ещё крутится изрядная часть банковских и государственных систем, я об этом сказал в начале статьи. А вот менеджеры, что характерно, писать на нём так и не начали, продолжив писать отчеты руками, в ворде, в виде таблиц и схем, и давать задания, теперь уже COBOL‑разработчикам.
Потом настала эпоха SQL (1974), который изначально назывался SEQUEL, то есть Structured English Query Language, и назван так именно потому, что должен был позволить нетехническим людям задавать вопросы «программе» на почти‑английском. Позже его переименовали в SQL по рекламно‑денежными причинам, но замысел «английский для запросов» остался зашит прямо в имени. Сегодня SQL‑разработчик это отдельная профессия, а «нетехнический человек‑менеджер», встретивший LEFT JOIN с тремя подзапросами и оконной функцией, обычно идёт искать технического, которые понимает этот трехэтажный, великий и могучий.
Потом были 4GL и CASE (Computer‑Aided Software Engineering, восьмидесятые), которые считаются языкам четвёртого поколения «естественных языков программирования», и опять обещали сделать «программирование без программистов». Реклама звучала из каждого утюга и была настолько мощной, что в конце восьмидесятых многие реально опасались эффекта пустых офисов, когда большинство приложений будет создаваться без написания кода, а разработчики массово потянутся к «свободной кассе». Но опять к двухтысячному году индустрия не только не избавилась от программеров, а обзавелась целой плеядой новых высокооплачиваемых специалистов по SAP, Oracle и проприетарным фреймворкам.
Оказалось, что «естественность» 4GL‑систем такая же иллюзия, как COBOL и SQL до него, просто скрывающая за фасадом из визуальных блоков чудовищную сложность конфигурации и непредсказуемое поведение системы. Чем больше CASE‑инструменты пытались автоматизировать написание кода, тем больше времени программисты тратили на борьбу с ограничениями самих этих инструментов, превращаясь из творцов логики в «архитекторов системных интеграций» и в итоге вместо исчезновения разработчиков мы получили их дефицит, а «программирование без программистов» просто переехало в другую плоскость, где теперь вместо написания кода на C++ или Pascal нужно учиться понимать «тайное знание» конкретного вендора, превращая визуальный конструктор в очередной, пусть и очень дорогой, инструмент программирования.
Действительно дорогой, потому что зарплата обычного SAP‑разработчика легко улетает за 100к$ плюс обучение плюс годовые экзамены, а сверху к этому идёт обучение по Xk$ и обязательная ежегодная переаттестация, без которой сертификат просто протухает, и всё это завязано на платную подписку самого вендора.
Потом пришел черед UML и Model‑Driven Architecture (девяностые‑нулевые) с красивой идеей рисования диаграмм, которые будут генерировать код. А на практике UML выжил как средство документации и схема для разработчиков, которые потом код всё равно пишут руками, а иногда рисуют диаграммы уже по написанному коду, что как бы намекает. Потом денег в UML стало сильно меньше, и люди, продававшие Model‑Driven Architecture, в начале десятых массово потянулись в No‑Code и Low‑Code стартапы и конторы, всех видов и размеров, что тоже как бы намекает.
Bubble, Webflow, OutSystems, Mendix начали продавать всем желающим «теперь любой бизнес соберёт себе приложение сам», а на практике это свелось к типовым задачам, формам, CRUD‑интерфейсам и автоматизациям со своим тренерами, школами, инструментами и поддержкой. Но опять же, как только нужна нестандартная логика, интеграция или производительность, приходится городить костыли из блоков внутри платформы, либо нанимать разработчика, который знает именно эту платформу и умеет писать «обычный» код на C++/Java/Swift/выберете свое. То есть появилась, сюрприз... ещё одна специализация. Оказалось, что индустрия, которая продавала мечту «вам больше не нужен разработчик», за небольшой гешефт параллельно продаёт сертификат «я разработчик под эту штуку». Настал черед LLM...
Вы находитесь здесь, и она качественно отличается от предыдущих, потому что впервые инструмент стал работать с произвольным естественным языком, а не с ограниченным DSL в виде блоков, схем, специальных слов. Это очень большой скачок, сравнимый с COBOL/SQL/UML и остальными, тут я говорю безо всякой иронии. Но фундаментальные ограничения в виде двусмысленности, проверяемости и воспроизводимости, никуда не делись, потому что они не про инструмент, а про природу задачи. Кто‑то всё равно должен сформулировать задачу, сформулировать её точно и небольшими порциями, прочитать сгенерированный код и ответить за то, что это код будет делать в проде в три часа ночи.
Если вы оглянитесь назад, на этот список, то увидите, что каждая волна действительно убивала какой‑то пласт ручной работы, но каждая же волна создавала новый пласт работы поверх себя.
Парадокс Джевонса
В 1865 году Уильям Стэнли Джевонс заметил, что чем эффективнее становятся паровые машины и чем меньше угля требуется каждой для выработки единицы работы, тем больше в целом угля стали потреблять, потому что подешевевшая единица работы открыла столько новых применений, что суммарный объем нужной работы вырос.
Каждый раз, когда инструмент делает написание кода дешевле, спрос на софт растёт быстрее, чем падает стоимость его производства. Так число программистов выросло с нескольких тысяч в начале пятидесятых до сотен тысяч в девяностные, миллионов в двухтысячные и десятки миллионов сегодня, и это несмотря на то, что современный разработчик с фреймворком, IDE, пакетным менеджером и поиском...
Иногда по ошибке выдавая за день столько, сколько его коллега из прошлого века писал дни и месяцы, потому что производительность обычного программиста выросла на порядки, и его занятость тоже выросла, потому что дешёвый код сделал выгодными проекты, которые раньше никто бы не начал. Так что если ваша интуиция подсказывает «инструмент делает работу за меня, значит работы станет меньше», то у Джевонса есть для вас плохие новости, которым сто шестьдесят лет.
Что меняется на самом деле
Из всего сказанного однако не следует, что не меняется ничего — меняется, и довольно сильно, просто не в ту сторону, которую мы видим. Уходит низ рынка в виде шаблонного кода, простых CRUD‑систем, верстки и генерации бойлерплейта, вся та работа, где решение уже известны и надо его напечатать. Тут нейронки реально хороши.
Но растёт верх в виде проектирования систем, понимания доменной области, отладки, оптимизации производительности (одна из областей где даже всемогущий Клод плавает аки топор и говноклодит, только успевай комиты реджектить), безопасности, и встраивания компонентов в системы, которые обязаны работать предсказуемо. Кто‑то же должен проверять, что нагенерил генератором генератор генератора? И этот кто‑то должен понимать Систему, нет уже даже не Код... глубже, чем тот, кто его сгенерировал, потому что тот, кто его сгенерировал упирается в теорему Райса и работы Кампа.
Можно сказать, что граница «что умеет машина» сдвигается, и быстро, но граница «что нужно бизнесу» сдвигается ещё быстрее. Программисты в этой среде не исчезают, но у них меняется состав работы, теперь печатать ручками надо меньше, думать больше, и отвечать по‑прежнему за всё.
Бессмертно ли программирование
Языки программирования держит на плаву не синтаксис, привычки разработчика или сопротивление индустрии переменам, хотя сопротивления тоже хватает. Языки программирования решают задачу, для которой естественный язык (в какой бы инструмент его не обернули) в принципе не приспособлен, ни в виде схем, ни в виде md файлов или планов, ни в виде диалога с клодом. Язык программирования однозначно описывает поведение систем, которые обязаны работать предсказуемо.
Пока существуют системы, для которых «примерно правильно» означает потерю прибыли, времени или получение ущерба, а это примерно все банки, вся медицина, вся авиация, и возможно, большинство обычного бизнеса, то будет нужен формальный способ описать, что именно они должны делать. Этот формальный способ и есть язык программирования, как бы он ни выглядел к 2050 году, хоть текстом, хоть голосом, хоть мыслью напрямую из головы.
Машина, которая принимает «я хочу миллион долларов» и волшебным образом исполняет, это все еще фантастический сюжет начала прошлого века, а не инженерная реальность, потому что кому‑то придётся сказать машине, откуда эти деньги, в какой валюте, на какой счёт перевести и что делать, если вместо денег пришли ребятки в коротких пиджаках. Этот кто‑то и есть программист, разве что кроме случая с ребятками, независимо от того, печатает он transfer(amount, account) руками, общается с чатиком или диктует ассистенту голосом.
Я подвожу вас к выводу, что всегда было основой профессии программиста. Vibe coding не убрал необходимость точно формулировать задачу, а всего лишь сдвинул момент, когда вы платите за неточность формулировок. И получается, что проблему опять не решили, и решить её нельзя, но, как обычно, её можно вынести на уровень технического человека, только теперь его будут называть как‑то иначе — Senior Opus Engineer, например, а лет через десять кто‑нибудь на Хабре напишет статью о том, откуда взялась новая профессия со своей зарплатной вилкой. Согласны?
Комментарии (205)
achekalin
27.07.2026 21:47Мне кажется, тут есть ещё один аргумент в пользу вашего вывода, причём он почти не зависит от того, насколько хорош станет следующий Opus.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее. Всё это кто-то должен формализовать.
А затем нужен независимый от генератора слой проверки: тесты, типы, статический анализ, формальные методы, интеграционные стенды — в зависимости от задачи. То есть мало получить программу, нужно ещё иметь способ верифицировать её против требований.
И отсюда, кстати, забавный вывод про языки высокого уровня. Они нужны не только потому, что человек не умеет писать машинный код. Это удобный промежуточный слой, на котором можно выражать структуру системы, ограничения и свойства, о которых можно рассуждать и которые можно проверять. Причём он полезен и самой модели.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Более того, чем больше кода модель способна произвести за час, тем важнее становится этот второй слой. Иначе мы просто получаем очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт.
leen_vl
27.07.2026 21:47Поддержу - продукт кодосодержащий, идентичный натуральному, получать было легко еще во времена индийского кода, а это примерно давно. С тех пор подросло целое поколение. Граница, как и раньше проходит по формализации мышления, что отличает кодера от программиста. А кожаный кодер или песочный - не так уж и важно.
Wesha
27.07.2026 21:47Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация
Классика жеж!
P.S. Нейрокартинка паровоза — низачот.
liriik123
27.07.2026 21:47ну скорее не код, а алгоритм, но да забавно
maisvendoo
27.07.2026 21:47ну скорее не код, а алгоритм
Код есть представление алгоритма, выраженное средствами конкретного языка программирования. Суть эквивалентно
misha_erementchouk
27.07.2026 21:47А еще точнее не алгоритм, а система требований (статья в Википедии так себе, про программирование в ограничениях получше, но микроскопически). Например, из алгоритма "возьми столбец чисел, умножь на вот эту таблицу, пропусти покомпонентно через такую-то функцию и так 20 раз" никак не следует что получится по итогам: чье ухо на вот этой свадебной фотографии или какой ход сделать в данной позиции на шахматной доске?
Javian
27.07.2026 21:47Дружелюбный русский алгоритмический язык, который обеспечивает наглядность (сокр. ДРАКОН)
unC0Rr
27.07.2026 21:47Эти рассуждения вполне применимы и к команде разработчиков. Кто-то принимает десятки решений по каждым мелочам, и как-то нужно решить, получилось ли то, что задумано.
Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Когда задаёшь промпт погонщику агентов, он именно этими вещами и занимается.
очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт
Всё отличие от предыдущего состояния индустрии заключается в словах "очень быстрый".
amazingname
27.07.2026 21:47Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
Эту точную спецификацию тоже пишет LLM интерактивно обсуждая с человеком проблемы и концепт. При этом здесь важна вовсе не детальность описания концепта а принципиальное наличие этого концепта в голове человека и примерное понимание как этот концерт отольются в коде.
Т.е. картина кардинально поменялась. Раньше суть была в том, чтобы сначала вообразить что это будет а затем формализовать проблему до уровня языка программирования.
Теперь задача в том, чтобы вообразить что это будет и шаг за шагом доносить этот образ агенту. При этом образ объясняется а не формализуется. Формализация нужна когда исполнитель глупее постановщика задачи. Но с LLM это не совсем так или совсем не так.
Cerberuser
27.07.2026 21:47Формализация всё равно нужна. Просто в случае с LLM (как и в случае с диалогом “заказчик-тимлид”) её можно проводить итерационно, а компилятору/интерпретатору надо скармливать уже готовую.
LemeRus
27.07.2026 21:47Т.е. картина кардинально поменялась, теперь суть в том, чтобы сначала вообразить что это будет а затем формализовать проблему до уровня большой языковой модели?
k4ir05
27.07.2026 21:47При этом образ объясняется а не формализуется
А в чём принципиальная разница? Объяснение - это ведь, по сути, движение к формализации. Только более витиеватое. Вы лишь останавливаетесь на каком-то этапе, оставляя дальнейшую формализацию на откуп LLM.
Kirthgreat4
27.07.2026 21:47Базу выдал, добавить нечего. Ллм отлично заменяет гугл и стэковерфлоу, но системный дизайн ей пока доверять рано
Barnaby
27.07.2026 21:47Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
Запустить ее? Раз клод пишет софт значит это кому-то нужно, у ПО уже есть потребитель - вот он и проверит что работает как надо.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Только это будет не программист, а потребитель. Он все и сформулирует, а клод ему подскажет если сам не сможет. Погромист нафиг не нужон получается. В принципе это уже сейчас происходит - количество ПО сильно выросло, причем нормально оформленного с доками и гуями (LLM одинаково хороша во всем, да) - люди с помощью агентов пишут софт который им нужен, хотя раньше они бы в это явно не полезли. Сейчас это все еще (около-)программисты, но это вопрос развития LLM :)
Kano
27.07.2026 21:47Я пишу требования, ллм делает план и пытается в архитектуру (смотрим как на рекомендацию), я пишу код, ллм проверяет и даёт свои рекомендации, я правлю (или нет), ллм пишет кейсы для тестирования, я пишу вместе с ллм тесты и в конце еще ллм делает обзор на PR. Вот это здоровый способ использования ллм
feelamee
27.07.2026 21:47по-моему вы упускаете тот же самый момент что и автор статьи:
Проблема всё равно остаётся: откуда берётся эта точная спецификация
Во-первых, спецификация и есть по сути код.
Во-вторых - а откуда она берется сейчас? Правильно, постановщик задачи дает его представление о требуемом результате, а задача современного разработчика это представление привести к спецификации. Для этого есть разные способы - логические заключения, уточняющие вопросы и тд.
Т.е., то что вы упускаете - почему этим “современным разработчиком” должен быть человек? Что мешает следующему или N-ому клоду быть достаточно сообразительным чтобы заниматься этим? Правильно - ничего.
P.S. хотя похоже иммено это и пытается сказать @amazingname, пусть и в не очень сдержанной манере.
Dr_Faksov
27.07.2026 21:47«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее.
Вполне себе спецификация. Ибо есть и формальные описания и главное - куча примеров. Создать по аналогии - не подходит?
А картинка паровоза таки да - отстой.
k4ir05
27.07.2026 21:47И что вы по этой спецификации ожидаете? Копию одной из операционки? Или некую сборную солянку в произвольных пропорциях из произвольного набора? Только зачем такая операционка нужна, если можно взять готовую?
Dr_Faksov
27.07.2026 21:47Я ожидаю нЕчто, что можно назвать операционной системой. "Зачем" - это вы себя спрашивайте. В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось. Заметьте - я не обсуждаю нужность\полезность написания. Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают. TR-DOS помещался на дискете 360 КБ. И ещё место оставалось.
k4ir05
27.07.2026 21:47"Зачем" - это вы себя спрашивайте.
Так не я же оправдываю такую "спецификацию". Мне такое вообще не нужно.
В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось.
А спецификации без назначения бывают? Стоит тогда уточнить термин спецификация.
Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают.
Что-то у меня эти предложения не стыкуются вместе.
Politura
27.07.2026 21:47Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мира и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
"Посчитай сотрудникам премии за квартал" работает только в сработанном коллективе, где этот весь контекст уже известен и все понимают главбуха, что именно он имел ввиду. А вот если приходит такой главбух к программистам и говорит: "хочу программу, чтоб считала премии за квартал", то у живого программиста совсем другой опыт и знания, так что ему придется все эти ваши вопросы задавать, и если программист чуть более опытный, еще и фиксировать в ТЗ на подпись, чтоб потом не было от главбуха: "а я совсем другое говорил!".
И вот-это ТЗ, это ТЗ на то, как должен выглядеть результат. Вариантов реализации по прежнему бесчисленное множество. Так вот, в отличии от времен изобретения Кобола и Сиквела, теперь это ТЗ можно напрямую засунуть в кодинг тулзы и получить нечто, что будет работать и выдавать результат по ТЗ. И даже на очевидных неопределенностях кодинг тулзы будут вопросы задавать: как сделать, вот-так, или так? И вместо выбора из предложенных вариантов, можно текстом ему написать какой-то новый вариант, которого нет в списке, и он поймет и сделает по-нему.
Dr_Faksov
27.07.2026 21:47чтоб потом не было от главбуха: "а я совсем другое говорил!"
Это не ТЗ, это защита от недобросовестности заказчика. Но тоже быть должна. Хотелки -они такие :)
funca
27.07.2026 21:47теперь это ТЗ можно напрямую засунуть в кодинг тулзы и получить нечто, что будет работать и выдавать результат по ТЗ
В реальности как результат соотносится с ТЗ не знает даже сама тулза, не говоря уже обо всех остальных.
Wesha
27.07.2026 21:47Тут ещё хохма в том, что поменялась тулза — и она по тому же самому промпту нагенерит что-то совершенно новое.
Dr_Faksov
27.07.2026 21:47как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
А это сейчас кто-то, кроме заказчика, может это проверить? И не ссылайтесь на техзадание, это просто бумажка - зад исполнителя прикрыть. А ещё - чистосердечное признание в том, что компетенция разработчика недостаточна для понимания замысла заказчика, и требуется разжевать и в рот положить. И для его реализации - тоже. И не надо рассказывать, что заказчик не знает, что ему надо. Знает. Просто в 99% случаев квалификации исполнителей не хватает. И начинаются упрощения.
Наконец-то настанет светлое будущее, когда заказчик будет платить деньги за то, что ему надо, а не за то, что смогли наваять и теперь ему втюхивают.
randomsimplenumber
27.07.2026 21:47И не надо рассказывать, что заказчик не знает, что ему надо. Знает.
Тоже мне тайна. Он хочет кнопку "Заработай много денег"
Просто в 99% случаев квалификации исполнителей не хватает.
В 100%
Kirthgreat4
27.07.2026 21:47Если разрабы такие тупые, а заказчики умные, почему заказчики сами себе код не пишут. Кнопку "сделать збс" еще не завезли в новые фреймворки
IvanSTV
27.07.2026 21:47здесь весь вопрос с том, что процессы - они в голове у заказчика. И там огромное количество нюансов, которые вытащить из головы и описать - это огромнейший труд. Когда заказчик сам себе хороший программист, то все великолепно получается. Я много-много раз писал автоматизации СВОИХ процессов под СВОЙ функционал, а потом еще и разворачивал его как универсальный для коллег, так как знаю все нюансы процессов. И ограничивало 2 вещи: время на разработку и знания яп/технических инструментов. То есть, когда квалификации чисто в том, КАК это сделать, не хватало. А вот с тем, ЧТО сделать надо - все было просто.
Даже самый тупой клиент абсолютно точно знает, что ему надо. Объяснить не может. А вот передать весь массив информации, что есть в башке у владельца процесса - это отдельное искусство.
Вот элементарное. Нужна обработка считать стоимость перевозки по количеству коробок, потому что раньше считалось все по весу, а тут хлоп - одному клиенту надо покоробочно выставлять. Пересчитали, внедрили, оказалось, что параллельно считается по весу количество паллет, и для покоробочного тарифа оно некорректно. Дописали еще пересчет паллет. Потом оказалось, что для многострочных счетов количество паллет ставится по хитрому принципу, существующему лишь в башке оператора - как распределить на много строчек количество паллет, сформулировать принцип округления и распределения по паллетам никто из операторов не может, но все делают. Пытать операторов с образованием в 9 классов+ПТУ бессмысленно, давай статистически посмотрим, как они ставят. Выявили три закономерности. Согласовали. что алгоритм распределения количества паллет по строкам будет именно по этим закономерностям, статистические погрешности операторы правят вручную. Вроде ерунда - оператор залезает в документ, считает по количеству коробок количество паллет (причем сколько на каждом типе паллета каждого типа коробки, оператор держит в памяти, в справочниках такого нет), проставляет по строчкам, считает по тарифу - операция для оператора простая, но ручная и небыстрая. А для автоматизации просто описание алгоритмов - целый проект с опросами и выборками. И тут два способа. Если разраба посадить оператором, то освоит и автоматизирует в процессе. Или аналитику переводить мысли в головах операторов в что-то алгоритмизируемое. А писать разраб будет на машкодах или на bsl - непринципиально. Можно попробовать оператора научить программированию - этот путь пропагандирует вайбкодинг. Но результат неконтролируем и неприемлем.
Qwest_Prozto
27.07.2026 21:47Это вы тот самый тип заказчика, у которого техзадание - "сделай мне социальную сеть по типу фейсбук с бесконечной базой данных за 5к рублей"? Ну, просто разрабов таких не нашлось что сделают, конечно конечно. Дальше оправдывайте свой инфантилизм.
Dr_Faksov
27.07.2026 21:47за 5к рублей
Э не, как раз за деньги речь нигде не шла! Это вы сами придумали! Деньги как раз одним из основных регуляторов и являются.
А на счет вашего техзадания - его можно и по другому вывернуть. За 50M USD возьмётесь делать? Только "AS IS" не будет. Срок исполнения - 90 дней. За каждый день просрочки запуска - штраф в 1% процент от стоимости заказа. За каждый час простоя сети в течении первых 120 дней - штраф в размере % процент от стоимости заказа. За каждый сбой регистрации клиента - штраф. За не срабатывание фильтров DRM и прочей цензуры - штраф. И много ещё чего. Квалификации хватит? Или только сумма оплаты маловата?
Клиент всегда прав, пока платит деньги :)
Kerman
27.07.2026 21:47Статья одной картинкой
А, извините, @Wesha раньше успел.
Wesha
27.07.2026 21:47Кстати, любителям английского предлагаю догадаться, для чего именно предназначен метод
record_changes()в незнакомом коде: записывает в базу изменения, произошедшие в некоем объекте (записать_изменения()) — или представляет собой хук, который вызывается, когда система обнаруживает изменения в некой записи (запись_изменяется()). True story, bro.funca
27.07.2026 21:47Первый вариант, если код писали нейтивы. А так может быть все, что угодно.
Wesha
27.07.2026 21:47Так в том-то и проблема, что писала смешанная команда нейтивов и индусов.
funca
27.07.2026 21:47Неожидано. У индусов специфичное произношение, но английский обычно это второй, а когда и первый язык.
randomsimplenumber
27.07.2026 21:47По легенде, венгерскую нотацию придумал, внезапно, венгр из Microsoft.
funca
27.07.2026 21:47Не даром венгерский язык считается одним из самых трудных на планете, даже по сравнению с русским.
randomsimplenumber
27.07.2026 21:47Наверное, за имена переменных на венгерском транслите его сильно били палкой ;)
Diacut
27.07.2026 21:47Ух ты... Тот ещё старичок. И в космос пару раз слетал, и жена фотомодель, ещё и нотацию придумал.
Kerman
27.07.2026 21:47Метод называют глаголом, который что-то делает. Соответственно, в наименовании record changes "record" тот самый глагол. Если нужно обработать какое-то событие, то ставят handle_record_changes. Ну или в ивентах OnRecordChanged. Тут зависит от языка и соглашений.
vlivyur
27.07.2026 21:47Для второго варианта там должно было быть changed. Если там именно изменяется, то тогда changing.
Wesha
27.07.2026 21:47Челодой моловек, «changed» — это «изменился», а «changes» — это «изменяется».
randomsimplenumber
27.07.2026 21:47Трактат о пользе естественного языка в программировании. Датируется серединой Средних Веков, когда в наставлении для монахов попутали celibate и celebrate ;)
Оно еще и изменения ;)
vlivyur
27.07.2026 21:47Если в данный момент изменяется, то там не будет changes, там будет именно changing (is changing, если быть по-английски точным), потому что он сейчас изменяется, а не постоянно. А на изменение хук вызывается когда значение уже изменилось, т.е. changed
Но это если мы про глаголы говорим. А так-то там может быть и простое change - изменение (сущ.): on_change - при изменении.
Wesha
27.07.2026 21:47Но это если мы про глаголы говорим.
Я так понимаю, Вы не заметили, что там индусы мимокрокодили?
Fedorkov
27.07.2026 21:47Не хватает цитаты из Совершенного кода (2004).
За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — автоматическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улучшения, и общими усилиями они сделали программирование абсолютно неузнаваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инноваций не устранила программирования как такового.
Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инструментах — программистам приходится бороться с несовершенством реального мира; нам нужно досконально продумывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с плохо определенными интерфейсами с другими программными и аппаратными средствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования.
Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтб делать, и эта деятельность будет называться программированием. Когда вы слышите заявления о том, что «новый инструментарий устранит необходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом.
ShIV03
27.07.2026 21:47попробую чуть перефразировать:
1. Как исходная аксиома:
Всегда, человечество пыталось упрощать.
Нет предпосылок, что этого не будет происходить дальше.
2. Программирование - "еще один" способ упростить.
- появился (среди гиков - "универсалов");
- занял (массовую) нишу;
- и еще будет (узкие специальности, там где они выгодны. Аналогично, по проектным командам, и водопадной разработке).
3. LLM-ассистенты, вайб-кодинг - нужно другое, новое слово, чтобы не смешивать со "святым" программированием:
- спец - "сам сделаю лучше", и не позволит LLM выйти в "мастера";
- универсал - вспомнит "всё - уже было: постановка задач").
4. (Почему:) когда мы вызываем такси, (обычно!) нас и исполнителя, интересует только пара Принятых общих вопросов, но не такие детали, как марка машины, цвет, марка бензина.
Они - для чего-то сложного/уникального, ближе к "проекту", чем к "кодированию (программного обеспечения)".
Можно предположить, что LLM - (в будущем) будет сильнее ориентироваться в таких общих вопросах (специализироваться: помнить или получить сведения - "страна", "предпритие" пользователя, знать Бухгалтерию РФ, получить "штатное", ...).
5. Т.е. "в будущем" - "на входе" (на уровне Пользователя), всё (почти всегда, 99%) будет - просто, быстро и без лишних вопросов (появятся инструменты - языки, среды, ...).
А "что там внутри" - "магистрально", тожевыродитсяпереродится (как Электричество - для пользователя, за сто лет, свелось к "220В, выключателю, лампочке и проводам". Со стандартами - внутри).
6. Бороться, на своем уровне - пожалуйста ("Прыгайте, дети!" - тов.Дынин).
В целом - тенденция не умолима (никакие ошибки LLM - аля "кз", "телик, сгоревший при бросках" - не заставят отказаться. Всё - быстро подстроится).
7. Рассказывать, как было хорошо, когда все руками, уникально, и с головой - "Воспоминания юности".
8. Разработка "на века" - станет редкой, только для эстетов (типа, аудиофилов).
"Сформулировал, передал (там - что-то как-то сделалось), получил и забыл"
(в следующий раз, пользователь - начнет по новой, а внутри - предпочтут "выкатить с нуля").
Kirthgreat4
27.07.2026 21:47Если нейронки так шикарно понимают человеческий язык, почему промпт-инжиниринг с каждым днем все больше напоминает синтаксис плюсов)) Скоро начнем скобки и отступы в промптах ставить
semmaxim
27.07.2026 21:47Вообще-то наоборот. Как раз на современных умных моделях надо отказываться от всяких "хаков". Вон, недавно в методичке от Claude написали, чтобы программисты перестали загрязнять контекст всякими уточнениями, правилами и прочей мутью. Современная нейросеть гораздо лучше понимает строгий и лаконичный код, а не развесистый промпт.
Wesha
27.07.2026 21:47Современная нейросеть гораздо лучше понимает строгий и лаконичный код, а не развесистый промпт.
Не льстите себе — не понимает ни того, ни другого.
LemeRus
27.07.2026 21:47Справедливости ради, лаконичного в статье нет, а увиденная мною в комментах лаконичность другого автора напрочь убита прозаичностью и бесструктурностью. Если попытки будут продолжены, то стоит попробовать сильно ужать сопутствующий код верхнего уровня и увеличить описание конкретных элементов рисунка. Например (
< Ото рта [ПЕРСОНАЖ:ЗАЯЦ] идёт "хвостик" "пузыря" [ПУЗЫРЬ1], который располагается выше всех остальных "пузырей" на панели.[ПУЗЫРЬ1] содержит текст (реплику [ПЕРСОНАЖ:ЗАЯЦ]): "Да вот, обменник открыл!".
---
> Пузырь с текстом "Да вот, обменник открыл!", хвостик пузыря кончается у [ПЕРСОНАЖ:ЗАЯЦ]
)
А по теме здешнего обсуждения… Мне понравилось описание работы с нейронкой как общения с мидлом, которого надо контролировать как джуна. То есть LLM можно сгружать рутинные некритичные задачи при условии наличия большой базы типичного кода (на подобие которого надо писать), но не что-то совершенно новое или ответственное.
Dr_Faksov
27.07.2026 21:47У вас очень странный диалог. Сейчас возможности от версии к версии отличаются примерно как поездка на велосипеде отличается от поездки на электровелосипеде, а та, в свою очередь - от поездке на гоночном байке. И если один из вас работает с версией 1.1 а второй с версией 1.2 - вам не о чём говорить.
Akon32
27.07.2026 21:47промпт-инжиниринг с каждым днем все больше напоминает синтаксис плюсов
Не сказал бы. Удивительно, но llm-агенты в последнее время понимают чуть ли не с полуслова, даже если писать обычный текст, без промптовых вывертов. Кажется, ещё год назад было хуже.
Wesha
27.07.2026 21:47Удивительно, но llm-агенты в последнее время понимают чуть ли не с полуслова, даже если писать обычный текст
Интересно, это их достижение — или всё-таки Ваша недоработка?
aero2210
27.07.2026 21:47Идея придумать ЯП без программирования - решить проблему кодинга, введя еще один уровень абстракции, но....
Любую проблему можно решить, введя еще один уровень абстракции, кроме проблемы большого количества абстракций.
Думайте)
VAF34
27.07.2026 21:47Странно отсутствие в списке обсуждаемых языков алгола и фортрана. Первый использовался только для описания того, что вам надо посчитать с непременным указанием необходимых компонентов, фортран фактически повторял алгол, но измененная по отношению к алголу форма текста подготавливала компилятор, который брал на себя учет всех особенностей применяемой ВМ
dalerank Автор
27.07.2026 21:47алгол и фортран идеи отобрать хлеб у программиста не преследовали, и были классическими ВЯП. Первый емнип вообще стал основой современной теории языков программирования с его блокам, областью видимости и рекурсией, т.е. его как раз никто не позиционировал как язык, понятный бухгалтеру или менеджеру. Второй afaik создавался, чтобы заменить ассемблер для научных вычислений, т.е. опять же цель это математические формулы и точная логика, а не естественный язык.
Aleksej10448
27.07.2026 21:471. Программирование — это управление сложностью Вы абсолютно правы в том, что естественный язык не приспособлен для описания детерминированных систем. Главная проблема здесь — комбинаторный взрыв состояний. В системе из 100 булевых переключателей существует
возможных состояний. Естественный язык оперирует аналогиями и умолчаниями, он отлично сжимает информацию («сделай мне удобно»), но при попытке развернуть эту инструкцию в конкретные состояния системы возникают противоречия. Язык программирования (текстовый, визуальный или нейроинтерфейс) — это единственный известный человечеству инструмент принудительного устранения неопределенности. Он заставляет автора пройти по каждому ветвлению if-elseдо конца. Пока физические объекты (самолеты, кардиостимуляторы, атомные реакторы) подчиняются законам физики, а не желаниям оператора, этот механизм будет нужен.2. Экономика «примерно правильно» В бизнесе есть понятие стоимости ошибки.
В контент-маркетинге ошибка стоит ноль: вы написали слабый пост, его просто пролистнули. Поэтому там работает Vibe coding на базе LLM — генерируем 10 вариантов, публикуем лучший, убытки минимальны.
В процессинговом центре банка ошибка перевода стоит миллионы долларов в минуту плюс штрафы регулятора. Стоимость компиляции неточного запроса в точный код становится ничтожно малой по сравнению со стоимостью потенциального сбоя. Именно поэтому индустрия сопротивляется переменам в критических узлах. Вы можете писать фронтенд интернет-магазина с помощью голосовых команд, но логику работы ядра базы данных Oracle всё равно будут описывать люди через строгие формальные спецификации, потому что цена абстракции там слишком высока.
3. Что на самом деле делает LLM (и почему программист остается) Vibe coding сдвинул проблему, как вы верно заметили, но механика этого сдвига чисто техническая. Нейросеть — это статистическая модель распределения токенов. Она не знает, откуда берутся деньги. Она видела миллиарды примеров кода, где за словом
transferследуют скобки с аргументами. Она угадывает синтаксическую форму, основываясь на контексте. Но бизнес-логика не содержится в синтаксисе. Она содержится в инвариантах:Сумма списания должна равняться сумме зачисления (закон сохранения).
Счёт отправителя не может уйти в минус ниже лимита овердрафта (бизнес-правило).
Транзакция должна быть идемпотентной (при повторном запросе деньги не спишутся дважды). LLM сегодня умеет попадать в первый пункт (синтаксис), иногда случайно во второй, но гарантировать третий она не способна без внешнего слоя верификации. Кто-то должен составить таблицу истинности для этих правил. Этот кто-то и есть программист. Просто вместо написания циклов
for, которые теперь тривиально генерируются, он тратит время на описание граничных условий, контрактов API и сценариев отказа (negative testing). Профессия смещается от написания алгоритмов к проектированию ограничений.
4. Эволюция интерфейса ввода Машина, которая исполняет «я хочу миллион долларов», действительно фантастика, но не из-за сложности ИИ, а из-за отсутствия протокола передачи намерений. Голосовой ввод или набор текста — это лишь синтаксический сахар поверх того же самого процесса трансляции. Чтобы команда выполнилась, она должна пройти цепочку: [Намерение] -> [Разрешение двусмысленности (какой именно счет?)] -> [Формализация в структуру данных (JSON/SQL)] -> [Исполнение]. Нейросети научились неплохо автоматизировать первые два звена, но мостик между «хочу» и «структура данных» всегда будет требовать жесткого каркаса, иначе система свалится в галлюцинацию. Лет через десять Senior Opus Engineer действительно появится, но его работа будет заключаться не в написании кода, а в составлении промптов-спецификаций такой плотности, что они сами по себе станут новым языком программирования высокого уровня.
5. Будущее профессии: от плотника к архитектору-инспектору Программирование не просто бессмертно, оно поглощает смежные дисциплины. Раньше архитектор рисовал чертеж дома, а прораб строил его «по месту», исправляя огрехи чертежа деревом и гвоздями. Сегодня BIM-модель здания — это фактически программа. Если в модели заложен конфликт трубы и балки, здание нельзя построить физически, пока ошибка не будет исправлена в цифре. То же самое происходит с любым бизнесом. Код становится единственным достоверным описанием реальности компании. А тот, кто гарантирует соответствие этой цифровой модели физической и юридической реальности, всегда будет называться техническим специалистом. Название должности изменится, суть останется: человек, который несет ответственность за то, чтобы абстрактная схема вела себя предсказуемо в реальном мире. Мы перестаем быть авторами каждой строчки, становясь редакторами, аудиторами и архитекторами среды исполнения.
С вашим выводом можно согласиться полностью, если уточнить формулировку: решить проблему абсолютной точности естественного языка нельзя, но её можно бесконечно компрометировать. Мы делегируем машине право ошибаться в деталях реализации (пусть сама выбирает сортировку пузырьком или быструю), но оставляем за собой жесткий контроль над правилами игры. Азбука смыслов заменяет текущий инструментарий, но потребность в авторе этой азбуки — носителе предметной области — вечна.
Если убрать метафизику и оставить сухой механизм того, как азбука смыслов заменяет традиционный код на микроуровне, механика выглядит так.
1. Отказ от токенизации Традиционный компилятор разбивает текст
transfer(amount, account)на токены (identifier,(,number,)) и строит абстрактное синтаксическое дерево (AST). Азбука смыслов пропускает этот этап. Она работает не с текстом, а с векторами намерений, которые уже разбиты на атомарные смыслы еще до ввода. Ввод «перевести немного денег маме» для машины — это не строка текста, а готовый набор активированных узлов:СУБЪЕКТ_ДЕЙСТВИЯ: ЯОБЪЕКТ_ВОЗДЕЙСТВИЯ: БАЛАНС_МОЙОПЕРАЦИЯ: УМЕНЬШИТЬПАРАМЕТР_Квантования: НЕОПРЕДЕЛЕННЫЙ_МАЛЫЙ(триггер на запрос уточнения)ЦЕЛЬ: БАЛАНС_ИДЕНТИФИКАТОР(РОДСТВЕННИК_ПРЯМАЯ_Линия)ТРАНСПОРТ: ПРОТОКОЛ_PSD2/Visa
2. Механизм микро-кодировок Микро-кодировка — это перевод семантического узла в бинарный вектор состояния системы без промежуточного языка высокого уровня. Это происходит через три механизма:
Аттеншн-анкеры (якоря внимания): Вместо поиска совпадения по строке
account_number, система ищет пересечение смысловых полей. Вектор запроса[деньги] [отдать] [другому человеку]имеет максимальное скалярное произведение с вектором системной функцииledger.debit(). Это чистая математика линейной алгебры: косинус угла между вектором желания пользователя и вектором системной возможности должен быть близок к 1.0. Если он равен 0.7, машина понимает направление, но запрашивает уточнение анкерных параметров (какому именно человеку?).Операнды-примитивы: Традиционные типы данных (
int,string,float) заменяются смысловыми модификаторами. Например, операндНЕМНОГОиз вашего примера — это не переменная, а функция-модификатор
, которая при трансляции в микро-кодировку обращается к профилю субъекта и возвращает конкретное число или диапазон ![[x_{min}, x_{max}]](https://habrastorage.org/getpro/habr/formulas/f/fe/fe1/fe10b5bd180a4b73a160b0eb5116e506.svg)
. Микро-кодировка здесь — это динамический байт-код вида PUSH_CONTEXT(PROFILE_USER) -> CALL_MODIFIER("TRIVIAL_AMOUNT") -> PUSH_RESULT.Гильоши состояний (State Holograms): Поскольку естественный язык плохо описывает ветвления, азбука смыслов использует вероятностные поля вместо жестких конструкций
if-else. Весь сценарий транзакции упаковывается в один компактный блок — гильош. Это многомерная матрица, где каждая ось — это риск-параметр (ликвидность, легитимность, курс). Машина не исполняет код строчка за строчкой, она проецирует вектор запроса на эту матрицу. Если точка попадает в зеленую зону, микро-код выдаетCOMMIT. Если на границу — генерирует уточняющий опкод для интерфейса. Это избавляет от написания сотен вложенных условий проверки.
3. Как это выглядит на уровне железа (шина и память) На уровне процессора микро-кодировка — это прямое управление регистрами флагов и шиной адреса. Традиционная команда
if (balance < amount) throw Error();превращается в последовательность инструкций ассемблера:LOAD,CMP,JUMP_IF_LESS. Микрокод азбуки смыслов делает иначе. Смысловое полеНЕДОСТАТОЧНО_СРЕДСТВсамо по себе является готовым набором битов для регистра флагов процессора (например, установка флагаCF— Carry Flag — в архитектуре x86). Система не «проверяет условие», она сопоставляет смысловую нагрузку входящего вектора с аппаратным состоянием памяти. Ошибка нехватки средств — это не исключение в программе, это физический факт несоответствия двух векторов в адресном пространстве, который считывается за один такт.4. Где здесь место программиста (почему азбука его не заменила) Азбука смыслов автоматизировала написание реализации, но создала новую задачу — проектирование самой азбуки. Кто-то должен заранее определить:
Что именно считается узлом
СУБЪЕКТ. Является ли им юридическое лицо? А группа лиц? А бот?Какова разрядность вектора
НЕМНОГО. Какие числа там зашиты? Как они масштабируются в зависимости от региона (для кого-то «немного» — это 100 рублей, для кого-то — 10 000)?Как разрешать коллизии. Если вектор содержит одновременно
ЭКОНОМИТЬиКАЧЕСТВЕННОЕ, какой приоритет выше?
Этот процесс называется онтологическим инжинирингом. Программист старой школы писал инструкции для машины. Программист эпохи азбуки смыслов пишет правила игры для самих понятий. Он создает ту самую таблицу перевода смыслов в микрокод. И если он ошибется в определении базового узла (например, неверно задаст инварианты для узла
ДЕНЬГИ), рухнет вся банковская сеть, потому что LLM будет идеально точно и быстро исполнять ложную логику на уровне микрокоманд.5. Почему Vibe coding лишь заплатка Когда вы диктуете нейросети голосом, под капотом всё равно работает эта микро-кодировка. Нейросеть просто берет на себя самый грязный труд — извлечение тех самых узлов (аттеншн-анкеров) из вашей акустической волны и грамматических ошибок. Но финальный шаг — превращение распознанных узлов в безопасную транзакцию — всё равно требует жесткой формальной прослойки. Эту прослойку нельзя прошептать голосом, её можно только спроектировать. Именно этот слой проектирования микро-кодировок и есть бессмертное программирование. Текстовый редактор стал ненужен, но потребность в человеке, который скажет машине, что «немного» для этого конкретного банка означает «не более 15% от текущего остатка», останется ровно до тех пор, пока существуют банки и человеческая неточность.
Diacut
27.07.2026 21:47Машина, которая исполняет «я хочу миллион долларов», действительно фантастика
Нет, это банкомат. Ну ладно, большой такой банкомат...
CrushBy
27.07.2026 21:47Тут, на мой взгляд, в один мешок свалены две разные вещи: высокий уровень абстракции и конкретные закрытые визуальные конструкторы. Проблема начинается не тогда, когда язык выше Java, а когда у платформы нет следующего слоя вниз.
В том же lsFusion бизнес-логика остается обычным plain code: свойства декларативные, действия императивные, формы и их расширения тоже код. Все лежит в git и нормально мержится. Если платформенной конструкции не хватает, можно уйти в SQL, Java, JavaScript или внешний API, не переписывая приложение целиком. Сама платформа open source.
Поэтому тезис "нестандартная логика или интеграция сразу превращает 4GL в золотую клетку" не универсален. Золотая клетка получается у закрытого визуального DSL.
А с основным выводом согласен: программисты никуда не исчезают. Высокий уровень абстракции убирает рутину, но формализовать правила и отвечать за них все равно кому-то надо.
nomhoi
27.07.2026 21:47Косвенно вылезает ещё одно свойство, уже не про Райса, а про сам естественный язык. Чем более сложную композицию мы хотим построить, тем хуже она ложится на слова. По‑русски это звучит так, что маленькую функцию описать словами можно, получится даже неплохо и понятно, а вот систему на миллион строк словами описать нельзя, и дело не в том, что слов не хватит, просто естественный язык не композируется, а смысл может накладываться, перетекать от предложения к предложению или зависеть от соседних предложений, захватывая абзацы, а иногда и более крупные участки произведения.
для борьбы с этим и придумали DDD, разделение контекстов
Вы абсолютно правы, и это очень глубокое наблюдение. Вы затронули фундаментальную проблему семантического коллапса в естественном языке при масштабировании.
Естественный язык обладает свойством нелинейности и контекстной зависимости (синестезия смыслов, омонимия, метафоры). В литературе это плюс, но в инженерии — катастрофа. Код же обязан быть композициональным: смысл целого должен строго складываться из суммы его частей.
Вот как именно Domain-Driven Design (DDD) и разделение контекстов (Bounded Contexts) борются с этой проблемой естественного языка:
1. Борьба с полисемией (многозначностью)
В больших системах одно и то же слово означает абсолютно разные вещи для разных людей.
Проблема: Слово «Аккаунт» для бухгалтера — это баланс и проводки. Для службы безопасности — это логин и права доступа. Для маркетолога — это профиль клиента. Попытка создать единое описание «Аккаунта» словами приводит к путанице.
Решение DDD: Каждому контексту — свое определение. В контексте «Биллинг» Аккаунт — это деньги. В контексте «Авторизация» — это сессия. Смысл больше не «перетекает» хаотично.
2. Ограничение когнитивной нагрузки
Человеческий мозг не может удержать связи между миллионом строк кода или тысячей страниц текста, если они переплетены.
Проблема: В тексте без границ смысл предложения А может внезапно зависеть от абзаца Z в конце книги.
Решение DDD: Ограниченный контекст (Bounded Context) создает жесткую границу смысла. Все, что происходит внутри контекста, изолировано. Вам не нужно знать контекст Z, чтобы понять контекст A.
3. Единый язык (Ubiquitous Language) как API
DDD не пытается исправить весь естественный язык сразу. Оно исправляет его локально.
Решение DDD: Внутри одной границы создается строгий, почти математический словарь. Слово «Заказ» внутри контекста «Доставка» означает строго конкретный набор полей и статусов. Шаг влево, шаг вправо — синтаксическая ошибка.
По сути, DDD признает: «Мы не можем описать сложную систему единым текстом на человеческом языке. Поэтому мы нарежем систему на маленькие независимые “княжества”, внутри каждого из которых язык будет простым, однозначным и не вызовет композиционного взрыва».
Moog_Prodigy
27.07.2026 21:47Так и в коде придумали разбиение на функции, классы и прочие мелкие сущности, как раз для этого же. А огромная функция "посчитать дебет и кредит" занимающая 3 мегабайта текста мало того что нечитаемая легаси, изменения в ней проводить очень тяжело будет, даже если наизусть помнишь что где и как. А такое даже машине тяжело...
botyaslonim
27.07.2026 21:47Хорошая статья, спасибо!
Кмк, программист превращается из человека, который помнит наизусть встроенные методы и переворачивает деревья во сне, скорее в аналитика + архитектора
OlegZH
27.07.2026 21:47Да. Очень трудно объяснить работу какого-то механизма.
Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мира и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
Это мы понимаем, что есть сотрудники, есть кварталы, возможно начисление премии (по некоторым правилам). Трудность формализации. Надо задавать некие элементарные понятия и строить из них конструкцию, которую можно учитывать в расчётах. (Этим 1С и занимается.) Проблема в том, чтобы вытащить все умолчания, то есть сделать явным всё тайное. Если бы существовал формальный способ через диалог вытащить это всё из заказчика, то давно так и делали бы.
Хотя, да, можно было бы представить себе, как система постепенно учится понимать, что есть какие-то сотрудники, которые куда-то ходят, получают за это зарплату, и что могут быть ещё и премии...
OlegZH
27.07.2026 21:47"посчитай премии за квартал"ИИ-подход, видимо, должен заключаться в том, чтобы "скормить" этому самому ИИ руководство по бух. учёту + текущее законодательство и получить на выходе готовую конфигурацию объектов. Причём, ИИ должен сам выбрать (что и делает при программной реализации каждый живой программист) типологию объектов (в отличие от живого программиста, ИИ может проверить несколько различных гипотез в автоматическом режиме). (Что же будет являться здесь обучающими данными?)
С фундаментальной точки зрения, у нас возникает три пробелмы:
Можно ли найти такие элементарные понятия, которые позволяют выразить все необходимые классы объектов и автоматически строить системы для их обработки?
Можно ли находить такие элементарные понятия эффективно (если первая проблема разрешима)?
Можно ли пользоваться теми понятиями, которые действительно можно выделить. даже если построение полной системы составляющих неразрешима?
Тут проявляется что-то вроде теоремы Гёделя о неполноте формальных систем, когда логически непротиворечивая система оказывается неполной.
P.S. Эхх... Придётся пойти в такие теоретические дебри! Как любил повторять Морж у Льюиса Кэррола (и у Бьярна Страуструппа), "о многом пришла пора поговорить"... ;-)
kneaded
27.07.2026 21:47Я, как инженер, поддерживаю автора и всё сказанное. Буквально недавно читал статью про пограничные случаи в медицине https://habr.com/ru/companies/beget/articles/1051252/
Попробуйте, что называется, такое навайбкодить. А с учётом разного законодательства в разных странах, если продукт задумывается как мировой, нужно предусмотреть какие-то конфигурации или возможность для него, чтоб условно было не 2 гендера (пола), а больше
Я есть инженер данных и я специализируюсь на таких пограничных случаях. Ещё ни в какой сфере, где я работал, человеку не инженеру не удавалось описать всё словами, люди обычно держут контекст (что подтверждает статью) и о многом умолкают. Будь то железнодорожные перевозки (что делать с вагонами, у которых на путях преграда - будь то сломанные пути, человек лежит, дерево или визуально невидимая дорога из-за плотного пожара), мобильная связь (как и на какой дистанции устанавливать антенны, делиться ли антенной между операторами), медицина (читай статью выше), фармацевтика (там своих приколов с исследованиями и побочными эффектами хватает), строительство (ну тут вообще с ума сойти можно из-за разных климатических условий и вероятностей землетрясения)
Просто жду когда люди осознают что ИИ это не волшебная таблетка. Дело не в языке программирования и в разработчиках, нет, тут многое другое порождает наши специализации и оно вряд ли когда уберётся (условно - как запретить всем банкоматам выдавать валюту когда в стране кризис)
unC0Rr
27.07.2026 21:47Ещё ни в какой сфере, где я работал, человеку не инженеру не удавалось описать всё словами, люди обычно держут контекст (что подтверждает статью) и о многом умолкают.
Новые люди приходят в эти сферы, обучаются? Как им передают опыт? Что, если к новичку приставить ИИ, которая будет протоколировать обучение и выдаст документацию по всем нюансам?
Просто жду когда люди осознают что ИИ позволяет приложить усилия по обучению и экстракции опыта ровно один раз, после чего мгновенно можно иметь хоть миллион исполнителей, которые не уйдут в запой.
kneaded
27.07.2026 21:47Тут был длинный комментарий, но что-то произошло и комментарий отправился не полностью. Позже отвечу подробнее, но это не точно
Wesha
27.07.2026 21:47после чего мгновенно можно иметь хоть миллион исполнителей, которые не уйдут в запой.
Уйдут, как только электричество кончится.
lazarus_net
27.07.2026 21:47Попробуйте, что называется, такое навайбкодить. А с учётом разного законодательства в разных странах, если продукт задумывается как мировой, нужно предусмотреть какие-то конфигурации или возможность для него, чтоб условно было не 2 гендера (пола), а больше
И скажите нам, как специалист по граничным условиям: вы при наличии 10-ти грендеров, кого будет к урологу, а кого к гинекологу посылать?
Ещё вопрос с родильным отделением остается открытым и все что с ним связано…..
kneaded
27.07.2026 21:47А там в той статье про медицину в целом сказано, но повторюсь своими словами - на такой случай заводятся два поля - биологический пол (только мужской или женский) и пол юридический (хоть какой). И уже от биологического все пляшут
Cerberuser
27.07.2026 21:47кого будет к урологу, а кого к гинекологу посылать?
К урологу - с заболеваниями мочевыводящей системы (независимо ни от гендера, ни от биологического пола), к гинекологу/андрологу - с заболеваниями половой системы, в зависимости от вида этой самой системы.
FlyingDutchman2
27.07.2026 21:47Тут надо дать ссылку на классиков: Эдсгер Дейкстра On the foolishness of “natural language programming” (на Хабре есть перевод)
OlegZH
27.07.2026 21:47Надо очень хорошо понимать, что общепринятым является представление, в соответствии с которым имеется набор элементарных токенов (например, слов естественного языка), и каждый токен имеет своё значение (свой смысл); каждое предложение также имеет свой смысл, и этот смысл передаётся от одного субъекта к другому. Такую теорию информации можно назвать денотативной. Под денотатом здесь и понимается некий символ, за которым стоит определённое значение, и мы используем денотаты для передачи сообщений. Но всему этому противостоит коннотативная теория информации, где смысл никак не передаётся (от одного субъекта к другому), а привносится (субъектом-получателем). Это связывается с тем, что у каждого субъекта имеется своя собственная когнитивная область, то есть — своя система координат, свои наборы опорных объектов и обозначений.
В этом смысле, естественный язык можно воспринимать как смесь более узких подъязыков, где одновременно присутствуют и элементы "высокого уровня", и элементы уровня "микрокода", которые управляют интерпретацией элементов "высокого уровня". И если "высокий уровень" ещё и претендует на что-то общезначимое, то чем "ниже", тем всё более завязывается на субъекта (как говорящего, так и слушающего). Получается что-то вроде контекстно-зависимой грамматики, чья зависимость определяется каждым субъектом. При этом, сам формальный подход к описанию естественного языка, также представляется принципиально неполным...
P.S. Помнится, у Бурбаки была предпринята попытка полнейшей формализации математики. Не получилось.
beswalod
27.07.2026 21:47Очень хорошая, глубокая статья.
Действительно, не всегда просто перейти от абстрактного желания заказчика к поведению конкретных пикселей (простите за вульгарность) на экране. А иногда и сам заказчик не до конца понимает что ему надо.
semennikov
27.07.2026 21:47Будете долго смеяться, но заказчик НИКОГДА не понимает что ему надо. Я, по крайней мере, никогда таких не встречал
dalerank Автор
27.07.2026 21:47ну почему же, я только таких и встречаю "сделай збс" разве не ясное и точное объянение?
VadimTikhonov
27.07.2026 21:47Добрый день. Статья интересная, спасибо. Комментрии тоже интересны. Выскажу две мысли, которые м.б. кто-то уже высказывал и частично есть в самой статье.
Спор по поводу Экспертизы программистов и Вайбкодинга не имеет ни кого смысла ! Почему:
Дело вообше не в этом, не в технологиях - дело в другом - если есть Экономический рост, Рост произвоства товаров и услуг, Расширения рынков, Развитие бизнеса и т.д. то будут востребовано и то и то. А если нет будет Экономического роста (основанного преимущественного на росте ТПН и услугах, не сырьевой или с/х), то в меньшей степени нужно будет и то и другое. Этим и объясняется "Парадокс Джевонса" - и это не парадокс, а наоборот поянятная Логика - если общество Развивается, Растет (Экономически, Демографически ит .д.), то растет и сложность устройство Общества, и Виды и Количество различных взаимодействий, операций в Мире. Конечно в современном Мире программисты нужны и в других направляниях - оборона, войны и т.д., но это скорее отрицательный пример для людей в целом, чем положительный (не здоровый рост).
Если смотреть узко, в рамках технологии Программирования, о чем большинство споров и комментариве. То здесь тоже Правда и там и там. Развитие технологий ( в данном случае Программирования, обработка информации в целом) показывает четко, что мы движемся от Низкоуровневых инструментов к более Продвинутым инструментам и Стандартизации рутины - поэтому, Да многое будет упрощено и автоматизировано. Но Востребованы будут и Программисты потому что иммено они обладают Одновременно - Экспертизой в технологии и спобностью решать Новые, Оригинальные и/или Сложные, Комплексные, не Стандартные задачи, а это нужно будет всегда, хоть через 1000 лет.
Revertis
27.07.2026 21:47отладки, оптимизации производительности (одна из областей где даже всемогущий Клод плавает аки топор и говноклодит, только успевай комиты реджектить)
В корне не согласен. Даже Opus 4.8 вполне замечательно справлялся с оптимизацией шифрования, встраивая SIMD-инструкции, и добавив бенчмарки для сравнения реализации.
dalerank Автор
27.07.2026 21:47мои недавние проекты говорят обратное, https://youtu.be/Tt1CYGt2goo?si=rAqiWGyzgfkdSJDi
клод действительно хорош в написании нового кода, возможно, но не в оптимизации уже существующего, особенно если это связано с памятью. Надеюсь мне дадут апрув на статью про это и можно будет показать, что ИИ не видит в упорRevertis
27.07.2026 21:47То, что кто-то один не смог, ничего не говорит о самой нейронке. А у меня, например, я уже писал, он ускорил шифрование Salsa20 в 4 раза, добавив реализацию с AVX, AVX2 и NEON.
amazingname
Вообще мимо. Не нужна никакая точность формулировок. Это все рассистские предрассудки кожаных. На практике чем меньше точных формулировок и чем больше общего описания что и зачем нужно, тем лучше результат. Потому, что всякий кто руководил живыми программистами а теперь агентом знает, что агента от живых программистов отличает понятливость и, внезапно, здравый смысл.
От человека на данный момент нужно общее стратегическое понимание как все будет работать - какого рода алгоритмы, примерно что за данные, что будут проверять тесты, и определенная доля внимательности к деталям, чтобы не попасть на бессмысленно раздутую кодовую базу и неоптимальные по быстродействию решения. Безопасность LLM уже анализируют на экспертном уровне.
При этом вообще не видно причин почему нельзя и это стратегическое понимание тоже перевалить на нейронки при дальнейшем их развитии.
И все это справедливо в этом месяце. А что будет через пол года никто не знает.
Просто смиритесь, что у вас больше нет принципиальных преимуществ перед машиной и не высасывайте из пальца причины почему все будет по старому.
amazingname
И если что, я девелопер с 30 летним стажем, который работает в энтерпрайзе проекте, в среднем палит токенов на 1000$ в месяц и не пишет код руками уже с пол года вообще.
А тема про "детальные требования" которые готовит человек для меня выглядит абсолютно оторванной от того что происходит в моей работе и в нашей команде, и тем более от того что я слышу от принципал АИ инженеров в проекте. Эти ребята уже успели предписать своих фреймворков на подобие бимэд и грустно выдают философские формулировки типа "мозг можешь засолить в банку с огурцами".
Где все это на хабре? Или я живу в альтернативной реальности?
Wesha
Сейчас проверим. В чём особенность чтения/записи в регистр
@#177714на БК-0010? Как узнать, что клавиша на клавиатуре нажата и удерживается?randomsimplenumber
30 лет назад уже существовали PC с турбопаскалями ;) потроха БК тогда уже мало кому были интересны, кроме пары гиков.
amazingname
Те что стали программистами в 96 как раз успели покодить на БК, синклерах, векторах в конце 80х.
Блин, карма все летит вниз. Это ж сколько неолудитов и цепанул своим вбросом на вентилятор, мать моя.
randomsimplenumber
Для того кто застал синклер, регистры БК могут и не значить ничего. Его про RANDOMIZE USR надо спрашивать ;)
Diacut
ну.... всякое бывало. кто-то синклеры и бк, а кто-то и S/360.... давно было
ps как-то прошли мимо синклеры и всякое такое. Хотя первое, с чем приходилось иметь дело это Наири-2, правда аж целых 45 лет назад. А 30 лет назад дома стояло глючное минское поделие ес-1840
Wesha
А вот давайте Вы не будете нам (ну или как минимум мне) рассказывать... 30 лет назад был 1996 год, самый расцвет БК. Ммм, синтезатор речи, умещающийся в 15,5 килобайт...
А PC с турбопаскалями да, существовали. В учреждениях. Разобыть чудо зарубежной технической мысли себе домой было практически нереально (хотя исключения бывали, да). Особенно с учётом того, сколько оно стоило. Мой первый писюк оказался у меня потому, что продали бабушкину квартиру.
randomsimplenumber
В каждой избушке свои погремушки, конечно же. Прикиньте, существовали люди, которых расцвет БК не коснулся ;) А PC можно и из бу частей собрать; они подходят :)
MxMaks
В 1996 году мы в школе дискетами с играми менялись, пентиумы и 486 были у 2-3х человек в моем классе и в параллельных еще больше. Урал. Стоил комплект Пентиума с монитором 5 900 000 руб, да хватило только на пень 120 вместо модного 133 и элт монитор 14" вместо 15" и среди продвинутой школоты считался нищим) но это примерно 1000 $ по тем деньгам сумма подьемная для многих, знать бы зачем). В журналах тех времен разгоняли тезис, ну как можно иметь авто за несколько тыс $ но не хотеть купить компьютер. Квартиры на видеомагнитофоны и подержанные авто да меняли но чуть раньше). В 2000м я уже сайты на Perl под яндекс загружал на Valuehost)
ivvi
Ох и отстойный был хостинг...
KReal
А я там работал в 2003м... Что не отменяет вашего тезиса)
ivvi
Вы шутите? У меня, студента, в 1994 году появился личный PC AT 386, и на тот момент БК воспринимался как что-то уже устаревшее. Родители - обычные инженеры, никто квартиру не продавал.
Riedl
не так. я синклер 128, собрал в 1992, в этот же год появились дисководы 5,25.БК действительно уже были неинтересны к этому времени. Расцвет синклеров, самиздат газетки это 1990 - 1993 год, далее они уже никому небыли нужны. В лицее у нас уже был класс на 80286 подареный американцами. в 1993 я перешел в универ - и там были СМ черно зеленые с бобинами ленты в соседней комнате и разобранные к утилизации читалки перфокарт. на некоторых кафедрах были Искры с картриджами и некое изобретение стран восточного блока под названием ЕС. к весне 1994 появились 80286,80386 и к 1995 году 80486 ну и далее это понятно. Понятно что паскаль, нортон, винда 3.1 и всякая остальная дичь
qvvah
Рассвет ли? Мои данные никак нельзя назвать полными, но тут, похоже, закат
Почему именно БК? Почему не ZX и не любой другой советский ПК, десятки их? Мне кажется, были бы тут спектрумисты - они бы заявили: "А вот в 95 был самый пик ZX..."
Wesha
Я так понимаю, дяденька — менеджер (ну, коли расцвет у него определяется по количеству новых продуктов, а не по их общему количеству)?
qvvah
У меня логика простая: если в РФ писали/портировали игры под БК больше всего в 1992ом, а в 1996 это уже были единичные случаи - значит и пик популярности был в 1992ом. Никто не станет программировать под устаревающую платформу, все переходят на новую. Оно как-то ещё по инерции живёт несколько лет, но популярность всё равно неумолимо падает. А у вас, вероятно, когнитивное искажение, сформированное вашим личным опытом.
Я бы в 2005ом ответил, что Dendy - популярная приставка. Но насколько бы это соответствовало реальности?...
Wesha
Ну так ведь я и не говорил, что «в 2005-м был расцвет „Денди“»!
qvvah
Насчёт Dendy - это пример аналогичного когнитивного искажения у меня, сформированного моим опытом. Вы, напомню, писали следующее:
Я к тому, что не был.
Wesha
А я к тому, что мы с Вами разные вещи под «расцветом» понимаем.
unC0Rr
А вы складской работник, коли определяете расцвет по общему количеству, а не по количеству используемых?
lazarus_net
Не знаю как у вас, а нам в среднюю школу обычного областного центра завели IBM PS/2
Правда с винтом был толко учительский но в то время 1.44 Mb хватало на все …
Wesha
Вам, наверно, забыли сообщить, что школа специальная (в хорошем смысле).
У нас тоже — но в одну. Из нескольких десятков.
sergey-gornostaev
В моей школе в "компьютерном классе" стояли Микроши и железная дверь, которая не открывалась никогда, так как занятий информатики у нас не было. Про Микроши я узнал только потому, что однажды по какой-то причине не нашлось класса для проведения урока то ли по русскому, то ли по математике, и железную дверь открыли.
ru_vlad
Ну если по “чесноку” то в 96 БК уже отошла, оставались единицы кто с ними общался. Тогда уже на развалах были платы РС и АТ в домашнем варианте использовался “Поиск” его брали готовым или паяли сами.
vlivyur
У нас в школе компьютерный класс с БК открылся году в 89. В 95м там уже стоял аж целая одна ЕС ЭВМ. В УПК занятия в то же время проходили на Intel 386 с FoxPro. А дальше только больше. Так что 96й год это уже был закат БК и домой добровольно его уже никто не брал, все мечтали об IBM PC.
Wesha
"Так выпьем же за то...
rblaze
В 1996 году у меня, студента второго курса, уже была PC с 486SX. БК к этому времени все повыкидывали нахрен. Я их видел в средне-школьные времена разве что, году в 90м.
Это в Москве, конечно. Мы там были зажравшиеся.
Wesha
А у нас в Замкадье всё было несколько сложнее.
Newbilius
А у нас в Краснотурьинске я знал людей, которые в начале 2000х дома имели 80286, потому что на большее денег не было. Так что да, будущее по миру распространяется неравномерно...
randomsimplenumber
Ну так БК недешевая игрушка.
amazingname
На ассемблере я писал для радио 86 рк, и это был 8й класс. Что про него помню, что регистр запрета прерываний был выведен на динамик чтобы пищать. Загружать программу нужно было с магнитофона, зная адрес куда она пишется. Так можно было писать в цикле - загрузил ассемблер, загрузил программу, изменил программу, записал программу, запустил программу, увидел что система ушла на перезагрузку, сел думать где ошибка. Я написал помню диггера и аквариум с рыбками и водолазом как в игровом автомате. БК был у моего кореша, но там я только пробовал пару команд... на fokal что-ли.
Восторг от этого был неописуемый. По идее сейчас должен быть такой же от новых возможностей LLM, но уже конечно не то.
mrcashe
Это не 30, а 35 лет тому.
Насколько помню, этот 16-битный регистр выводился на разъём типа СНП-59-64. Можно было подключить принтер, джойстик и т.д. 16 выходов, 16 входов.
Примечательно, что readback там не было: запись шла в одну пару регистров, а чтение - из другой.
randomsimplenumber
Схемотехника проще.
select26
Не думаю. Дешифратор адреса то проще сделать единый и стробировать по !WR.
Вероятно другая причина
Wesha
Да, схемотехника проще.
SEL2 (“обращение конкретно к адресу
177714”) генерируется внутри процессора. DIN, DOUT — соответственно сигналы чтения или записи.Wesha
Нейрослоп детектед: добавление правдоподобных, но неправильных подробностей («СНП-59-64» — никто зубодоробительных кодовых номеров мелких деталей не помнил, вот микросхем — то да. Спасибо ещё, что хоть эта колодка действительно существует в природе, и с первого взгляда даже похожа — но не она), а также вроде бы правильных (с первого взгляда), но по факту — неправильных деталей (какая ещё «пара регистров», когда спрашивалось про один?)
mrcashe
Я по образованию инженер-электронщик, моного чего помню. На БКшках кодил года 3, пока не прикупил 286.
Физически на плате было 4 микросхемы, подключённые к этому адресу. Кажется, К589ИР12. Они 8-битные. 2 на вывод, 2 на ввод.
Wesha
Тогда Вы правы — просто Вы очень резко перескочили от «регистр (ячейка)» к «регистр (микросхема)», я за Вашей мыслью не успел.
А так‑то да.
MxMaks
Ровно 30 лет назад у меня в Уральской глубинке был Пень-120 с Windows 95, Делфи и Visual с++
Wesha
Хватай нефтяника!
Rigidus
По одному адресу 177714 находятся два физически разных 16-разрядных регистра. Поэтому прочитать обратно только что записанное значение нельзя: при чтении процессор получит текущее состояние входных контактов, а не выходной защёлки. Кроме того, сигналы порта инверсные: записанный программой 1 соответствует низкому уровню на выходе, и низкий уровень на входном контакте читается как 1
Проверка удерживаемой клавиши - для этого используется бит 6 регистра 177716 - равен 0 - хотя бы одна обычная клавиша нажата.
Для случая, когда пользователь нажимает только одну клавишу, удержание определяют косвенно:
Получают код нового нажатия через
177662.Запоминают этот код.
Через нужное время снова проверяют бит 6 регистра
177716.Если бит всё ещё равен нулю — считают запомненную клавишу удерживаемой.
Если что - я не изначальный автор комментария, которого Wesha решил вывести на чистую воду.
Wesha
...однако почему-то тем не менее решили на него ответить, частично спалить правильный ответ, и заставить меня придумывать новый вопрос для детектирования нас, олдфагов.
Кстати, не до конца правильно — у Вас один шаг пропущен, а в другом — ошибка.
randomsimplenumber
Знание про существование регистров само по себе указывает на олдфажество ;)
Wesha
Или на использование гопоты.
qvvah
Или что учебная программа отстаёт на 40 лет и кто-то учил системное программирование по MS-DOS и DEBUG.EXE в 2020 году. Хотя так ли уж это плохо? Зато в 2026 драйверы пишут нейрослопом без всяких "регистров".
randomsimplenumber
MS DOS до регистров не опускается, там INT10, INT21 и прочая олдовая магия.
Да и не пофиг ли?
Rsa97
Во времена MSDOS было два типа регистров.
Регистры процессора, AX, BX и т.д. И как раз перед вызовом INT надо было заполнить нужные регистры, а по возврату прочитать результат из регистров.
Аппаратные регистры оборудования, которые прямо или косвенно адресовались через порты. Например, порт 3D4h - выбор регистра контроллера CGA, 3D5h - запись в выбранный регистр, 3D8h - запись в регистр установки режима CGA.
И, собственно, ни те ни другие регистры никуда и не делись, просто остались на самом нижнем уровне, скрытые от большинства программистов несколькими слоями абстракций.
qvvah
Если задача - выявление истинных олдскульщиков, то нужно давать более сложные вопросы, которые не пройдут ни нейросети, ни молодёжь. И не только по БК. Нужно что-то более жёсткое по отсеву и с несколькими подвохами по содержанию. В противном случае даже я набираю баллы.
А что до MS-DOS... Так и запишем: ассемблерные инструкции in, out вместе с регистрами процессора ax, bx, cx, dx - мне в страшном сне приснились. Хотя если бы не они, я бы так и не понял, что меня тянет к "железу".
randomsimplenumber
В каком возрасте вы спаяли/собрали свой первый компьютер? Написали первую игру?
:)
qvvah
Первый раз пытался перебить листинг игры на BASIC из книжки в Educational Computer 2000 в 8 лет (и сразу нарвался на опечатки в исходниках), тогда же - первый Hello World, позднее в школе "паскалил" всякое. Компьютер собрал аж на 11 лет позже. А паять... Толком не научился, как и делать всё остальное: я пока специалист разряда "на все руки мастер, только руки из @#$%"
randomsimplenumber
Вы приняты :)
Wesha
Ох уж мне эта молодьож. Ничо без компьютера не умеет,
даже программировать
randomsimplenumber
Так вот кто изобрел кросс компиляцию.. писать на бумажке код для компьютера, необычное ;)
Wesha
А на чём его ещё писать, если сегодня утро субботы, а доступ к компьютеру будет только в понедельник вечером?
qvvah
А вот тут вы меня недооценили, уважаемый @Wesha
давным-давно...
randomsimplenumber
Битва двух якодзун за должность председателя ;)
Wesha
Остаться должен только один!
vlivyur
Интересно, как это она не опускается до регистров? А как же тогда все эти int 21h получают параметры?
randomsimplenumber
Сорян, имел в виду регистры железа. Нет необходимости писать прямо в контроллер флопика или видеоадаптер, для того DOS и придумали. Хотя возможность есть ;)
vlivyur
А, ну тут уже мой косяк, недопонял.
Javian
Или участника демопарти.
Такие любители старого железа с публикациями на хабре встречаются - https://habr.com/ru/articles/953810/ https://habr.com/ru/articles/383497/ https://habr.com/ru/companies/ruvds/articles/790938/
Rigidus
Ответить решил потому, что сам я никогда не программировал на БК, у меня был спектрум. Зато сейчас у меня есть доступ к модели, которая не только отвечает на такие вопросы, но и делает их негодными для детекта олдфагов. Кажется скоро она сделает и меня ненужным: на пробу я дал ей задачу в своей области (разработка языков программирования и языковых виртуальных машин) и она сделала отличное, согласованное в плане фич решение. Которое, будем честными, я бы вымучивал куда дольше и не факт что справился бы: там фичи противоречат друг другу и реализация должна учитывать много контекстных нюансов.
Мне не по себе. Я занимаюсь довольно безобидными вещами. Представляю что возможно с такой согласованностью решений в менее мирных областях.
Я слежу за прогрессом последние пару лет. Глюков все меньше. Качество растет довольно сильно, получаемые решения требуют все меньше проверок. Мне требуется все меньше думать и согласовывать инварианты, все больше подразумеваемого контекста оказывается даже не нужно проговаривать, даже в весьма неочевидных аспектах. Промпты, которые я ввожу в экспериментальных целях, все ближе к способу говорить моего менеджера - с пятого на десятое, без всякой системы - но модель справляется, разжевывать приходится все меньше.
И да, у меня подписка за 20 баксов. Я даже не знаю, что могут те, у кого фронтир
Wesha
И тем не менее, как я написал, Ваша модель совершила несколько ошибок. Человек, который реально писал, такие вещи забыть не может — я сказал «частично правильно», потому что понимал, что Вам ну вот прям не терпится себя показать.
Rigidus
Я не спорю. Но года два назад там был бы вообще глюк на глюке. Что будет через год-два?
mrcashe
Шина у проца 1801ВМ1 была инверсная, так что там всё было инверсным.
FireFly111
Чувак, у меня 30 лет назад уже пентиум дома стоял, какой ещё БК?
Wesha
А знаете, не все жили в Москве и были миллионерами!
Kirthgreat4
Жги еще про здравый смысл у ллм, особенно когда она уверенно придумывает несуществующие методы в апи
amazingname
Ну так она проверит API, обломается и найдет существующее. А кожаные вообще в гороскопы верят.
Wesha
Ну так таких кожаных и не берут в
космонавтыпрограммисты!semmaxim
Когда у MiMo не скомпилировался мой пет-проектик после повышения версии библиотеки, то она сообразила и полезла на github, нашла там changelog, этот класс и примеры рядом, проанализировала их, поняла в чём проблема и исправила проектик. Сама.
lazy_val
Ровно та история, про которую я уже говорил:
Чел ненавидит свою работу программиста, и подсознательно писаниной на хабре пытается от нее избавиться - чтобы женам-детям-родителям и прочим иждивенцам заявить мол “все, LLM заменили всех программистов, больше кормить вас программированием не буду, а буду заниматься любимым делом”
Опять психиатрия в чистом виде.
amazingname
Это вы слишком глубоко копнули. Я как раз надеюсь, что каким то чудом потребность в ультра дешёвом и ультра эффективном софте вырастет на порядок, раздутые войтишниками компании по-сдуются без халявных денег, в отрасли останутся энтузиасты и я снова смогу выбирать что мне нравится вайбкодить, не сильно оглядываясь на деньги, как это было в тучные времена.
eao197
Таки не понято, если вы программировали на работе, то разве это было не за деньги?
amazingname
Сначала я работал начальником отдела автоматизации в госсекторе и одновременно в команде с друзьями. И сам выбирал что именно хочу программировать за те небольшие деньги. Потом работал в маленькой фирме за небольшую зарплату и потому тоже сам выбирал что и как мы будем писать. Потом работал в большом проекте, в который меня взяли за редкую экспертизу в предметной области. И опять деньги были так себе и я имел почти полную свободу написать наконец то что всю жизнь хотел по своему профилю.
И вот к 50 я переезжаю в ЕС, нахожу работу на галере и теперь уже деньги моя единственная мотивация... И тут да, плавно начинается ненависть к работе. Но потом я попадаю в команду которая пилит довольно интересное MCP решение и теперь оно опять не так плохо. Пока.
eao197
Спасибо за развернутый ответ.
И что, если не секрет?
Выглядит так, что только к 50 вы столкнулись с настоящим промышленным программированием.
RedCatX
Разве то что вы описали не приведёт к обратному эффекту? Когда люди станут легкозаменяемым и дешевым придатком к машине, энтузиасты станут уже не просто не нужны, но и нежелательны, а потребуются исполнительные винтики, готовые промптить по 10-12 часов в сутки за зарплату младшего офисного работника... Боюсь в таком мире выбирать что вайбкодить вам не придётся, а смотреть захочется исключительно на деньги. Ведь если результат вашего труда будет чрезвычайно дешев, то при возникновении любых проблем с ним, или потребности в расширении функционала, его просто выкинут целиком, и сгенерируют новый, силами таких как вы - вайбкодеров. Понравится ли вам заниматься таким сизифовым трудом, когда всё что будут от вас требовать, это скорость и точность формулировок, а в итоге - одноразовый продукт, который очень скоро полетит в помойку?
dalerank Автор
где-то я даже термин слышал про обесценивание труда разработчика, называется "пролетаризация программиста". Если будет время почитайте "Конец радуг", там как раз об этом рассказывается на примере главного героя, чьё прежнее мастерство исчезло (гениальность поэта не вернулась вместе с вылеченной памятью), и ему приходсятся заново собирать смысл жизни и творчество в перекроенном мире, садясь за парту рядом с подростками. Там правда про поэта, а не программиста, но очень близко... он умел то, что не умели большинство вокруг, а теперь это умеют все, пусть и не так хорошо.
amazingname
Там где люди станут легкозаменяемым придатком к машине заменят и людей тоже. Но экономика по своей сути требует чтобы люди все ещё оказывали услуги друг другу, потому что то что делает чисто машина стоит около 0 денег и не является частью экономики.
Кроме того, это все не собирается существовать к каком то стабильном состоянии. Напротив, все меняется постоянно и чем дальше тем быстрее.
И если в этой изменяющейся среде понимать ее немного лучше чем другие (быть энтузиастом), то вполне можно чувствовать себя свободно и хорошо.
Например, люди-винтики появились в IT как раз во времена относительного застоя, когда скорость работы процессоров почти перестала расти и технологии создания продуктов устоялись. Если бы посадить команду пилить продукт в 2015 или в 2024, то разница была нет так велика для 10 лет. А сейчас пойди найди специалиста, который знает как организовать разработку когда все вайбкодят.
Понятно, что все это теории и что будет на самом деле никто не знает.
amazingname
Я просто поражен с реакции. Люди, вы забыли что такое дискуссия. Вам больше не интересен чужой опыт. По идее сейчас все должны быть ультра-заинтересованы в вопросе как перестать думать о деталях и делегировать это агентам. Люди пишут кучу фреймворков в поисках этого грааля. Но здесь все преимущественно ищут подтверждения, что это невозможно. Зачем? А вброс спорного мнения больше не вызывает обмена и спора. Только негатив. Что то сломаЛось.
Newbilius
Отправьте свой комментарий LLM-ке, и попросите её накидать несколько гипотез о том, почему реакция на ваш комментарий вышла именно такой ;)
arsmerk777
да бро не реагируй ты так, просто по фану люди минусуют то что уже заминусовано
evtomax
Вот именно на деталях LLM и сыпятся, хотя в целом всё сгенерированное может выглядеть круто на первый взгляд.
select26
Коллега, вы просто забыли где вы находитесь!
True_form
По факту, да. Чем меньше ограничений и учше описана конечная цель - тем лучше и адекватнее агент работает. Потому что внезапно, за каждым действием стоит конечная бизнес цель.никто никогда не красит кнопочки ради покраски кнопочек, условно.
el_mago
Что подразумевается под "чем меньше ограничений?" Например, одна из важных инженерных задач - это формирование ряда ограничений для системы, узла, устройства и т.д.
amazingname
Имеются ввиду не целевые показатели типа быстродействия или требуемых функций а скорее микроменеджмент на пути достижения результата.
Типа такого https://www.businessinsider.com/anthropic-claude-code-prompting-tips-boris-cherny-micromanaging-ai-2026-7?IR=T
lazil
А это разве не про точность формулировок? ))
amazingname
Не про точность.
Я бы выделил эту концепцию на трёх уровнях.
Первое когда пишем одиночный промпт для не рассуждающий модели. Опыт показывает, что множество ограничивающих требований модель просто игнорит. А одно общее объяснение зачем все это использует эффективнее.
На втором уровне агентного кодинга аналогично. Если начать описывать каким должен быть код, результат бывает хуже чем если описывать каков должен быть результат и для чего, позволяя модели самой запланировать каким должен быть код.
На третьем уровне например, мы реализуем функцию, но не уверены что сделали все хорошо. Зовём фабла, чтобы он провел аудит, предложил что улучшить и запускаем доработки. Здесь модель по коду и нашим объяснениям понимает какую задачу решаем. И сама думает как ее решать лучше. От нас требуется понять ее решение, выбрать из вариантов но не формализовать.
Т .е. развитие использования АИ все время идёт по одной и той же логике - делегируется чем дальше тем больше. Нету никакой необходимости останавливаться и ограничивать АИ работой внутри формальных требований. Все развитие напротив идёт к схеме когда на стороне человека будет задача понимать что нужно и понимать правда ли то что предлагаем агент, это то что нужно.
То есть понимать а не формализовать.
lazil
Это всегда было так - нужно понимать.
Значит потом нужно еще проверить то, что агент нам предложил. Сомнительная оптимизация, особенно если надо рассматривать взаимодействие функций систему в целом. Чем выше уровень - тем труднее проверять.
amazingname
Опять таки. Спросите у агента и он разжует - агент может прекрасно критиковать свои решения. Кроме того, агент крайне редко предложит совсем плохое решение. В итоге предполагается, что мы выйдем на сходное качество как было, но с кратно меньшими затратами.
funca
Агент находится в информационном пузыре, созданном контекстом. Если в нем нет конкретных инструкций от вас, то польза от такой критики получается как от бабки на скамейке у подъезда. В самом деле, есть соблазн использовать техники коучинга, не погружаясь в детали, но с агентами это работает ещё хуже, чем с людьми.
Ohar
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
Wesha
А потом критика для критика, и для него тоже критика....
funca
Агент без контекста рефлексирует над формой, а не по существу, фактически играя в ассоциации. Так же, как это делает @Wesha) Хорошая разминка для ума, но практическая польза минимальна.
k4ir05
То есть, в том, что агент правильно выполнил задачу, вы не уверены, а в том, что он правильно выполнил задачу на создание агента-критика, вы уверены?
Wesha
А у него там дальше
черепахиагенты до самого низа!Wesha
А «крайне редко совсем плохое» и не надо — вполне достаточно сотни‑другой просто хреноватых.
Это из разряда «в каждой десятой (сотой, тысячной...) банке тушёнки марки „ИИ“ — сюрприз: бритвеннное лезвие!» (кюшайте, не обляпаятесь).
amazingname
Ну, не совсем так. AI в отличии от человека хорошо фокусируется на коде и поэтому вы никогда не увидите в коде AI типичных для человека багов, когда перепутан знак равно и не-равно или забыта проверка или сложное условие содержит грубую логическую ошибку. Вместо этого AI срезает углы, закидывая решениями на отцепись там, где надо было остановиться и обсудить детали с программистом. Но эти косяки как раз не так сложно обнаружить. Хуже когда решение учитывает почти все, но не совсем все. Тут как в случае человека, так и в случае AI помогает хорошее покрытие всех случаев тестами.
А еще я делал даже так. Делаю быстро на питоне MCP для созданного сервиса, подключаю клод к этому MCP и предлагаю тестить все мыслимое и немыслимое пока не обнаружит странное поведение или баг. Обычно находит баги прилично эффективнее тестировщиков. Хотя так проверять можно конечно не каждый модуль.
Wesha
Для типичных для человека.багов у нас единорог есть!
Зато увидим оведохуа нетипичных для человека.
Особенно когда оно их стабит, чтобы позеленели.
amazingname
С год назад он действительно так делал. Но последние пол года я не припомню таких фокусов. Или модели починили, или мой опыт стал больше.
Эти пол года работал только с опус 4.8
dalerank Автор
типичных для человека нет, новых аишных увидим вагон и пару прицепов
vlivyur
Не поверишь, но на программистах это точно так же работает лучше, чем просто сказать где взять и куда положить.
RomanPokrovskij
Троль прав, само наличие контекста не спасает прикладное программрование как профессию. Но контекст кто-то тоже передал машине. Или дообучил или вставил в запрос. В первом случае работа со статистикой на этапе дообучения, и там много очень точного и специфичного описания управления потоками данных и результатов, аналогичного кодингу. Во втором работа с поиском категорий чтобы подобрать контекст подходящий к запросу и уместится в лимите. Передача контекста машине это и есть программирование для кожаных. Не то чтобы это несможет ИИ, просто это уже не область прикладного программирования и "архитектор прикладного продукта" не захочет и не сможет так легко принять ответственность на себя да и некогда ему будет, не уровень "стратегического планирования". Его уровень начинается с "дайте мне дообученый/достроеный ии за три, ой две, копейки" .
Qwest_Prozto
Простой ответ - любая машина никогда не будет знать все об окружающем мире, контекст, допущения конкретно вашей задачи или запроса. Без этого никогда не будет экспертности в проекте или части кода. Клауд опус 5.55 может задать вопрос по неизвестным местам, но если вы не эксперт - откуда вам знать, что все вопросы заданы и вы на них корректно ответили? А если вы эксперт и все знаете - чем программирование с нейросетью отличается от программирования без нее?
feelamee
Кажется тут просто логическая ошибка. Переведем на людей:
любая человек никогда не будет знать все об окружающем мире
Без этого никогда не будет экспертности в проекте или части кода
=> вывод: не существует людей с окспертностью в проекте… Вывод, очевидно ложный. В реальности это неправда.
Kot_na_klaviature
Сразу вспоминается, как агент снял мидлварь аутх с роутов, так что все роуты попали гостям. Или как прописал принудительную аутентификацию в тесте где проверялась аутентификация. Или бесконечные фоллбэки маскирующие проблемы.
Главное не просить взять машину на автомойку если она в 50 метрах
Пока не видел ни одного проекта вайбкодера без вырвиглазного говнокода без архитектуры с дубликатами и тупостью на тупости. Правда в том, что для того, чтобы добиться качества от агента нужно прилагать большие усилия - сформировать контекст, вникнуть, итерациями заревьюить и исправить. По времени это недалеко от разработки руками. Нет никакой волшебной кнопки, которая делает стартап пока ты завтракаешь.
Wesha
amazingname
Смотрите, что я на самом деле написал в своем сообщении, если читать его как мнение программиста работающего с AI а не вброс "а теперь вас всех уволят":
1. Посыл статьи ошибочен, точность формулировок это не то что нужно для эффективного програмирования с AI. Про это сейчас говорят все. Только сегодня видел прямо это утверждение в новостях от создателя Claude Code.
2. Агенты понятливы - С этитм я вообще не знаю кто может спорить. Только наверно тот кто запустил китайскую модель, помучался пол часа и бросил.
3. Агентам свойствнен здравый смысл - Да, если агент знает все о проблеме, он крайне редко может принять глупое решение, скорее всего решение будет сбаллансированным. Человек часто находится под влиянием психологии - жалко выбрасывать уже проделанную работу, хочется применить заумное решение и показать всем что ты умный, хочется опробовать новую технологию. Ничего из этого не свойственно AI.
4. "От человека на данный момент нужно общее стратегическое понимание как все будет работать - какого рода алгоритмы, примерно что за данные, что будут проверять тесты, и определенная доля внимательности к деталям, чтобы не попасть на бессмысленно раздутую кодовую базу и неоптимальные по быстродействию решения." - это в точности то, что вы написали - волшебной кнопки пока нет, надо прилагать усилия. С лучшими моделями типа фабла этих усилий все меньше, это факт.
5. "Безопасность LLM уже анализируют на экспертном уровне" - Я не сказал что LLM пишет безопасные приложения. Я сказал что если его попросить найти уязвимости в коде, он сделает это лучше человека. Где я не прав?
Я вообще удивлен, что столь очевидное и распространенное в каких нибудь американских стартапах мнение воспринимается здесь как троллинг.
Kot_na_klaviature
От продавца лопат, который неожиданно хвалит лопаты.
Безопасность, понятливость и тд зависит от предоставленного контекста, на который нужно потратить время чтобы его сформировать. Вайбкодер создает контекст на нулевом уровне. Без контекста все модели пишут перепутанную зафоллбэченную лапшу, дубликаты без архитектуры и говнокод. И с ростом проекта эта проблема будет увеличиваться пока не начнутся известные проблемы, когда модель сама путается исправляет в одном месте и ломает в другом.
amazingname
Но где в статье или моем сообщении шла речь про "вайбкодера"?
Стандартная команда в стандартном аутсорсе работающая с гринфилда сейчас ставит какой нибудь BMAD и подымает продукт в 5 раз быстрее. При этом эти ваши "вайбкодеры" которые формируют с агентами спецификации там называются "архитекторы". Чистые девелоперы почти перестают быть нужны. А человеческое ревью полностью сводится к ревью архитектуры в коде. И как то у них всё работает.
k4ir05
Вы слишком антроморфизируете агентов. От этого исходят и остальные ложные выводы.
Не думали, что это может быть свойственно и вам в отношении AI?
eao197
Возможно это потому, что вы не говорите о каком именно программировании идет речь. Может вы занимаетесь тем, что читаете N полей из таблицы, отображаете их на форме, контролируете ввод пользователя на предмет того, что в число нельзя добавлять буквы, проверяете введенные значения на попадание в заданный диапазон, после чего записываете измененные поля обратно.
Wesha
...то есть тем, что кратко называется перекладыванием джейсонов.
eao197
По сути это тоже работа которую кому-то нужно работать и за которую вполне себе хорошо платят. Но эту работу на моей памяти всегда пытались автоматизировать и сводить к максимально декларативному виду.
amazingname
Конкретно мой опыт с агентами - средние относительно рутинные задачи. Типа добавить новые возможности во внутренний язык запросов для получения данных из базы с динамической схемой (когда все значения одного типа пихают в одну таблицу). Или переделать аутентификацию в сервисе под новые тенденции в проекте. Люди вокруг вайбкодят много чего покруче и много чего проще.