Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 24
Я подвожу вас к выводу, что всегда было основой профессии программиста. Vibe coding не убрал необходимость точно формулировать задачу, а всего лишь сдвинул момент, когда вы платите за неточность формулировок. И получается, что проблему опять не решили, и решить её нельзя, но, как обычно, её можно вынести на уровень технического человека, только теперь его будут называть как‑то иначе Senior Opus Engineer, например, а лет через десять кто‑нибудь на Хабре напишет статью о том, откуда взялась новая профессия со своей зарплатной вилков. Согласны?
Вообще мимо. Не нужна никакая точность формулировок. Это все рассистские предрассудки кожаных. На практике чем меньше точных формулировок и чем больше общего описания что и зачем нужно, тем лучше результат. Потому, что всякий кто руководил живыми программистами а теперь агентом знает, что агента от живых программистов отличает понятливость и, внезапно, здравый смысл.
От человека на данный момент нужно общее стратегическое понимание как все будет работать - какого рода алгоритмы, примерно что за данные, что будут проверять тесты, и определенная доля внимательности к деталям, чтобы не попасть на бессмысленно раздутую кодовую базу и неоптимальные по быстродействию решения. Безопасность LLM уже анализируют на экспертном уровне.
При этом вообще не видно причин почему нельзя и это стратегическое понимание тоже перевалить на нейронки при дальнейшем их развитии.
И все это справедливо в этом месяце. А что будет через пол года никто не знает.
Просто смиритесь, что у вас больше нет принципиальных преимуществ перед машиной и не высасывайте из пальца причины почему все будет по старому.
И если что, я девелопер с 30 летним стажем, который работает в энтерпрайзе проекте, в среднем палит токенов на 1000$ в месяц и не пишет код руками уже с пол года вообще.
А тема про "детальные требования" которые готовит человек для меня выглядит абсолютно оторванной от того что происходит в моей работе и в нашей команде, и тем более от того что я слышу от принципал АИ инженеров в проекте. Эти ребята уже успели предписать своих фреймворков на подобие бимэд и грустно выдают философские формулировки типа "мозг можешь засолить в банку с огурцами".
Где все это на хабре? Или я живу в альтернативной реальности?
И если что, я девелопер с 30 летним стажем
Сейчас проверим. В чём особенность чтения/записи в регистр @#177714 на БК-0010? Как узнать, что клавиша на клавиатуре нажата и удерживается?
30 лет назад уже существовали PC с турбопаскалями ;) потроха БК тогда уже мало кому были интересны, кроме пары гиков.
На ассемблере я писал для радио 86 рк, и это был 8й класс. Что про него помню, что регистр запрета прерываний был выведен на динамик чтобы пищать. Загружать программу нужно было с магнитофона, зная адрес куда она пишется. Так можно было писать в цикле - загрузил ассемблер, загрузил программу, изменил программу, записал программу, запустил программу, увидел что система ушла на перезагрузку, сел думать где ошибка. Я написал помню диггера и аквариум с рыбками и водолазом как в игровом автомате. БК был у моего кореша, но там я только пробовал пару команд... на fokal что-ли.
Восторг от этого был неописуемый. По идее сейчас должен быть такой же от новых возможностей LLM, но уже конечно не то.
Мне кажется, тут есть ещё один аргумент в пользу вашего вывода, причём он почти не зависит от того, насколько хорош станет следующий Opus.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее. Всё это кто-то должен формализовать.
А затем нужен независимый от генератора слой проверки: тесты, типы, статический анализ, формальные методы, интеграционные стенды — в зависимости от задачи. То есть мало получить программу, нужно ещё иметь способ верифицировать её против требований.
И отсюда, кстати, забавный вывод про языки высокого уровня. Они нужны не только потому, что человек не умеет писать машинный код. Это удобный промежуточный слой, на котором можно выражать структуру системы, ограничения и свойства, о которых можно рассуждать и которые можно проверять. Причём он полезен и самой модели.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Более того, чем больше кода модель способна произвести за час, тем важнее становится этот второй слой. Иначе мы просто получаем очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт.
Поддержу - продукт кодосодержащий, идентичный натуральному, получать было легко еще во времена индийского кода, а это примерно давно. С тех пор подросло целое поколение. Граница, как и раньше проходит по формализации мышления, что отличает кодера от программиста. А кожаный кодер или песочный - не так уж и важно.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация
Классика жеж!
P.S. Нейрокартинка паровоза — низачот.
Эти рассуждения вполне применимы и к команде разработчиков. Кто-то принимает десятки решений по каждым мелочам, и как-то нужно решить, получилось ли то, что задумано.
Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Когда задаёшь промпт погонщику агентов, он именно этими вещами и занимается.
очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт
Всё отличие от предыдущего состояния индустрии заключается в словах "очень быстрый".
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее.
Вполне себе спецификация. Ибо есть и формальные описания и главное - куча примеров. Создать по аналогии - не подходит?
А картинка паровоза таки да - отстой.
И что вы по этой спецификации ожидаете? Копию одной из операционки? Или некую сборную солянку в произвольных пропорциях из произвольного набора? Только зачем такая операционка нужна, если можно взять готовую?
Я ожидаю нЕчто, что можно назвать операционной системой. "Зачем" - это вы себя спрашивайте. В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось. Заметьте - я не обсуждаю нужность\полезность написания. Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают. TR-DOS помещался на дискете 360 КБ. И ещё место оставалось.
"Зачем" - это вы себя спрашивайте.
Так не я же оправдываю такую "спецификацию". Мне такое вообще не нужно.
В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось.
А спецификации без назначения бывают? Стоит тогда уточнить термин спецификация.
Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают.
Что-то у меня эти предложения не стыкуются вместе.
Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мира и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
"Посчитай сотрудникам премии за квартал" работает только в сработанном коллективе, где этот весь контекст уже известен и все понимают главбуха, что именно он имел ввиду. А вот если приходит такой главбух к программистам и говорит: "хочу программу, чтоб считала премии за квартал", то у живого программиста совсем другой опыт и знания, так что ему придется все эти ваши вопросы задавать, и если программист чуть более опытный, еще и фиксировать в ТЗ на подпись, чтоб потом не было от главбуха: "а я совсем другое говорил!".
И вот-это ТЗ, это ТЗ на то, как должен выглядеть результат. Вариантов реализации по прежнему бесчисленное множество. Так вот, в отличии от времен изобретения Кобола и Сиквела, теперь это ТЗ можно напрямую засунуть в кодинг тулзы и получить нечто, что будет работать и выдавать результат по ТЗ. И даже на очевидных неопределенностях кодинг тулзы будут вопросы задавать: как сделать, вот-так, или так? И вместо выбора из предложенных вариантов, можно текстом ему написать какой-то новый вариант, которого нет в списке, и он поймет и сделает по-нему.
как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
А это сейчас кто-то, кроме заказчика, может это проверить? И не ссылайтесь на техзадание, это просто бумажка - зад исполнителя прикрыть. А ещё - чистосердечное признание в том, что компетенция разработчика недостаточна для понимания замысла заказчика, и требуется разжевать и в рот положить. И для его реализации - тоже. И не надо рассказывать, что заказчик не знает, что ему надо. Знает. Просто в 99% случаев квалификации исполнителей не хватает. И начинаются упрощения.
Наконец-то настанет светлое будущее, когда заказчик будет платить деньги за то, что ему надо, а не за то, что смогли наваять и теперь ему втюхивают.
Статья одной картинкой
А, извините, @Wesha раньше успел.
Кстати, любителям английского предлагаю догадаться, для чего именно предназначен метод record_changes() в незнакомом коде: записывает в базу изменения, произошедшие в некоем объекте (записать_изменения()) — или представляет собой хук, который вызывается, когда система обнаруживает изменения в некой записи (запись_изменяется()). True story, bro.
Не хватает цитаты из Совершенного кода (2004).
За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — автоматическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улучшения, и общими усилиями они сделали программирование абсолютно неузнаваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инноваций не устранила программирования как такового."
Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инструментах — программистам приходится бороться с несовершенством реального мира; нам нужно досконально продумывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с плохо определенными интерфейсами с другими программными и аппаратными средствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования.
Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтб делать, и эта деятельность будет называться программированием. Когда вы слышите заявления о том, что «новый инструментарий устранит необходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Английский вместо кода