Comments 61
Разве промпт/спеки уже не стали новым языком программирования?
Нет, не стали.
Потому что никто не знает что это такое. И результат недерминируем как бросок кубика или поворот гача машины.
Чем более ответственная программа тем это несоответствие критичней.
Вы сможете ответить что должно быть в спецификации чтобы гарантированно корректно закрыть бизнес задачу и ничего не сломать? Критерий его полноты и качества.
Тут не каждый даже скажет что должно быть в бизнес задаче, чтобы её закрыть. :-)
А по факту, если в проекте при изменении или дополнении кода можно поломать не связанный код, то у меня для вас плохие новости. При нормальной организации проекта современные модели прекрасно разбираются где границы, за которые не надо выходить.
Речь же не про замену "код => ИИ", а про ""ручное программирование => автоматизированное программирование". Результат будет детерменированным ровно в той же степени, что и результат работы программиста
У вас в слове программирование куча ошибок. Правильно - кодирование.
Результат будет детерменированным ровно в той же степени, что и результат работы программиста
А в чём тогда польза?
Нет, я имел в виду как раз программирование, не выдумывайте за меня. Почти все процессы в существенной степени автоматизируются. Вообще, заметил, многие программисты усилено продвигают идею, что большую часть времени они "думают". Что абсолютно не так и является когнитивным искажением - думать хоть и самая русурсоемкая, но в тоже время и самая быстрая операция.
А в чём тогда польза?
В экономии времени, или улучшении качества, смотря как подходить к процессу разработки. Программист в любом случае пишет код итерациями, с ИИ итерации быстрее, оставшееся время можно тратить на повышение метрик качества, или траву курить трогать, кому что ближе
Вы наверное считаете что "думать" это только когда схема и логика но на самом деле думать приходится непрерывно то есть примерно "так, как запросить состояние текущего порта? ага у active_port запустить get_state ... Оо а их тут два второй с параметром чё там в комментах ага это туда можно AT команду закинуть прямо тут зачем это комуто понадобилось непонятно ... так а что он вернёт мне ага PortState верняк ведь long или int ну не моё дело это ... ну его теперь сохранить надо перед запуском теста так а на каком уровне то лучше тут или глобально ...итдитп" это всё постоянно занимает мозг и если это не "думать" то я уже и не знаю что такое "думать"
Нет, я имел в виду как раз программирование, не выдумывайте за меня.
Тогда я не понимаю, что вы подразумеваете под этим словом. И что значит "ручное программирование"? И чем оно отличается от автоматизированного?
Вообще, заметил, многие программисты усилено продвигают идею, что большую часть времени они "думают". Что абсолютно не так и является когнитивным искажением - думать хоть и самая русурсоемкая, но в тоже время и самая быстрая операция.
Почему вы думаете, что это не так? Что же, по-вашему, занимает большую часть времени? Разве во время чтения кода или документаций не нужно думать?
В экономии времени, или улучшении качества, смотря как подходить к процессу разработки.
Так сам процесс написания кода не так много времени занимает. Да и не всегда эта экономия получается на деле (зависит от некоторых факторов). А качество нынешние средства гарантировать не могут. Реально экономить время без потери качества поможет хороший инструментарий (вот тут может помочь ИИ), библиотеки, в каких-то случаях более высокоуровневые языки.
Программист в любом случае пишет код итерациями, с ИИ итерации быстрее, оставшееся время можно тратить на повышение метрик качества, или траву
куритьтрогать, кому что ближе
Лучше тратить его на проверку того, что натворил ИИ ;)
И да, тем более - кто знает, точно ли код который нагаллюциногенил ИИ работает? Автор пишет что "ИИ уже умеет писать код", но он видимо путает (или забыл) "писать" с "написал и заработало как должно быть"
Результат работы человека тоже в своем роде бросок кубика. Вы даёте задачу программисту, он ее как то делает. И мб даже результат похож на то, что было описано в ТЗ (не всегда). Но никто не гарантирует, что там нет критичных багов, плохой архитектуры и тому подобного.
Да, у вас может следовать код ревью, QA и все такое, понятно. Но и за работой ИИ может это все следовать.
Спеки именно как заменитель исходного кода не особенно то работают. Дьявол кроется в деталях, которые спеки не покрывают. Ну, или мы пока не знаем, как эти спеки правильно писать
мы пока не знаем, как эти спеки правильно писать
Мы уже десятки лет этого не знаем. Даже тяжёлые спецификации SRS на основе стандарта ISO/IEC/IEEE 29148:2011 не полны.
Но раньше гэп между спецификациями и кодом закрывал компетентный программист. А сейчас - никто.
Этот никто довольно умён, чтобы закрывать разрыв, но архитектурное видение у него пока хромает.
Надо сказать, проблема с тем, что по одним и тем же спекам можно написать две очень разные программы - не новая. Программист - существо даже менее детерминированное, чем LLM. Раньше это как-то считалось нормальным. Ныне спохватились
Программист, а особенно хорошая команда программистов, имеет нормальную память. У агентов с памятью, как ни обрабатывай и ни дистиллируй логи сессий, пока весьма дерьмовенько. Даже прекрасный Fable 5 забывает прямо на ходу прямые инструкции из скилла, загруженного меньше минуты назад, в почти пустом контексте. Потом при анализе пишет:the skill’s own gotcha text was independently re-verified empirically by the main agent (function f { return , @(1,2) } test), then still tripped it up once in its own placement-recheck script (see 1C) — the lesson was known but not internalized until it broke.
Not, б, internalized.
Этот никто довольно умён, чтобы закрывать разрыв
Закрывать разрыв не обоснованно, не учитывая ограничений и приоритетов корректного проекта, а по шаблону.
Это фигня
Как раз сейчас заметил, что если в мобильной версии хабра начать пересылать ссылку, но не скопировать её, а отменить действие, то вылезет ошибка. С номером 20 и описанием "share cancelled".
Как по мне, неплохой пример для гэпа. Не знаю, хотел ли какой-то менеджер знать, как часто люди отменяют действие, но вряд ли было прописано "покажи ошибку пользователю". А ведь человек сидел, размышлял, добавлял custom exception. Наверняка на слишком глобальном catch попался.
Даже тяжёлые спецификации SRS на основе стандарта ISO/IEC/IEEE 29148:2011 не полны.
Ну так можно же полную спецификацию написать
Я выскажу неочевидную аналогию. Чем более развито и образовано общество, тем сложнее и больше бюрократия. Не происходит упрощения управления/создания. Раньше вы просто собирали налоги, теперь вам надо построить на них ядерную бомбу. Легче и проще никогда не становится. И людей всегда надо все больше и больше. Все очень сильно усложнится.
Нужно больше людей, которые знают, что делать. А это совсем другое общество, оно сложнее буржуазного и управлять им очень сложно. Вот где проблема большая ждет.
пф, фантасты все уже придумали! просто приводим общество к высокотехнологичному дикарству и все
реальные ресурсы у кого надо, продукты пилятся узкими фрагментами что бы один идейный не мог нарушить работу всей системы,чем выше к "знаниям" тем выше тоталитаризм и конктроль
вон северная корея отлично илюстлирует этот подход, причем в самом лучшем виде с расслоением и высокотехнологичным дикарством, когда разрешенная тупая звонилка ведет слежку на зависть всем современным государствам (я про глубину и обьем данных)
Следующий момент Бэкуса...
...
Человек будет описывать:
цели
...
критерии правильности
Подтверждаю -- описывается.
ЗЫ: спецификация зачотная
Ору. Сидят ребята и верят, что программирование перейдет на новый уровень в ближайшем будущем... Нет, не перейдет!!! Если программа не запускается на железе, которое доступно большинству, это априори бесполезная программа, так как в любой момент жизни краник могут перекрыть. Любая революция в программировании как в науке о формальных языках сопровождалась соответствующей технологической революцией, до которой нам с LLM ещё как до Луны, если считать по массовости
Начнём с измеримого? Что у вас значит «ближайшее будущее»: 1, 5 или 10 лет? Без срока тезис «не перейдёт» нельзя проверить. И чем меряем массовость: домашним железом у большинства или промышленной доступностью среды разработки через облако/локальные станции?
Отвечу за товарища, с которым согласен в той части, что если fable или gpt сильно оторвутся от доступных на каждом компьютере интеллектов, то очень быстро их закроют для бесплатного пользования, а цена будет доступна только корпорациям. На каком железе оно будет работать в этом случае вторично. Т к именно открытость и доступность построила современный ит-мир. Графические интерфейсы появились на огромных мейнфреймах, но толк от них пришёл вместе с windows на "бабушкином" системнике, который был у каждой бабушки (аллегория разумеется) . Так и здесь будет. Пока толку от ии мало, а платным его уже начали делать. И мало того, стали чинить запреты на уровне стран, союзов и корпораций. Т е даже если есть деньги, не каждый сможет их заплатить... Массовое же внедрение произойдет на новой аппаратной базе, ну если быть оптимистичным то лет 5-7 надо. И это для текущих технологий, которые явно имеют ограничения. Что там дальше будет пока не ясно. Лично я думаю, что на этом мощность ИИ пока застопорится не только по причине отсутствия свежих идей и аппаратной базы, но и по причине, что экстенсивное увеличение моделей подошло к пределу и дальнейший рост числа параметров не даст роста мощности (кроме электрической потребляемой разумеется 😁)
Каждая крупная революция в программировании повышала уровень, на котором человек описывает машине свои намерения.
Это происходило когда компиляторы/интерпретаторы и документация были доступны и бесплатны.
В случае ИИ, "компиляторы" несогласованные, нестабильные, платные или требуют дорогого железа. Документаций к ним толком нет, они постоянно переписываются.
Компилятор пришлось доказывать делом.
Я вначале подумал что там было математическое доказательство работы компилятора, но решил проверить оригинал.
"The compiler had to earn trust through results."
Я бы перевел как "компилятору приходилось зарабатывать доверие при помощи результатов работы". Может это криво, но по крайней мере сохраняет смыл изначальной фразы.
Интересная параллель, только вот во время FORTRAN даже он не был способен обуздать сложность систем, которые разрабатываются сейчас на объекто-ориентированных, функциональных и SQL / NoSQL языках. В итоге если проводить параллель дальше - это приведет лишь к тому, что новый инструмент (пускай сейчас он называется ИИ, но не суть) просто позволит писать более сложные системы.
Генеративный ИИ сделал программный код дешёвым
Ну-ну. Лучшие модели весьма недешевые, при том что работают по сути в глубокий минус, и каждая новая требует все больше и больше ресурсов. А на выходе еще и код, который совсем не тот же самый код.
Это все круто. Только вот я сейчас сижу в монорепе и вспоминаю консольные команды работы с репозиториями. Мердж с плагином для VS CODE это блок нового кода и ниже блок старого. И это не 5 строчек кода. Так что до этих ваших ИИ еще далеко.
Бэкус дал программистам дистанцию от процессора.
Следующее поколение инструментов даст дизайнерам цифровых систем дистанцию от синтаксиса
Слишком по элэлэмски сформулировано. “Дистанция” здесь не подходит. Суть в “абстрагировании” от железа, а не в “дистанцировании”. По поводу синтаксиса, так он скорее “упрощается и унифицируется”. Уйдут “отступы/закорючки” со своим особым значением для каждого языка, помогающие компилятору понять назначение того или иного участка текста программы. Уйдут гетеры/сетеры. Изменится представление о “грамотном, красивом, чистом” коде.
Этакая компакт-ретроспектива программирования получилась. Правда автор забыл упомянуть известный Algol, который появился чуть попозднее Fortran'а, но шел с ним бок в бок все 60-ые.
Что касается ///ИИ способен быстро написать реализацию///, то для профессионалов данное утверждение сомнительное, если не сказать ложное. Ещё больше времени потребуется, чтобы разобраться в этой "писанине", доработать ее на надёжность, принятые стандарты разработки и документировать для дальнейшей техподдержки. Разработка серьезного ПО является инженерной работой, 1в1 повторяющий процесс и жизненный цикл сложного технического изделия со всеми вытекающими отсюда выводами. Разработка (не писание !) программного кода один из важных этапов этого процесса, но не главный. Было бы значительно лучше, если бы генеративный ИИ умел анализировать уже разработанный кем-то программный код на предмет его корректности и надёжности. В конечном же итоге, качество и надёжность программного обеспечения всегда будут зависеть от профессионализма разработчиков, а не от какого нибудь ИИ.
Мякотка в том, что сейчас оно обсуждается в кругу кодеров, которые могут кодить по-старому. Как только они исчезнут, неважно как, от старости ли, переучившись на вайбкодинг, отдав основную часть кодинга агентам, потому что так начали требовать корпоративные условия, всё начнет рушиться. Одинаковые ситуации приводят по большей части к одинаковым результатам. Это касается и кодеров на COBOLe и старичков инженеров, которых начали в США вытаскивать обратно на работу в возрасте 80-85 лет, потому что возникли проблемы с расконсервированием и восстановлением заводов по производству оружия (особенно арт.снарядов) ( https://www.cpijobs.com/2026/06/09/great-retirement-wave-manufacturing/ - 55 лет средний возраст в аэрокосмической отрасли и впк..), в ядерной энергетике забили тревогу, более 40% общего состава либо пенсионеры, либо уже почти.
Вот только в других отраслях стараются заботиться о таких проблемах заранее (как минимум есть списки имеющих компетенции и при наступлении проблем известно откуда их выдернуть даже с пенсии), а о кобольщиках (хотел написать "кобольдах", но все мои знакомые кодеры на этом языке, весьма отрицательно относятся к этому слову) вспомнили только когда они начали натурально умирать от старости.
Колесо, уважаемый, на Вашем автомобиле, небось, давно натурально умерло от старости несколько раз ? Никак бедному 2,5тыс.лет и, по вашей логике, давно ему бедному на покой и вперёд на автодроны. А если по серьезному, то принцип "что надёжно работает, то пусть и работает" верен не только для этого самого колеса, но и для всего остального, включая и программное обеспечение. К надёжному, функционально удовлетворяющему ПО термин "устаревает" не подходит в принципе. Об его устаревании могут рассуждать только люди называющими себя кодерами (не путать с разработчиками серьезного ПО !), либо дилетанты. На счёт COBOL'а, в частности, замечу, что один мой дальний знакомый и по сей день успешно на нем работает в Канаде на минитюаризированном мэйнфрайме IBM 370, который перемалывает софт разработанный как в 80'х, так и новый на "устаревших" COBOL'е, PL/I и Fortran'е.
Если мы не стукнемся о какой-то потолок в развитии ИИ в ближайшее время, то мне видится следующее будущее:
Традиционные языки программирования уйдут в прошлое. Они слишком формализованы и имеют слишком много ограничений для того, чтобы с ними мог работать человек. Аналогия: космическому кораблю, на котором летят люди, нужно чудовищное количество оборудования только для поддержания жизни людей. В то же время спутнику-роботу это всё не нужно, он может быть в 100 раз меньше, потреблять в 1.000 раз меньше энергии, но выполнять те же функции в зависимости от программы полёта.
В то же время и чистый машинный код не подходит. Потому что там всё должно быть очень сильно оптимизировано, и поэтому хранить какой-то контекст бизнес-логики гораздо сложнее чем в языке программирования. Тем более текст на ассемблере будет просто чудовищной длины, и это очень неэффективно с точки зрения потребления токенов.
Решением, скорее всего, будет создание агентом своего собственного языка для понимания кода именно агентом. Это представление будет очень богато контекстом. Агент сам будет добавлять или исключать какие-то функции из этого своего языка, в зависимости от конкретных нужд. Также он напишет компилятор который сможет быстро компилировать этот промежуточный формат уже в машинный код.
В результате основой для написания любого кода станет спецификация выработанная человеком в общении с агентом. Далее агент преобразует эту спецификацию в свой собственный язык программирования и компилирует по необходимости.
Да, мы потеряем контроль над непосредственно программным кодом. Но я всем советую почитать книжку Станислава Лема "Сумма технологий". Станислав Лем-это писатель-фантаст. Но именно эта книга является чуть ли не научной работой, просто написанной на доступном языке. Он там как раз по полочкам раскладывает возможное развитие будущего, где технологии станут саморазвивающимися, и человек просто не будет понимать что там внутри происходит, он будет видеть только результат.
Традиционные языки программирования уйдут в прошлое. Они слишком формализованы и имеют слишком много ограничений для того, чтобы с ними мог работать человек
Что значит слишком? Слишком для неподготовленного? Так любому ремеслу надо учиться. Они формализованы на столько, на сколько это требуется. Процессоры не могут выполнять неформализованные команды. Иначе может получится нежелательный результат. А естественные языки слишком неформализованные.
В результате основой для написания любого кода станет спецификация выработанная человеком в общении с агентом
А как убедиться, что агент правильно понял человека? Желательно до начала эксплуатации программы.
В языках программирования для людей очень много ограничений, которые не позволяют человеку выстрелить себе в ногу на каждом этапе долгого периода разработки.
Для ИИ это лишняя нагрузка. Если рассматривать продукт как черный ящик, обложенный чудовищным количеством тестов, то в принципе по барабану, что там внутри. Детальные спецификации того, что ИИ должен произвести как раз и будут защитой от того, что агент неправильно поймёт человека. Т.е. формализовать и ограничить нужно всё ту же часть процесса, где присутствует человек, а не ту, где пишется код.
В языках программирования для людей очень много ограничений, которые не позволяют человеку выстрелить себе в ногу на каждом этапе долгого периода разработки.
Вы не в ту сторону смотрите, либо судите с точки зрения естественных языков. ЯП не ограничивают, а наоборот - дают возможности. Много ли вы языков знаете? Есть языка, некоторые позволяют все ноги (и не только) отстрелить.
Если рассматривать продукт как черный ящик, обложенный чудовищным количеством тестов, то в принципе по барабану, что там внутри
А тесты откуда возьмутся? Это ведь такие же программы, которые нужно написать.
Детальные спецификации того, что ИИ должен произвести как раз и будут защитой от того, что агент неправильно поймёт человека. Т.е. формализовать и ограничить нужно всё ту же часть процесса, где присутствует человек, а не ту, где пишется код.
Если спецификацию будет писать человек, то это путь в никуда. Спецификация будет являться продуктом мозгового штурма команды людей и агентов. Люди будут хранителями бизнес-идеи, основных направлений проекта, предпочтений клиентов и т.д. А агенты займутся технической частью спецификации, выпытав у людей все нужные им подробности. Я уже давно делаю нечто отдалённо-подобное при составлении планов.
Такого же содержания мысли приходилось выслушивать от футурологов ИИ (AI) по теме "программирование для ЭВМ и ИИ" 40 и даже 50 лет назад.
Ну, с этой точки зрения, уже потеряли (или не потеряем в случае ЯП для ИИ - смотря как посмотреть). Сейчас очень малая доля программистов поймёт выхлоп дизассемблера. Но никто ж не говорит, что мы уже потеряли контроль над кодом, просто мало кому это нужно на таком низком уровне. И ЯП для ИИ тоже нужно будет стандартизировать, чтобы разные агенты и модели понимали, что они уже накодили, когда придёт черёд очередной фичи или багфикса. Ну или каждый раз переписывать проект с 0, каждый раз добавляя новые баги. А если будет стандарт, будут и средства для реверс-инжиниринга или трансляции ИИшного ЯП во что-то более человекочитаемое.
Не нужно стандартизировать. Предыдущая модель может по запросу подготовить специальную спецификацию данной конкретной версии своего языка для новой модели. Генерировать такой документ можно, например, при релизе очередной версии продукта
Приблизительно такого же содержания мысли приходилось выслушивать от футурологов ИИ (AI) по теме "программирование и ИИ" 40 и даже 50 лет назад.
Следующий «момент Бэкуса»: почему программирование снова готово подняться на уровень выше