Comments 192
Я подвожу вас к выводу, что всегда было основой профессии программиста. Vibe coding не убрал необходимость точно формулировать задачу, а всего лишь сдвинул момент, когда вы платите за неточность формулировок. И получается, что проблему опять не решили, и решить её нельзя, но, как обычно, её можно вынести на уровень технического человека, только теперь его будут называть как‑то иначе Senior Opus Engineer, например, а лет через десять кто‑нибудь на Хабре напишет статью о том, откуда взялась новая профессия со своей зарплатной вилков. Согласны?
Вообще мимо. Не нужна никакая точность формулировок. Это все рассистские предрассудки кожаных. На практике чем меньше точных формулировок и чем больше общего описания что и зачем нужно, тем лучше результат. Потому, что всякий кто руководил живыми программистами а теперь агентом знает, что агента от живых программистов отличает понятливость и, внезапно, здравый смысл.
От человека на данный момент нужно общее стратегическое понимание как все будет работать - какого рода алгоритмы, примерно что за данные, что будут проверять тесты, и определенная доля внимательности к деталям, чтобы не попасть на бессмысленно раздутую кодовую базу и неоптимальные по быстродействию решения. Безопасность LLM уже анализируют на экспертном уровне.
При этом вообще не видно причин почему нельзя и это стратегическое понимание тоже перевалить на нейронки при дальнейшем их развитии.
И все это справедливо в этом месяце. А что будет через пол года никто не знает.
Просто смиритесь, что у вас больше нет принципиальных преимуществ перед машиной и не высасывайте из пальца причины почему все будет по старому.
И если что, я девелопер с 30 летним стажем, который работает в энтерпрайзе проекте, в среднем палит токенов на 1000$ в месяц и не пишет код руками уже с пол года вообще.
А тема про "детальные требования" которые готовит человек для меня выглядит абсолютно оторванной от того что происходит в моей работе и в нашей команде, и тем более от того что я слышу от принципал АИ инженеров в проекте. Эти ребята уже успели предписать своих фреймворков на подобие бимэд и грустно выдают философские формулировки типа "мозг можешь засолить в банку с огурцами".
Где все это на хабре? Или я живу в альтернативной реальности?
И если что, я девелопер с 30 летним стажем
Сейчас проверим. В чём особенность чтения/записи в регистр @#177714 на БК-0010? Как узнать, что клавиша на клавиатуре нажата и удерживается?
30 лет назад уже существовали PC с турбопаскалями ;) потроха БК тогда уже мало кому были интересны, кроме пары гиков.
Те что стали программистами в 96 как раз успели покодить на БК, синклерах, векторах в конце 80х.
Блин, карма все летит вниз. Это ж сколько неолудитов и цепанул своим вбросом на вентилятор, мать моя.
30 лет назад уже существовали PC с турбопаскалями ;) потроха БК тогда уже мало кому были интересны, кроме пары гиков.
А вот давайте Вы не будете нам (ну или как минимум мне) рассказывать... 30 лет назад был 1996 год, самый расцвет БК. Ммм, синтезатор речи, умещающийся в 15,5 килобайт...
А PC с турбопаскалями да, существовали. В учреждениях. Разобыть чудо зарубежной технической мысли себе домой было практически нереально (хотя исключения бывали, да). Особенно с учётом того, сколько оно стоило. Мой первый писюк оказался у меня потому, что продали бабушкину квартиру.
В каждой избушке свои погремушки, конечно же. Прикиньте, существовали люди, которых расцвет БК не коснулся ;) А PC можно и из бу частей собрать; они подходят :)
В 1996 году мы в школе дискетами с играми менялись, пентиумы и 486 были у 2-3х человек в моем классе и в параллельных еще больше. Урал. Стоил комплект Пентиума с монитором 5 900 000 руб, да хватило только на пень 120 вместо модного 133 и элт монитор 14" вместо 15" и среди продвинутой школоты считался нищим) но это примерно 1000 $ по тем деньгам сумма подьемная для многих, знать бы зачем). В журналах тех времен разгоняли тезис, ну как можно иметь авто за несколько тыс $ но не хотеть купить компьютер. Квартиры на видеомагнитофоны и подержанные авто да меняли но чуть раньше). В 2000м я уже сайты на Perl под яндекс загружал на Valuehost)
Вы шутите? У меня, студента, в 1994 году появился личный PC AT 386, и на тот момент БК воспринимался как что-то уже устаревшее. Родители - обычные инженеры, никто квартиру не продавал.
не так. я синклер 128, собрал в 1992, в этот же год появились дисководы 5,25.БК действительно уже были неинтересны к этому времени. Расцвет синклеров, самиздат газетки это 1990 - 1993 год, далее они уже никому небыли нужны. В лицее у нас уже был класс на 80286 подареный американцами. в 1993 я перешел в универ - и там были СМ черно зеленые с бобинами ленты в соседней комнате и разобранные к утилизации читалки перфокарт. на некоторых кафедрах были Искры с картриджами и некое изобретение стран восточного блока под названием ЕС. к весне 1994 появились 80286,80386 и к 1995 году 80486 ну и далее это понятно. Понятно что паскаль, нортон, винда 3.1 и всякая остальная дичь
Рассвет ли? Мои данные никак нельзя назвать полными, но тут, похоже, закат
Почему именно БК? Почему не ZX и не любой другой советский ПК, десятки их? Мне кажется, были бы тут спектрумисты - они бы заявили: "А вот в 95 был самый пик ZX..."
Я так понимаю, дяденька — менеджер (ну, коли расцвет у него определяется по количеству новых продуктов, а не по их общему количеству)?
У меня логика простая: если в РФ писали/портировали игры под БК больше всего в 1992ом, а в 1996 это уже были единичные случаи - значит и пик популярности был в 1992ом. Никто не станет программировать под устаревающую платформу, все переходят на новую. Оно как-то ещё по инерции живёт несколько лет, но популярность всё равно неумолимо падает. А у вас, вероятно, когнитивное искажение, сформированное вашим личным опытом.
Я бы в 2005ом ответил, что Dendy - популярная приставка. Но насколько бы это соответствовало реальности?...
А вы складской работник, коли определяете расцвет по общему количеству, а не по количеству используемых?
Не знаю как у вас, а нам в среднюю школу обычного областного центра завели IBM PS/2
Правда с винтом был толко учительский но в то время 1.44 Mb хватало на все …
Вам, наверно, забыли сообщить, что школа специальная (в хорошем смысле).
У нас тоже — но в одну. Из нескольких десятков.
В моей школе в "компьютерном классе" стояли Микроши и железная дверь, которая не открывалась никогда, так как занятий информатики у нас не было. Про Микроши я узнал только потому, что однажды по какой-то причине не нашлось класса для проведения урока то ли по русскому, то ли по математике, и железную дверь открыли.
Ну если по “чесноку” то в 96 БК уже отошла, оставались единицы кто с ними общался. Тогда уже на развалах были платы РС и АТ в домашнем варианте использовался “Поиск” его брали готовым или паяли сами.
У нас в школе компьютерный класс с БК открылся году в 89. В 95м там уже стоял аж целая одна ЕС ЭВМ. В УПК занятия в то же время проходили на Intel 386 с FoxPro. А дальше только больше. Так что 96й год это уже был закат БК и домой добровольно его уже никто не брал, все мечтали об IBM PC.
В 1996 году у меня, студента второго курса, уже была PC с 486SX. БК к этому времени все повыкидывали нахрен. Я их видел в средне-школьные времена разве что, году в 90м.
Это в Москве, конечно. Мы там были зажравшиеся.
На ассемблере я писал для радио 86 рк, и это был 8й класс. Что про него помню, что регистр запрета прерываний был выведен на динамик чтобы пищать. Загружать программу нужно было с магнитофона, зная адрес куда она пишется. Так можно было писать в цикле - загрузил ассемблер, загрузил программу, изменил программу, записал программу, запустил программу, увидел что система ушла на перезагрузку, сел думать где ошибка. Я написал помню диггера и аквариум с рыбками и водолазом как в игровом автомате. БК был у моего кореша, но там я только пробовал пару команд... на fokal что-ли.
Восторг от этого был неописуемый. По идее сейчас должен быть такой же от новых возможностей LLM, но уже конечно не то.
В чём особенность чтения/записи в регистр
@#177714на БК-0010?
Это не 30, а 35 лет тому.
Насколько помню, этот 16-битный регистр выводился на разъём типа СНП-59-64. Можно было подключить принтер, джойстик и т.д. 16 выходов, 16 входов.
Примечательно, что readback там не было: запись шла в одну пару регистров, а чтение - из другой.
запись шла в одну пару регистров, а чтение - из другой
Схемотехника проще.
Примечательно, что readback там не было: запись шла в одну пару регистров, а чтение — из другой.
Нейрослоп детектед: добавление правдоподобных, но неправильных подробностей («СНП-59-64» — никто зубодоробительных кодовых номеров мелких деталей не помнил, вот микросхем — то да. Спасибо ещё, что хоть эта колодка действительно существует в природе, и с первого взгляда даже похожа — но не она), а также вроде бы правильных (с первого взгляда), но по факту — неправильных деталей (какая ещё «пара регистров», когда спрашивалось про один?)
Я по образованию инженер-электронщик, моного чего помню. На БКшках кодил года 3, пока не прикупил 286.
Физически на плате было 4 микросхемы, подключённые к этому адресу. Кажется, К589ИР12. Они 8-битные. 2 на вывод, 2 на ввод.
Ровно 30 лет назад у меня в Уральской глубинке был Пень-120 с Windows 95, Делфи и Visual с++
По одному адресу 177714 находятся два физически разных 16-разрядных регистра. Поэтому прочитать обратно только что записанное значение нельзя: при чтении процессор получит текущее состояние входных контактов, а не выходной защёлки. Кроме того, сигналы порта инверсные: записанный программой 1 соответствует низкому уровню на выходе, и низкий уровень на входном контакте читается как 1
Проверка удерживаемой клавиши - для этого используется бит 6 регистра 177716 - равен 0 - хотя бы одна обычная клавиша нажата.
Для случая, когда пользователь нажимает только одну клавишу, удержание определяют косвенно:
Получают код нового нажатия через
177662.Запоминают этот код.
Через нужное время снова проверяют бит 6 регистра
177716.Если бит всё ещё равен нулю — считают запомненную клавишу удерживаемой.
Если что - я не изначальный автор комментария, которого Wesha решил вывести на чистую воду.
Если что - я не изначальный автор комментария,
...однако почему-то тем не менее решили на него ответить, частично спалить правильный ответ, и заставить меня придумывать новый вопрос для детектирования нас, олдфагов.
Кстати, не до конца правильно — у Вас один шаг пропущен, а в другом — ошибка.
вопрос для детектирования нас, олдфагов
Знание про существование регистров само по себе указывает на олдфажество ;)
Или на использование гопоты.
Или что учебная программа отстаёт на 40 лет и кто-то учил системное программирование по MS-DOS и DEBUG.EXE в 2020 году. Хотя так ли уж это плохо? Зато в 2026 драйверы пишут нейрослопом без всяких "регистров".
кто-то учил системное программирование по MS-DOS и DEBUG.EXE
MS DOS до регистров не опускается, там INT10, INT21 и прочая олдовая магия.
Да и не пофиг ли?
Во времена MSDOS было два типа регистров.
Регистры процессора, AX, BX и т.д. И как раз перед вызовом INT надо было заполнить нужные регистры, а по возврату прочитать результат из регистров.
Аппаратные регистры оборудования, которые прямо или косвенно адресовались через порты. Например, порт 3D4h - выбор регистра контроллера CGA, 3D5h - запись в выбранный регистр, 3D8h - запись в регистр установки режима CGA.
И, собственно, ни те ни другие регистры никуда и не делись, просто остались на самом нижнем уровне, скрытые от большинства программистов несколькими слоями абстракций.
Если задача - выявление истинных олдскульщиков, то нужно давать более сложные вопросы, которые не пройдут ни нейросети, ни молодёжь. И не только по БК. Нужно что-то более жёсткое по отсеву и с несколькими подвохами по содержанию. В противном случае даже я набираю баллы.
А что до MS-DOS... Так и запишем: ассемблерные инструкции in, out вместе с регистрами процессора ax, bx, cx, dx - мне в страшном сне приснились. Хотя если бы не они, я бы так и не понял, что меня тянет к "железу".
Если задача - выявление истинных олдскульщиков
В каком возрасте вы спаяли/собрали свой первый компьютер? Написали первую игру?
:)
Первый раз пытался перебить листинг игры на BASIC из книжки в Educational Computer 2000 в 8 лет (и сразу нарвался на опечатки в исходниках), тогда же - первый Hello World, позднее в школе "паскалил" всякое. Компьютер собрал аж на 11 лет позже. А паять... Толком не научился, как и делать всё остальное: я пока специалист разряда "на все руки мастер, только руки из @#$%"
пытался перебить листинг игры на BASIC из книжки
Вы приняты :)
Ох уж мне эта молодьож. Ничо без компьютера не умеет,
даже программировать
Так вот кто изобрел кросс компиляцию.. писать на бумажке код для компьютера, необычное ;)
А вот тут вы меня недооценили, уважаемый @Wesha
давным-давно...
Интересно, как это она не опускается до регистров? А как же тогда все эти int 21h получают параметры?
Или участника демопарти.
Такие любители старого железа с публикациями на хабре встречаются - https://habr.com/ru/articles/953810/ https://habr.com/ru/articles/383497/ https://habr.com/ru/companies/ruvds/articles/790938/
...однако почему-то тем не менее решили на него ответить...
Ответить решил потому, что сам я никогда не программировал на БК, у меня был спектрум. Зато сейчас у меня есть доступ к модели, которая не только отвечает на такие вопросы, но и делает их негодными для детекта олдфагов. Кажется скоро она сделает и меня ненужным: на пробу я дал ей задачу в своей области (разработка языков программирования и языковых виртуальных машин) и она сделала отличное, согласованное в плане фич решение. Которое, будем честными, я бы вымучивал куда дольше и не факт что справился бы: там фичи противоречат друг другу и реализация должна учитывать много контекстных нюансов.
Мне не по себе. Я занимаюсь довольно безобидными вещами. Представляю что возможно с такой согласованностью решений в менее мирных областях.
Я слежу за прогрессом последние пару лет. Глюков все меньше. Качество растет довольно сильно, получаемые решения требуют все меньше проверок. Мне требуется все меньше думать и согласовывать инварианты, все больше подразумеваемого контекста оказывается даже не нужно проговаривать, даже в весьма неочевидных аспектах. Промпты, которые я ввожу в экспериментальных целях, все ближе к способу говорить моего менеджера - с пятого на десятое, без всякой системы - но модель справляется, разжевывать приходится все меньше.
И да, у меня подписка за 20 баксов. Я даже не знаю, что могут те, у кого фронтир
Кроме того, сигналы порта инверсные: записанный программой 1 соответствует низкому уровню на выходе, и низкий уровень на входном контакте читается как 1
Шина у проца 1801ВМ1 была инверсная, так что там всё было инверсным.
Чувак, у меня 30 лет назад уже пентиум дома стоял, какой ещё БК?
Жги еще про здравый смысл у ллм, особенно когда она уверенно придумывает несуществующие методы в апи
Ну так она проверит API, обломается и найдет существующее. А кожаные вообще в гороскопы верят.
Когда у MiMo не скомпилировался мой пет-проектик после повышения версии библиотеки, то она сообразила и полезла на github, нашла там changelog, этот класс и примеры рядом, проанализировала их, поняла в чём проблема и исправила проектик. Сама.
Ровно та история, про которую я уже говорил:
Всю принципиально программировал только те вещи которые мне нравятся и был счастлив. Утром за чаем и в транспорте не мог дождаться когда же попаду на работу и начну делать очередную задачу. В 48 лет в силу обстоятельств лет решил заняться программированием чисто за деньги. Теперь живу в тоскливом бесконечном тоннеле боли, страдания и отстутствия смысла. Все время заставлять себя заниматься работой, все время изучать то что не хочется изучать и обсуждать с людьми то на что мне по сути пофиг, все время доказывать что ты хороший специалист - сплошная боль каждый день.
Чел ненавидит свою работу программиста, и подсознательно писаниной на хабре пытается от нее избавиться - чтобы женам-детям-родителям и прочим иждивенцам заявить мол “все, LLM заменили всех программистов, больше кормить вас программированием не буду, а буду заниматься любимым делом”
Опять психиатрия в чистом виде.
Это вы слишком глубоко копнули. Я как раз надеюсь, что каким то чудом потребность в ультра дешёвом и ультра эффективном софте вырастет на порядок, раздутые войтишниками компании по-сдуются без халявных денег, в отрасли останутся энтузиасты и я снова смогу выбирать что мне нравится вайбкодить, не сильно оглядываясь на деньги, как это было в тучные времена.
Таки не понято, если вы программировали на работе, то разве это было не за деньги?
Сначала я работал начальником отдела автоматизации в госсекторе и одновременно в команде с друзьями. И сам выбирал что именно хочу программировать за те небольшие деньги. Потом работал в маленькой фирме за небольшую зарплату и потому тоже сам выбирал что и как мы будем писать. Потом работал в большом проекте, в который меня взяли за редкую экспертизу в предметной области. И опять деньги были так себе и я имел почти полную свободу написать наконец то что всю жизнь хотел по своему профилю.
И вот к 50 я переезжаю в ЕС, нахожу работу на галере и теперь уже деньги моя единственная мотивация... И тут да, плавно начинается ненависть к работе. Но потом я попадаю в команду которая пилит довольно интересное MCP решение и теперь оно опять не так плохо. Пока.
Разве то что вы описали не приведёт к обратному эффекту? Когда люди станут легкозаменяемым и дешевым придатком к машине, энтузиасты станут уже не просто не нужны, но и нежелательны, а потребуются исполнительные винтики, готовые промптить по 10-12 часов в сутки за зарплату младшего офисного работника... Боюсь в таком мире выбирать что вайбкодить вам не придётся, а смотреть захочется исключительно на деньги. Ведь если результат вашего труда будет чрезвычайно дешев, то при возникновении любых проблем с ним, или потребности в расширении функционала, его просто выкинут целиком, и сгенерируют новый, силами таких как вы - вайбкодеров. Понравится ли вам заниматься таким сизифовым трудом, когда всё что будут от вас требовать, это скорость и точность формулировок, а в итоге - одноразовый продукт, который очень скоро полетит в помойку?
где-то я даже термин слышал про обесценивание труда разработчика, называется "пролетаризация программиста". Если будет время почитайте "Конец радуг", там как раз об этом рассказывается на примере главного героя, чьё прежнее мастерство исчезло (гениальность поэта не вернулась вместе с вылеченной памятью), и ему приходсятся заново собирать смысл жизни и творчество в перекроенном мире, садясь за парту рядом с подростками. Там правда про поэта, а не программиста, но очень близко... он умел то, что не умели большинство вокруг, а теперь это умеют все, пусть и не так хорошо.
Разве то что вы описали не приведёт к обратному эффекту? Когда люди станут легкозаменяемым и дешевым придатком к машине, энтузиасты станут уже не просто не нужны, но и нежелательны,
Там где люди станут легкозаменяемым придатком к машине заменят и людей тоже. Но экономика по своей сути требует чтобы люди все ещё оказывали услуги друг другу, потому что то что делает чисто машина стоит около 0 денег и не является частью экономики.
Кроме того, это все не собирается существовать к каком то стабильном состоянии. Напротив, все меняется постоянно и чем дальше тем быстрее.
И если в этой изменяющейся среде понимать ее немного лучше чем другие (быть энтузиастом), то вполне можно чувствовать себя свободно и хорошо.
Например, люди-винтики появились в IT как раз во времена относительного застоя, когда скорость работы процессоров почти перестала расти и технологии создания продуктов устоялись. Если бы посадить команду пилить продукт в 2015 или в 2024, то разница была нет так велика для 10 лет. А сейчас пойди найди специалиста, который знает как организовать разработку когда все вайбкодят.
Понятно, что все это теории и что будет на самом деле никто не знает.
Я просто поражен с реакции. Люди, вы забыли что такое дискуссия. Вам больше не интересен чужой опыт. По идее сейчас все должны быть ультра-заинтересованы в вопросе как перестать думать о деталях и делегировать это агентам. Люди пишут кучу фреймворков в поисках этого грааля. Но здесь все преимущественно ищут подтверждения, что это невозможно. Зачем? А вброс спорного мнения больше не вызывает обмена и спора. Только негатив. Что то сломаЛось.
Отправьте свой комментарий LLM-ке, и попросите её накидать несколько гипотез о том, почему реакция на ваш комментарий вышла именно такой ;)
да бро не реагируй ты так, просто по фану люди минусуют то что уже заминусовано
Вот именно на деталях LLM и сыпятся, хотя в целом всё сгенерированное может выглядеть круто на первый взгляд.
Я просто поражен с реакции.
Коллега, вы просто забыли где вы находитесь!
По факту, да. Чем меньше ограничений и учше описана конечная цель - тем лучше и адекватнее агент работает. Потому что внезапно, за каждым действием стоит конечная бизнес цель.никто никогда не красит кнопочки ради покраски кнопочек, условно.
чем больше общего описания что и зачем нужно
А это разве не про точность формулировок? ))
Не про точность.
Я бы выделил эту концепцию на трёх уровнях.
Первое когда пишем одиночный промпт для не рассуждающий модели. Опыт показывает, что множество ограничивающих требований модель просто игнорит. А одно общее объяснение зачем все это использует эффективнее.
На втором уровне агентного кодинга аналогично. Если начать описывать каким должен быть код, результат бывает хуже чем если описывать каков должен быть результат и для чего, позволяя модели самой запланировать каким должен быть код.
На третьем уровне например, мы реализуем функцию, но не уверены что сделали все хорошо. Зовём фабла, чтобы он провел аудит, предложил что улучшить и запускаем доработки. Здесь модель по коду и нашим объяснениям понимает какую задачу решаем. И сама думает как ее решать лучше. От нас требуется понять ее решение, выбрать из вариантов но не формализовать.
Т .е. развитие использования АИ все время идёт по одной и той же логике - делегируется чем дальше тем больше. Нету никакой необходимости останавливаться и ограничивать АИ работой внутри формальных требований. Все развитие напротив идёт к схеме когда на стороне человека будет задача понимать что нужно и понимать правда ли то что предлагаем агент, это то что нужно.
То есть понимать а не формализовать.
на стороне человека будет задача понимать что нужно
Это всегда было так - нужно понимать.
понимать правда ли то что предлагаем агент, это то что нужно.
Значит потом нужно еще проверить то, что агент нам предложил. Сомнительная оптимизация, особенно если надо рассматривать взаимодействие функций систему в целом. Чем выше уровень - тем труднее проверять.
Значит потом нужно еще проверить то, что агент нам предложил. Сомнительная оптимизация, особенно если надо рассматривать взаимодействие функций систему в целом. Чем выше уровень - тем труднее проверять.
Опять таки. Спросите у агента и он разжует - агент может прекрасно критиковать свои решения. Кроме того, агент крайне редко предложит совсем плохое решение. В итоге предполагается, что мы выйдем на сходное качество как было, но с кратно меньшими затратами.
Агент находится в информационном пузыре, созданном контекстом. Если в нем нет конкретных инструкций от вас, то польза от такой критики получается как от бабки на скамейке у подъезда. В самом деле, есть соблазн использовать техники коучинга, не погружаясь в детали, но с агентами это работает ещё хуже, чем с людьми.
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
А потом критика для критика, и для него тоже критика....
Агент без контекста рефлексирует над формой, а не по существу, фактически играя в ассоциации. Так же, как это делает @Wesha) Хорошая разминка для ума, но практическая польза минимальна.
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
То есть, в том, что агент правильно выполнил задачу, вы не уверены, а в том, что он правильно выполнил задачу на создание агента-критика, вы уверены?
То есть, в том, что агент правильно выполнил задачу, вы не уверены, а в том, что он правильно выполнил задачу на создание агента-критика, вы уверены?
А у него там дальше черепахи агенты до самого низа!
агент крайне редко предложит совсем плохое решение.
А «крайне редко совсем плохое» и не надо — вполне достаточно сотни‑другой просто хреноватых.
Это из разряда «в каждой десятой (сотой, тысячной...) банке тушёнки марки „ИИ“ — сюрприз: бритвеннное лезвие!» (кюшайте, не обляпаятесь).
Ну, не совсем так. AI в отличии от человека хорошо фокусируется на коде и поэтому вы никогда не увидите в коде AI типичных для человека багов, когда перепутан знак равно и не-равно или забыта проверка или сложное условие содержит грубую логическую ошибку. Вместо этого AI срезает углы, закидывая решениями на отцепись там, где надо было остановиться и обсудить детали с программистом. Но эти косяки как раз не так сложно обнаружить. Хуже когда решение учитывает почти все, но не совсем все. Тут как в случае человека, так и в случае AI помогает хорошее покрытие всех случаев тестами.
А еще я делал даже так. Делаю быстро на питоне MCP для созданного сервиса, подключаю клод к этому MCP и предлагаю тестить все мыслимое и немыслимое пока не обнаружит странное поведение или баг. Обычно находит баги прилично эффективнее тестировщиков. Хотя так проверять можно конечно не каждый модуль.
вы никогда не увидите в коде AI типичных для человека багов
Для типичных для человека.багов у нас единорог есть!
Зато увидим оведохуа нетипичных для человека.
в случае AI помогает хорошее покрытие всех случаев тестами.
Особенно когда оно их стабит, чтобы позеленели.
Особенно когда оно их стабит, чтобы позеленели.
С год назад он действительно так делал. Но последние пол года я не припомню таких фокусов. Или модели починили, или мой опыт стал больше.
Эти пол года работал только с опус 4.8
типичных для человека нет, новых аишных увидим вагон и пару прицепов
Опыт показывает, что множество ограничивающих требований модель просто игнорит. А одно общее объяснение зачем все это использует эффективнее.
Не поверишь, но на программистах это точно так же работает лучше, чем просто сказать где взять и куда положить.
Троль прав, само наличие контекста не спасает прикладное программрование как профессию. Но контекст кто-то тоже передал машине. Или дообучил или вставил в запрос. В первом случае работа со статистикой на этапе дообучения, и там много очень точного и специфичного описания управления потоками данных и результатов, аналогичного кодингу. Во втором работа с поиском категорий чтобы подобрать контекст подходящий к запросу и уместится в лимите. Передача контекста машине это и есть программирование для кожаных. Не то чтобы это несможет ИИ, просто это уже не область прикладного программирования и "архитектор прикладного продукта" не захочет и не сможет так легко принять ответственность на себя да и некогда ему будет, не уровень "стратегического планирования". Его уровень начинается с "дайте мне дообученый/достроеный ии за три, ой две, копейки" .
Простой ответ - любая машина никогда не будет знать все об окружающем мире, контекст, допущения конкретно вашей задачи или запроса. Без этого никогда не будет экспертности в проекте или части кода. Клауд опус 5.55 может задать вопрос по неизвестным местам, но если вы не эксперт - откуда вам знать, что все вопросы заданы и вы на них корректно ответили? А если вы эксперт и все знаете - чем программирование с нейросетью отличается от программирования без нее?
Простой ответ - любая машина никогда не будет знать все об окружающем мире, контекст, допущения конкретно вашей задачи или запроса. Без этого никогда не будет экспертности в проекте или части кода.
Кажется тут просто логическая ошибка. Переведем на людей:
любая человек никогда не будет знать все об окружающем мире
Без этого никогда не будет экспертности в проекте или части кода
=> вывод: не существует людей с окспертностью в проекте… Вывод, очевидно ложный. В реальности это неправда.
Безопасность LLM уже анализируют на экспертном уровне
Сразу вспоминается, как агент снял мидлварь аутх с роутов, так что все роуты попали гостям. Или как прописал принудительную аутентификацию в тесте где проверялась аутентификация. Или бесконечные фоллбэки маскирующие проблемы.
отличает понятливость и, внезапно, здравый смысл
Главное не просить взять машину на автомойку если она в 50 метрах
тем лучше результат
Пока не видел ни одного проекта вайбкодера без вырвиглазного говнокода без архитектуры с дубликатами и тупостью на тупости. Правда в том, что для того, чтобы добиться качества от агента нужно прилагать большие усилия - сформировать контекст, вникнуть, итерациями заревьюить и исправить. По времени это недалеко от разработки руками. Нет никакой волшебной кнопки, которая делает стартап пока ты завтракаешь.
Смотрите, что я на самом деле написал в своем сообщении, если читать его как мнение программиста работающего с AI а не вброс "а теперь вас всех уволят":
1. Посыл статьи ошибочен, точность формулировок это не то что нужно для эффективного програмирования с AI. Про это сейчас говорят все. Только сегодня видел прямо это утверждение в новостях от создателя Claude Code.
2. Агенты понятливы - С этитм я вообще не знаю кто может спорить. Только наверно тот кто запустил китайскую модель, помучался пол часа и бросил.
3. Агентам свойствнен здравый смысл - Да, если агент знает все о проблеме, он крайне редко может принять глупое решение, скорее всего решение будет сбаллансированным. Человек часто находится под влиянием психологии - жалко выбрасывать уже проделанную работу, хочется применить заумное решение и показать всем что ты умный, хочется опробовать новую технологию. Ничего из этого не свойственно AI.
4. "От человека на данный момент нужно общее стратегическое понимание как все будет работать - какого рода алгоритмы, примерно что за данные, что будут проверять тесты, и определенная доля внимательности к деталям, чтобы не попасть на бессмысленно раздутую кодовую базу и неоптимальные по быстродействию решения." - это в точности то, что вы написали - волшебной кнопки пока нет, надо прилагать усилия. С лучшими моделями типа фабла этих усилий все меньше, это факт.
5. "Безопасность LLM уже анализируют на экспертном уровне" - Я не сказал что LLM пишет безопасные приложения. Я сказал что если его попросить найти уязвимости в коде, он сделает это лучше человека. Где я не прав?
Я вообще удивлен, что столь очевидное и распространенное в каких нибудь американских стартапах мнение воспринимается здесь как троллинг.
Только сегодня видел прямо это утверждение в новостях от создателя Claude Code
От продавца лопат, который неожиданно хвалит лопаты.
Безопасность, понятливость и тд зависит от предоставленного контекста, на который нужно потратить время чтобы его сформировать. Вайбкодер создает контекст на нулевом уровне. Без контекста все модели пишут перепутанную зафоллбэченную лапшу, дубликаты без архитектуры и говнокод. И с ростом проекта эта проблема будет увеличиваться пока не начнутся известные проблемы, когда модель сама путается исправляет в одном месте и ломает в другом.
Вы слишком антроморфизируете агентов. От этого исходят и остальные ложные выводы.
Человек часто находится под влиянием психологии - жалко выбрасывать уже проделанную работу, хочется применить заумное решение и показать всем что ты умный, хочется опробовать новую технологию.
Не думали, что это может быть свойственно и вам в отношении AI?
Мне кажется, тут есть ещё один аргумент в пользу вашего вывода, причём он почти не зависит от того, насколько хорош станет следующий Opus.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее. Всё это кто-то должен формализовать.
А затем нужен независимый от генератора слой проверки: тесты, типы, статический анализ, формальные методы, интеграционные стенды — в зависимости от задачи. То есть мало получить программу, нужно ещё иметь способ верифицировать её против требований.
И отсюда, кстати, забавный вывод про языки высокого уровня. Они нужны не только потому, что человек не умеет писать машинный код. Это удобный промежуточный слой, на котором можно выражать структуру системы, ограничения и свойства, о которых можно рассуждать и которые можно проверять. Причём он полезен и самой модели.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Более того, чем больше кода модель способна произвести за час, тем важнее становится этот второй слой. Иначе мы просто получаем очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт.
Поддержу - продукт кодосодержащий, идентичный натуральному, получать было легко еще во времена индийского кода, а это примерно давно. С тех пор подросло целое поколение. Граница, как и раньше проходит по формализации мышления, что отличает кодера от программиста. А кожаный кодер или песочный - не так уж и важно.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация
Классика жеж!
P.S. Нейрокартинка паровоза — низачот.
ну скорее не код, а алгоритм, но да забавно
ну скорее не код, а алгоритм
Код есть представление алгоритма, выраженное средствами конкретного языка программирования. Суть эквивалентно
А еще точнее не алгоритм, а система требований (статья в Википедии так себе, про программирование в ограничениях получше, но микроскопически). Например, из алгоритма "возьми столбец чисел, умножь на вот эту таблицу, пропусти покомпонентно через такую-то функцию и так 20 раз" никак не следует что получится по итогам: чье ухо на вот этой свадебной фотографии или какой ход сделать в данной позиции на шахматной доске?
Дружелюбный русский алгоритмический язык, который обеспечивает наглядность (сокр. ДРАКОН)
Эти рассуждения вполне применимы и к команде разработчиков. Кто-то принимает десятки решений по каждым мелочам, и как-то нужно решить, получилось ли то, что задумано.
Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Когда задаёшь промпт погонщику агентов, он именно этими вещами и занимается.
очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт
Всё отличие от предыдущего состояния индустрии заключается в словах "очень быстрый".
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
Эту точную спецификацию тоже пишет LLM интерактивно обсуждая с человеком проблемы и концепт. При этом здесь важна вовсе не детальность описания концепта а принципиальное наличие этого концепта в голове человека и примерное понимание как этот концерт отольются в коде.
Т.е. картина кардинально поменялась. Раньше суть была в том, чтобы сначала вообразить что это будет а затем формализовать проблему до уровня языка программирования.
Теперь задача в том, чтобы вообразить что это будет и шаг за шагом доносить этот образ агенту. При этом образ объясняется а не формализуется. Формализация нужна когда исполнитель глупее постановщика задачи. Но с LLM это не совсем так или совсем не так.
Формализация всё равно нужна. Просто в случае с LLM (как и в случае с диалогом “заказчик-тимлид”) её можно проводить итерационно, а компилятору/интерпретатору надо скармливать уже готовую.
Т.е. картина кардинально поменялась, теперь суть в том, чтобы сначала вообразить что это будет а затем формализовать проблему до уровня большой языковой модели?
При этом образ объясняется а не формализуется
А в чём принципиальная разница? Объяснение - это ведь, по сути, движение к формализации. Только более витиеватое. Вы лишь останавливаетесь на каком-то этапе, оставляя дальнейшую формализацию на откуп LLM.
Базу выдал, добавить нечего. Ллм отлично заменяет гугл и стэковерфлоу, но системный дизайн ей пока доверять рано
Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
Запустить ее? Раз клод пишет софт значит это кому-то нужно, у ПО уже есть потребитель - вот он и проверит что работает как надо.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Только это будет не программист, а потребитель. Он все и сформулирует, а клод ему подскажет если сам не сможет. Погромист нафиг не нужон получается. В принципе это уже сейчас происходит - количество ПО сильно выросло, причем нормально оформленного с доками и гуями (LLM одинаково хороша во всем, да) - люди с помощью агентов пишут софт который им нужен, хотя раньше они бы в это явно не полезли. Сейчас это все еще (около-)программисты, но это вопрос развития LLM :)
Я пишу требования, ллм делает план и пытается в архитектуру (смотрим как на рекомендацию), я пишу код, ллм проверяет и даёт свои рекомендации, я правлю (или нет), ллм пишет кейсы для тестирования, я пишу вместе с ллм тесты и в конце еще ллм делает обзор на PR. Вот это здоровый способ использования ллм
по-моему вы упускаете тот же самый момент что и автор статьи:
Проблема всё равно остаётся: откуда берётся эта точная спецификация
Во-первых, спецификация и есть по сути код.
Во-вторых - а откуда она берется сейчас? Правильно, постановщик задачи дает его представление о требуемом результате, а задача современного разработчика это представление привести к спецификации. Для этого есть разные способы - логические заключения, уточняющие вопросы и тд.
Т.е., то что вы упускаете - почему этим “современным разработчиком” должен быть человек? Что мешает следующему или N-ому клоду быть достаточно сообразительным чтобы заниматься этим? Правильно - ничего.
P.S. хотя похоже иммено это и пытается сказать @amazingname, пусть и в не очень сдержанной манере.
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее.
Вполне себе спецификация. Ибо есть и формальные описания и главное - куча примеров. Создать по аналогии - не подходит?
А картинка паровоза таки да - отстой.
И что вы по этой спецификации ожидаете? Копию одной из операционки? Или некую сборную солянку в произвольных пропорциях из произвольного набора? Только зачем такая операционка нужна, если можно взять готовую?
Я ожидаю нЕчто, что можно назвать операционной системой. "Зачем" - это вы себя спрашивайте. В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось. Заметьте - я не обсуждаю нужность\полезность написания. Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают. TR-DOS помещался на дискете 360 КБ. И ещё место оставалось.
"Зачем" - это вы себя спрашивайте.
Так не я же оправдываю такую "спецификацию". Мне такое вообще не нужно.
В исходном задании «Claude, напиши мне новую операционку» назначение не указывалось.
А спецификации без назначения бывают? Стоит тогда уточнить термин спецификация.
Я утверждаю, что само название - "операционка" вполне формально описывает задание и достаточно для построения. Операционки - они разные бывают.
Что-то у меня эти предложения не стыкуются вместе.
Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мира и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
"Посчитай сотрудникам премии за квартал" работает только в сработанном коллективе, где этот весь контекст уже известен и все понимают главбуха, что именно он имел ввиду. А вот если приходит такой главбух к программистам и говорит: "хочу программу, чтоб считала премии за квартал", то у живого программиста совсем другой опыт и знания, так что ему придется все эти ваши вопросы задавать, и если программист чуть более опытный, еще и фиксировать в ТЗ на подпись, чтоб потом не было от главбуха: "а я совсем другое говорил!".
И вот-это ТЗ, это ТЗ на то, как должен выглядеть результат. Вариантов реализации по прежнему бесчисленное множество. Так вот, в отличии от времен изобретения Кобола и Сиквела, теперь это ТЗ можно напрямую засунуть в кодинг тулзы и получить нечто, что будет работать и выдавать результат по ТЗ. И даже на очевидных неопределенностях кодинг тулзы будут вопросы задавать: как сделать, вот-так, или так? И вместо выбора из предложенных вариантов, можно текстом ему написать какой-то новый вариант, которого нет в списке, и он поймет и сделает по-нему.
чтоб потом не было от главбуха: "а я совсем другое говорил!"
Это не ТЗ, это защита от недобросовестности заказчика. Но тоже быть должна. Хотелки -они такие :)
теперь это ТЗ можно напрямую засунуть в кодинг тулзы и получить нечто, что будет работать и выдавать результат по ТЗ
В реальности как результат соотносится с ТЗ не знает даже сама тулза, не говоря уже обо всех остальных.
как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
А это сейчас кто-то, кроме заказчика, может это проверить? И не ссылайтесь на техзадание, это просто бумажка - зад исполнителя прикрыть. А ещё - чистосердечное признание в том, что компетенция разработчика недостаточна для понимания замысла заказчика, и требуется разжевать и в рот положить. И для его реализации - тоже. И не надо рассказывать, что заказчик не знает, что ему надо. Знает. Просто в 99% случаев квалификации исполнителей не хватает. И начинаются упрощения.
Наконец-то настанет светлое будущее, когда заказчик будет платить деньги за то, что ему надо, а не за то, что смогли наваять и теперь ему втюхивают.
И не надо рассказывать, что заказчик не знает, что ему надо. Знает.
Тоже мне тайна. Он хочет кнопку "Заработай много денег"
Просто в 99% случаев квалификации исполнителей не хватает.
В 100%
Если разрабы такие тупые, а заказчики умные, почему заказчики сами себе код не пишут. Кнопку "сделать збс" еще не завезли в новые фреймворки
здесь весь вопрос с том, что процессы - они в голове у заказчика. И там огромное количество нюансов, которые вытащить из головы и описать - это огромнейший труд. Когда заказчик сам себе хороший программист, то все великолепно получается. Я много-много раз писал автоматизации СВОИХ процессов под СВОЙ функционал, а потом еще и разворачивал его как универсальный для коллег, так как знаю все нюансы процессов. И ограничивало 2 вещи: время на разработку и знания яп/технических инструментов. То есть, когда квалификации чисто в том, КАК это сделать, не хватало. А вот с тем, ЧТО сделать надо - все было просто.
Даже самый тупой клиент абсолютно точно знает, что ему надо. Объяснить не может. А вот передать весь массив информации, что есть в башке у владельца процесса - это отдельное искусство.
Вот элементарное. Нужна обработка считать стоимость перевозки по количеству коробок, потому что раньше считалось все по весу, а тут хлоп - одному клиенту надо покоробочно выставлять. Пересчитали, внедрили, оказалось, что параллельно считается по весу количество паллет, и для покоробочного тарифа оно некорректно. Дописали еще пересчет паллет. Потом оказалось, что для многострочных счетов количество паллет ставится по хитрому принципу, существующему лишь в башке оператора - как распределить на много строчек количество паллет, сформулировать принцип округления и распределения по паллетам никто из операторов не может, но все делают. Пытать операторов с образованием в 9 классов+ПТУ бессмысленно, давай статистически посмотрим, как они ставят. Выявили три закономерности. Согласовали. что алгоритм распределения количества паллет по строкам будет именно по этим закономерностям, статистические погрешности операторы правят вручную. Вроде ерунда - оператор залезает в документ, считает по количеству коробок количество паллет (причем сколько на каждом типе паллета каждого типа коробки, оператор держит в памяти, в справочниках такого нет), проставляет по строчкам, считает по тарифу - операция для оператора простая, но ручная и небыстрая. А для автоматизации просто описание алгоритмов - целый проект с опросами и выборками. И тут два способа. Если разраба посадить оператором, то освоит и автоматизирует в процессе. Или аналитику переводить мысли в головах операторов в что-то алгоритмизируемое. А писать разраб будет на машкодах или на bsl - непринципиально. Можно попробовать оператора научить программированию - этот путь пропагандирует вайбкодинг. Но результат неконтролируем и неприемлем.
Это вы тот самый тип заказчика, у которого техзадание - "сделай мне социальную сеть по типу фейсбук с бесконечной базой данных за 5к рублей"? Ну, просто разрабов таких не нашлось что сделают, конечно конечно. Дальше оправдывайте свой инфантилизм.
за 5к рублей
Э не, как раз за деньги речь нигде не шла! Это вы сами придумали! Деньги как раз одним из основных регуляторов и являются.
А на счет вашего техзадания - его можно и по другому вывернуть. За 50M USD возьмётесь делать? Только "AS IS" не будет. Срок исполнения - 90 дней. За каждый день просрочки запуска - штраф в 1% процент от стоимости заказа. За каждый час простоя сети в течении первых 120 дней - штраф в размере % процент от стоимости заказа. За каждый сбой регистрации клиента - штраф. За не срабатывание фильтров DRM и прочей цензуры - штраф. И много ещё чего. Квалификации хватит? Или только сумма оплаты маловата?
Клиент всегда прав, пока платит деньги :)
Статья одной картинкой
А, извините, @Wesha раньше успел.
Кстати, любителям английского предлагаю догадаться, для чего именно предназначен метод record_changes() в незнакомом коде: записывает в базу изменения, произошедшие в некоем объекте (записать_изменения()) — или представляет собой хук, который вызывается, когда система обнаруживает изменения в некой записи (запись_изменяется()). True story, bro.
Венгерскую нотацию придумали зачем то.
Первый вариант, если код писали нейтивы. А так может быть все, что угодно.
Метод называют глаголом, который что-то делает. Соответственно, в наименовании record changes "record" тот самый глагол. Если нужно обработать какое-то событие, то ставят handle_record_changes. Ну или в ивентах OnRecordChanged. Тут зависит от языка и соглашений.
Для второго варианта там должно было быть changed. Если там именно изменяется, то тогда changing.
Челодой моловек, «changed» — это «изменился», а «changes» — это «изменяется».
Трактат о пользе естественного языка в программировании. Датируется серединой Средних Веков, когда в наставлении для монахов попутали celibate и celebrate ;)
Оно еще и изменения ;)
Если в данный момент изменяется, то там не будет changes, там будет именно changing (is changing, если быть по-английски точным), потому что он сейчас изменяется, а не постоянно. А на изменение хук вызывается когда значение уже изменилось, т.е. changed
Но это если мы про глаголы говорим. А так-то там может быть и простое change - изменение (сущ.): on_change - при изменении.
Но это если мы про глаголы говорим.
Я так понимаю, Вы не заметили, что там индусы мимокрокодили?
Не хватает цитаты из Совершенного кода (2004).
За последние десятилетия программисты видели массу инструментов, которые предположительно должны были устранить необходимость программирования. Сначала это были языки третьего поколения, потом — четвертого. Потом — автоматическое программирование. Потом — CASE-средства. Потом — визуальное программирование. Каждое из этих достижений привносило значительные улучшения, и общими усилиями они сделали программирование абсолютно неузнаваемым для тех, кто изучал его до этих нововведений. Но ни одна из этих инноваций не устранила программирования как такового.
Причина в том, что программирование — принципиально сложный процесс даже при наличии хорошего инструментария. Дело не в инструментах — программистам приходится бороться с несовершенством реального мира; нам нужно досконально продумывать последовательности, зависимости и исключения, иметь дело с конечными пользователями, которые никак не могут ничего решить. Нам всегда придется бороться с плохо определенными интерфейсами с другими программными и аппаратными средствам и всегда принимать во внимание инструкции, бизнес-правила и другие источники сложных проблем, возникающие вне мира программирования.
Нам всегда будут нужны люди, способные заполнить брешь между задачей реального мира, которую нужно решить, и компьютером, предназначенным для решения этой задачи. Эти люди будут называться программистами независимо от того, манипулируют они машинными регистрами на ассемблере или диалоговыми окнами в Microsoft Visual Basic. Пока у нас есть компьютеры, нам будут нужны люди, которые говорят компьютерам, чтб делать, и эта деятельность будет называться программированием. Когда вы слышите заявления о том, что «новый инструментарий устранит необходимость компьютерного программирования», бегите! Или хотя бы посмейтесь про себя над этим наивным оптимизмом.
попробую чуть перефразировать:
1. Как исходная аксиома:
Всегда, человечество пыталось упрощать.
Нет предпосылок, что этого не будет происходить дальше.
2. Программирование - "еще один" способ упростить.
- появился (среди гиков - "универсалов");
- занял (массовую) нишу;
- и еще будет (узкие специальности, там где они выгодны. Аналогично, по проектным командам, и водопадной разработке).
3. LLM-ассистенты, вайб-кодинг - нужно другое, новое слово, чтобы не смешивать со "святым" программированием:
- спец - "сам сделаю лучше", и не позволит LLM выйти в "мастера";
- универсал - вспомнит "всё - уже было: постановка задач").
4. (Почему:) когда мы вызываем такси, (обычно!) нас и исполнителя, интересует только пара Принятых общих вопросов, но не такие детали, как марка машины, цвет, марка бензина.
Они - для чего-то сложного/уникального, ближе к "проекту", чем к "кодированию (программного обеспечения)".
Можно предположить, что LLM - (в будущем) будет сильнее ориентироваться в таких общих вопросах (специализироваться: помнить или получить сведения - "страна", "предпритие" пользователя, знать Бухгалтерию РФ, получить "штатное", ...).
5. Т.е. "в будущем" - "на входе" (на уровне Пользователя), всё (почти всегда, 99%) будет - просто, быстро и без лишних вопросов (появятся инструменты - языки, среды, ...).
А "что там внутри" - "магистрально", тоже выродитсяпереродится (как Электричество - для пользователя, за сто лет, свелось к "220В, выключателю, лампочке и проводам". Со стандартами - внутри).
6. Бороться, на своем уровне - пожалуйста ("Прыгайте, дети!" - тов.Дынин).
В целом - тенденция не умолима (никакие ошибки LLM - аля "кз", "телик, сгоревший при бросках" - не заставят отказаться. Всё - быстро подстроится).
7. Рассказывать, как было хорошо, когда все руками, уникально, и с головой - "Воспоминания юности".
8. Разработка "на века" - станет редкой, только для эстетов (типа, аудиофилов).
"Сформулировал, передал (там - что-то как-то сделалось), получил и забыл"
(в следующий раз, пользователь - начнет по новой, а внутри - предпочтут "выкатить с нуля").
Если нейронки так шикарно понимают человеческий язык, почему промпт-инжиниринг с каждым днем все больше напоминает синтаксис плюсов)) Скоро начнем скобки и отступы в промптах ставить
Вообще-то наоборот. Как раз на современных умных моделях надо отказываться от всяких "хаков". Вон, недавно в методичке от Claude написали, чтобы программисты перестали загрязнять контекст всякими уточнениями, правилами и прочей мутью. Современная нейросеть гораздо лучше понимает строгий и лаконичный код, а не развесистый промпт.
Современная нейросеть гораздо лучше понимает строгий и лаконичный код, а не развесистый промпт.
Не льстите себе — не понимает ни того, ни другого.
Справедливости ради, лаконичного в статье нет, а увиденная мною в комментах лаконичность другого автора напрочь убита прозаичностью и бесструктурностью. Если попытки будут продолжены, то стоит попробовать сильно ужать сопутствующий код верхнего уровня и увеличить описание конкретных элементов рисунка. Например (
< Ото рта [ПЕРСОНАЖ:ЗАЯЦ] идёт "хвостик" "пузыря" [ПУЗЫРЬ1], который располагается выше всех остальных "пузырей" на панели.
[ПУЗЫРЬ1] содержит текст (реплику [ПЕРСОНАЖ:ЗАЯЦ]): "Да вот, обменник открыл!".
---
> Пузырь с текстом "Да вот, обменник открыл!", хвостик пузыря кончается у [ПЕРСОНАЖ:ЗАЯЦ]
)
А по теме здешнего обсуждения… Мне понравилось описание работы с нейронкой как общения с мидлом, которого надо контролировать как джуна. То есть LLM можно сгружать рутинные некритичные задачи при условии наличия большой базы типичного кода (на подобие которого надо писать), но не что-то совершенно новое или ответственное.
У вас очень странный диалог. Сейчас возможности от версии к версии отличаются примерно как поездка на велосипеде отличается от поездки на электровелосипеде, а та, в свою очередь - от поездке на гоночном байке. И если один из вас работает с версией 1.1 а второй с версией 1.2 - вам не о чём говорить.
Почему то вспомнился "протокол Вихрь", если кто помнит.
отстаете на пару лет
промпт-инжиниринг с каждым днем все больше напоминает синтаксис плюсов
Не сказал бы. Удивительно, но llm-агенты в последнее время понимают чуть ли не с полуслова, даже если писать обычный текст, без промптовых вывертов. Кажется, ещё год назад было хуже.
Идея придумать ЯП без программирования - решить проблему кодинга, введя еще один уровень абстракции, но....
Любую проблему можно решить, введя еще один уровень абстракции, кроме проблемы большого количества абстракций.
Думайте)
Странно отсутствие в списке обсуждаемых языков алгола и фортрана. Первый использовался только для описания того, что вам надо посчитать с непременным указанием необходимых компонентов, фортран фактически повторял алгол, но измененная по отношению к алголу форма текста подготавливала компилятор, который брал на себя учет всех особенностей применяемой ВМ
алгол и фортран идеи отобрать хлеб у программиста не преследовали, и были классическими ВЯП. Первый емнип вообще стал основой современной теории языков программирования с его блокам, областью видимости и рекурсией, т.е. его как раз никто не позиционировал как язык, понятный бухгалтеру или менеджеру. Второй afaik создавался, чтобы заменить ассемблер для научных вычислений, т.е. опять же цель это математические формулы и точная логика, а не естественный язык.
1. Программирование — это управление сложностью Вы абсолютно правы в том, что естественный язык не приспособлен для описания детерминированных систем. Главная проблема здесь — комбинаторный взрыв состояний. В системе из 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% от текущего остатка», останется ровно до тех пор, пока существуют банки и человеческая неточность.
Машина, которая исполняет «я хочу миллион долларов», действительно фантастика
Нет, это банкомат. Ну ладно, большой такой банкомат...
То чувство, когда нейросеть написала текст про то, почему нейросеть не шмогла....
Тут, на мой взгляд, в один мешок свалены две разные вещи: высокий уровень абстракции и конкретные закрытые визуальные конструкторы. Проблема начинается не тогда, когда язык выше Java, а когда у платформы нет следующего слоя вниз.
В том же lsFusion бизнес-логика остается обычным plain code: свойства декларативные, действия императивные, формы и их расширения тоже код. Все лежит в git и нормально мержится. Если платформенной конструкции не хватает, можно уйти в SQL, Java, JavaScript или внешний API, не переписывая приложение целиком. Сама платформа open source.
Поэтому тезис "нестандартная логика или интеграция сразу превращает 4GL в золотую клетку" не универсален. Золотая клетка получается у закрытого визуального DSL.
А с основным выводом согласен: программисты никуда не исчезают. Высокий уровень абстракции убирает рутину, но формализовать правила и отвечать за них все равно кому-то надо.
Косвенно вылезает ещё одно свойство, уже не про Райса, а про сам естественный язык. Чем более сложную композицию мы хотим построить, тем хуже она ложится на слова. По‑русски это звучит так, что маленькую функцию описать словами можно, получится даже неплохо и понятно, а вот систему на миллион строк словами описать нельзя, и дело не в том, что слов не хватит, просто естественный язык не композируется, а смысл может накладываться, перетекать от предложения к предложению или зависеть от соседних предложений, захватывая абзацы, а иногда и более крупные участки произведения.
для борьбы с этим и придумали DDD, разделение контекстов
Вы абсолютно правы, и это очень глубокое наблюдение. Вы затронули фундаментальную проблему семантического коллапса в естественном языке при масштабировании.
Естественный язык обладает свойством нелинейности и контекстной зависимости (синестезия смыслов, омонимия, метафоры). В литературе это плюс, но в инженерии — катастрофа. Код же обязан быть композициональным: смысл целого должен строго складываться из суммы его частей.
Вот как именно Domain-Driven Design (DDD) и разделение контекстов (Bounded Contexts) борются с этой проблемой естественного языка:
1. Борьба с полисемией (многозначностью)
В больших системах одно и то же слово означает абсолютно разные вещи для разных людей.
Проблема: Слово «Аккаунт» для бухгалтера — это баланс и проводки. Для службы безопасности — это логин и права доступа. Для маркетолога — это профиль клиента. Попытка создать единое описание «Аккаунта» словами приводит к путанице.
Решение DDD: Каждому контексту — свое определение. В контексте «Биллинг» Аккаунт — это деньги. В контексте «Авторизация» — это сессия. Смысл больше не «перетекает» хаотично.
2. Ограничение когнитивной нагрузки
Человеческий мозг не может удержать связи между миллионом строк кода или тысячей страниц текста, если они переплетены.
Проблема: В тексте без границ смысл предложения А может внезапно зависеть от абзаца Z в конце книги.
Решение DDD: Ограниченный контекст (Bounded Context) создает жесткую границу смысла. Все, что происходит внутри контекста, изолировано. Вам не нужно знать контекст Z, чтобы понять контекст A.
3. Единый язык (Ubiquitous Language) как API
DDD не пытается исправить весь естественный язык сразу. Оно исправляет его локально.
Решение DDD: Внутри одной границы создается строгий, почти математический словарь. Слово «Заказ» внутри контекста «Доставка» означает строго конкретный набор полей и статусов. Шаг влево, шаг вправо — синтаксическая ошибка.
По сути, DDD признает: «Мы не можем описать сложную систему единым текстом на человеческом языке. Поэтому мы нарежем систему на маленькие независимые “княжества”, внутри каждого из которых язык будет простым, однозначным и не вызовет композиционного взрыва».
Так и в коде придумали разбиение на функции, классы и прочие мелкие сущности, как раз для этого же. А огромная функция "посчитать дебет и кредит" занимающая 3 мегабайта текста мало того что нечитаемая легаси, изменения в ней проводить очень тяжело будет, даже если наизусть помнишь что где и как. А такое даже машине тяжело...
Хорошая статья, спасибо!
Кмк, программист превращается из человека, который помнит наизусть встроенные методы и переворачивает деревья во сне, скорее в аналитика + архитектора
Да. Очень трудно объяснить работу какого-то механизма.
Что значит для бухгалтера фраза «посчитай сотрудникам премии за квартал»? В начале моей карьеры занесло меня в небольшую конторку, которая плодила энтропию в этом мира и занималась написанием чего‑то вроде 1C движка для подсчета зарплат, поэтому я немного коснулся этого болота. Живому человеку этой фразы было достаточно, чтобы достроить десятки умолчаний: кому именно начислять, по какой формуле, что делать с теми, кто пришёл в середине квартала, что с уволенными, округлять ли и в какую сторону, в какой валюте, что делать если по человеку вообще нет данных. Естественный язык работает именно потому, что слушатель затыкает эти дыры контекстом, здравым смыслом и общими знаниями, которых у него много, потому что он работает в этой сфере.
Это мы понимаем, что есть сотрудники, есть кварталы, возможно начисление премии (по некоторым правилам). Трудность формализации. Надо задавать некие элементарные понятия и строить из них конструкцию, которую можно учитывать в расчётах. (Этим 1С и занимается.) Проблема в том, чтобы вытащить все умолчания, то есть сделать явным всё тайное. Если бы существовал формальный способ через диалог вытащить это всё из заказчика, то давно так и делали бы.
Хотя, да, можно было бы представить себе, как система постепенно учится понимать, что есть какие-то сотрудники, которые куда-то ходят, получают за это зарплату, и что могут быть ещё и премии...
"посчитай премии за квартал"
ИИ-подход, видимо, должен заключаться в том, чтобы "скормить" этому самому ИИ руководство по бух. учёту + текущее законодательство и получить на выходе готовую конфигурацию объектов. Причём, ИИ должен сам выбрать (что и делает при программной реализации каждый живой программист) типологию объектов (в отличие от живого программиста, ИИ может проверить несколько различных гипотез в автоматическом режиме). (Что же будет являться здесь обучающими данными?)
С фундаментальной точки зрения, у нас возникает три пробелмы:
Можно ли найти такие элементарные понятия, которые позволяют выразить все необходимые классы объектов и автоматически строить системы для их обработки?
Можно ли находить такие элементарные понятия эффективно (если первая проблема разрешима)?
Можно ли пользоваться теми понятиями, которые действительно можно выделить. даже если построение полной системы составляющих неразрешима?
Тут проявляется что-то вроде теоремы Гёделя о неполноте формальных систем, когда логически непротиворечивая система оказывается неполной.
P.S. Эхх... Придётся пойти в такие теоретические дебри! Как любил повторять Морж у Льюиса Кэррола (и у Бьярна Страуструппа), "о многом пришла пора поговорить"... ;-)
«скормить» этому самому ИИ руководство по бух. учёту + текущее законодательство и получить на выходе готовую конфигурацию объектов.
«Ну, тафай, тафай!..» ©
Я, как инженер, поддерживаю автора и всё сказанное. Буквально недавно читал статью про пограничные случаи в медицине https://habr.com/ru/companies/beget/articles/1051252/
Попробуйте, что называется, такое навайбкодить. А с учётом разного законодательства в разных странах, если продукт задумывается как мировой, нужно предусмотреть какие-то конфигурации или возможность для него, чтоб условно было не 2 гендера (пола), а больше
Я есть инженер данных и я специализируюсь на таких пограничных случаях. Ещё ни в какой сфере, где я работал, человеку не инженеру не удавалось описать всё словами, люди обычно держут контекст (что подтверждает статью) и о многом умолкают. Будь то железнодорожные перевозки (что делать с вагонами, у которых на путях преграда - будь то сломанные пути, человек лежит, дерево или визуально невидимая дорога из-за плотного пожара), мобильная связь (как и на какой дистанции устанавливать антенны, делиться ли антенной между операторами), медицина (читай статью выше), фармацевтика (там своих приколов с исследованиями и побочными эффектами хватает), строительство (ну тут вообще с ума сойти можно из-за разных климатических условий и вероятностей землетрясения)
Просто жду когда люди осознают что ИИ это не волшебная таблетка. Дело не в языке программирования и в разработчиках, нет, тут многое другое порождает наши специализации и оно вряд ли когда уберётся (условно - как запретить всем банкоматам выдавать валюту когда в стране кризис)
Ещё ни в какой сфере, где я работал, человеку не инженеру не удавалось описать всё словами, люди обычно держут контекст (что подтверждает статью) и о многом умолкают.
Новые люди приходят в эти сферы, обучаются? Как им передают опыт? Что, если к новичку приставить ИИ, которая будет протоколировать обучение и выдаст документацию по всем нюансам?
Просто жду когда люди осознают что ИИ позволяет приложить усилия по обучению и экстракции опыта ровно один раз, после чего мгновенно можно иметь хоть миллион исполнителей, которые не уйдут в запой.
Попробуйте, что называется, такое навайбкодить. А с учётом разного законодательства в разных странах, если продукт задумывается как мировой, нужно предусмотреть какие-то конфигурации или возможность для него, чтоб условно было не 2 гендера (пола), а больше
И скажите нам, как специалист по граничным условиям: вы при наличии 10-ти грендеров, кого будет к урологу, а кого к гинекологу посылать?
Ещё вопрос с родильным отделением остается открытым и все что с ним связано…..
А там в той статье про медицину в целом сказано, но повторюсь своими словами - на такой случай заводятся два поля - биологический пол (только мужской или женский) и пол юридический (хоть какой). И уже от биологического все пляшут
кого будет к урологу, а кого к гинекологу посылать?
К урологу - с заболеваниями мочевыводящей системы (независимо ни от гендера, ни от биологического пола), к гинекологу/андрологу - с заболеваниями половой системы, в зависимости от вида этой самой системы.
Тут надо дать ссылку на классиков: Эдсгер Дейкстра On the foolishness of “natural language programming” (на Хабре есть перевод)
Надо очень хорошо понимать, что общепринятым является представление, в соответствии с которым имеется набор элементарных токенов (например, слов естественного языка), и каждый токен имеет своё значение (свой смысл); каждое предложение также имеет свой смысл, и этот смысл передаётся от одного субъекта к другому. Такую теорию информации можно назвать денотативной. Под денотатом здесь и понимается некий символ, за которым стоит определённое значение, и мы используем денотаты для передачи сообщений. Но всему этому противостоит коннотативная теория информации, где смысл никак не передаётся (от одного субъекта к другому), а привносится (субъектом-получателем). Это связывается с тем, что у каждого субъекта имеется своя собственная когнитивная область, то есть — своя система координат, свои наборы опорных объектов и обозначений.
В этом смысле, естественный язык можно воспринимать как смесь более узких подъязыков, где одновременно присутствуют и элементы "высокого уровня", и элементы уровня "микрокода", которые управляют интерпретацией элементов "высокого уровня". И если "высокий уровень" ещё и претендует на что-то общезначимое, то чем "ниже", тем всё более завязывается на субъекта (как говорящего, так и слушающего). Получается что-то вроде контекстно-зависимой грамматики, чья зависимость определяется каждым субъектом. При этом, сам формальный подход к описанию естественного языка, также представляется принципиально неполным...
P.S. Помнится, у Бурбаки была предпринята попытка полнейшей формализации математики. Не получилось.
Очень хорошая, глубокая статья.
Действительно, не всегда просто перейти от абстрактного желания заказчика к поведению конкретных пикселей (простите за вульгарность) на экране. А иногда и сам заказчик не до конца понимает что ему надо.
Английский вместо кода