Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Геймдев доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 246
Я подвожу вас к выводу, что всегда было основой профессии программиста. 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 хватало на все …
Вам, наверно, забыли сообщить, что школа специальная (в хорошем смысле).
У нас тоже — но в одну. Из нескольких десятков.
В моей школе в "компьютерном классе" стояли Микроши и железная дверь, которая не открывалась никогда, так как занятий информатики у нас не было. Про Микроши я узнал только потому, что однажды по какой-то причине не нашлось класса для проведения урока то ли по русскому, то ли по математике, и железную дверь открыли.
У нас тоже году в 1989 - 1990. Может мы в одну школу ходили :)
Ну если по “чесноку” то в 96 БК уже отошла, оставались единицы кто с ними общался. Тогда уже на развалах были платы РС и АТ в домашнем варианте использовался “Поиск” его брали готовым или паяли сами.
У нас в школе компьютерный класс с БК открылся году в 89. В 95м там уже стоял аж целая одна ЕС ЭВМ. В УПК занятия в то же время проходили на Intel 386 с FoxPro. А дальше только больше. Так что 96й год это уже был закат БК и домой добровольно его уже никто не брал, все мечтали об IBM PC.
В 1996 году у меня, студента второго курса, уже была PC с 486SX. БК к этому времени все повыкидывали нахрен. Я их видел в средне-школьные времена разве что, году в 90м.
Это в Москве, конечно. Мы там были зажравшиеся.
На половину стоимости 486dx2 с моником заработал за лето 1995 года, вторую добавили родители. Программировал на нем уже на турбо-паскале
Ну хз. Я вот со стипендии в обычном универе, правда с повышенной 200 пень купил. Правда к 98, а до этого пентагон гонял. Так что не такая уж и экзотика :)
у меня дома был с 1991 года Поиск. IBM PC совместимый. А БК в школе, но это уже все воспринимали, как устаревшее
(не москва)
Столкнулся с БК где-то в 1988 - 1989 на Станции Юных Техников. В том же году их заменили на Корветы. В школе тоже были уже Корветы и IBM PC c VGA дисплеем. 256 цветов как никак.
На ассемблере я писал для радио 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 и сыпятся, хотя в целом всё сгенерированное может выглядеть круто на первый взгляд.
Я просто поражен с реакции.
Коллега, вы просто забыли где вы находитесь!
По факту, да. Чем меньше ограничений и учше описана конечная цель - тем лучше и адекватнее агент работает. Потому что внезапно, за каждым действием стоит конечная бизнес цель.никто никогда не красит кнопочки ради покраски кнопочек, условно.
Что подразумевается под "чем меньше ограничений?" Например, одна из важных инженерных задач - это формирование ряда ограничений для системы, узла, устройства и т.д.
за каждым действием стоит конечная бизнес цель никто никогда не красит кнопочки ради покраски кнопочек
Ну примерно поэтому нейроразработка пока особо ни у кого не полетела. Потому что бизнес-цель есть, разумеется. У CTO - план по закрытым таскам (хорошо если выраженный не в объемах кода в символах), от которого зависит его премия. У CPO - план по внедренным фичам (хорошо если выраженный не в объемах элементов интерфейса в кнопках), от которого зависит его премия. И так далее, и тому подобное.
А владелец изначальных бизнес-целей (деньги зарабатывать) отрезан от разработки 33 уровнями иерархии. "Живите в проклятом мире, который сами же и создали"
чем больше общего описания что и зачем нужно
А это разве не про точность формулировок? ))
Не про точность.
Я бы выделил эту концепцию на трёх уровнях.
Первое когда пишем одиночный промпт для не рассуждающий модели. Опыт показывает, что множество ограничивающих требований модель просто игнорит. А одно общее объяснение зачем все это использует эффективнее.
На втором уровне агентного кодинга аналогично. Если начать описывать каким должен быть код, результат бывает хуже чем если описывать каков должен быть результат и для чего, позволяя модели самой запланировать каким должен быть код.
На третьем уровне например, мы реализуем функцию, но не уверены что сделали все хорошо. Зовём фабла, чтобы он провел аудит, предложил что улучшить и запускаем доработки. Здесь модель по коду и нашим объяснениям понимает какую задачу решаем. И сама думает как ее решать лучше. От нас требуется понять ее решение, выбрать из вариантов но не формализовать.
Т .е. развитие использования АИ все время идёт по одной и той же логике - делегируется чем дальше тем больше. Нету никакой необходимости останавливаться и ограничивать АИ работой внутри формальных требований. Все развитие напротив идёт к схеме когда на стороне человека будет задача понимать что нужно и понимать правда ли то что предлагаем агент, это то что нужно.
То есть понимать а не формализовать.
на стороне человека будет задача понимать что нужно
Это всегда было так - нужно понимать.
понимать правда ли то что предлагаем агент, это то что нужно.
Значит потом нужно еще проверить то, что агент нам предложил. Сомнительная оптимизация, особенно если надо рассматривать взаимодействие функций систему в целом. Чем выше уровень - тем труднее проверять.
Значит потом нужно еще проверить то, что агент нам предложил. Сомнительная оптимизация, особенно если надо рассматривать взаимодействие функций систему в целом. Чем выше уровень - тем труднее проверять.
Опять таки. Спросите у агента и он разжует - агент может прекрасно критиковать свои решения. Кроме того, агент крайне редко предложит совсем плохое решение. В итоге предполагается, что мы выйдем на сходное качество как было, но с кратно меньшими затратами.
Агент находится в информационном пузыре, созданном контекстом. Если в нем нет конкретных инструкций от вас, то польза от такой критики получается как от бабки на скамейке у подъезда. В самом деле, есть соблазн использовать техники коучинга, не погружаясь в детали, но с агентами это работает ещё хуже, чем с людьми.
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
Поэтому я прошу агента создать внешнего вгента-критика решения и не давать ему контекст
А потом критика для критика, и для него тоже критика....
Агент без контекста рефлексирует над формой, а не по существу, фактически играя в ассоциации. Так же, как это делает @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
От продавца лопат, который неожиданно хвалит лопаты.
Безопасность, понятливость и тд зависит от предоставленного контекста, на который нужно потратить время чтобы его сформировать. Вайбкодер создает контекст на нулевом уровне. Без контекста все модели пишут перепутанную зафоллбэченную лапшу, дубликаты без архитектуры и говнокод. И с ростом проекта эта проблема будет увеличиваться пока не начнутся известные проблемы, когда модель сама путается исправляет в одном месте и ломает в другом.
Но где в статье или моем сообщении шла речь про "вайбкодера"?
Стандартная команда в стандартном аутсорсе работающая с гринфилда сейчас ставит какой нибудь BMAD и подымает продукт в 5 раз быстрее. При этом эти ваши "вайбкодеры" которые формируют с агентами спецификации там называются "архитекторы". Чистые девелоперы почти перестают быть нужны. А человеческое ревью полностью сводится к ревью архитектуры в коде. И как то у них всё работает.
Я всё никак не могу понять, почему тогда на рынке не становится больше новых продуктов, а старые не начинают релизиться в пять раз чаще или выкатывать в релизах в пять раз больше фич. Единственный реально видимый эффект от этих чудес ускорения разработки - это рост количества инцидентов у AWS, например.
Хороший вопрос. Я бы предположил такое объяснение.
Во первых, модели стали работать по настоящему эффективно примерно с начала 2026. Это значит, что только самые прогрессивные команды успели наработать достаточно опыта чтобы закончить с экспериментами и работать эффективно.
Во вторых, рынок имеет инерцию, он не готов потреблять в несколько раз больше софта чем раньше прямо через несколько месяцев.
В третьих, х.з. что там происходит на рынке в США, похоже что они бегут вперёд и ещё как. Российский рынок банально тормозится санкциями и трудной доступностью флагманских моделей.
Во первых, модели стали работать по настоящему эффективно примерно с начала 2026.
Странно, вот уже несколько лет все подряд, начиная от Дарио Амодеи и заканчивая комментаторами на Хабре, всё время рассказывают, как ИИ уже делает всё-всё и через полгода нас всех заменят.
Во вторых, рынок имеет инерцию, он не готов потреблять в несколько раз больше софта чем раньше
То есть в данный момент экономической выгоды от внедрения нет? Вкладывать деньги в возможное будущее, чтобы не отстать от остальных - звучит как один из признаков пузыря.
В третьих, х.з. что там происходит на рынке в США, похоже что они бегут вперёд и ещё как.
Нигде в мире не стали релизить больше. Особенно интересно, что этого не происходит у лидеров гонки за ИИ - Google, Microsoft, Amazon, Oracle и прочих.
Странно, вот уже несколько лет все подряд, начиная от Дарио Амодеи и заканчивая комментаторами на Хабре, всё время рассказывают, как ИИ уже делает всё-всё и через полгода нас всех заменят.
Я говорю только по своему ощущению. В 2026 началась магия. До того я придерживался мнения примерно как автор статьи - новый инструмент для кодинга и не более.
То есть в данный момент экономической выгоды от внедрения нет?
В данный момент выгода в том, что можно уволить две трети программистов и закрыть те же задачи. Но мало кто это делает надеясь на появление новых задач.
Нигде в мире не стали релизить больше.
Ну, я работаю в средней отсталости американском проекте и мы побежали ощутимо быстрее. И штат стал сокращаться, увы. При том что заказчики стали тоже платить меньше. Пока деньги куда то перетекают.
Странно, вот уже несколько лет все подряд, начиная от Дарио Амодеи и заканчивая комментаторами на Хабре, всё время рассказывают, как ИИ уже делает всё-всё и через полгода нас всех заменят.
Постоянная Амодея примерно равна 1/60 постоянной Капицы?
А есть пример продуктов, сделанных в аутсорсе такими командами? Ну и разница в разработке в "в пять раз" - это не очень много, это (на уровне всего продукта) где-то процентов 15 экономии. А с учетом "стало дешевле делать фичи - значит будем делать больше ненужных фич", реально для продуктов практически ничего не поменяется.
Интересно будет, когда весь процесс разработки (от идеи и до продуктовой аналитики после выкатки) удастся упаковать в AI-цикл, там разница может быть существенной. Сейчас такие примеры есть, но крайне редкие и для микробизнесов.
Тем более, что нормальных описаний предметных областей в моделях нет и научиться им пока неоткуда (
Вы слишком антроморфизируете агентов. От этого исходят и остальные ложные выводы.
Человек часто находится под влиянием психологии - жалко выбрасывать уже проделанную работу, хочется применить заумное решение и показать всем что ты умный, хочется опробовать новую технологию.
Не думали, что это может быть свойственно и вам в отношении AI?
Я вообще удивлен, что столь очевидное и распространенное в каких нибудь американских стартапах мнение воспринимается здесь как троллинг.
Возможно это потому, что вы не говорите о каком именно программировании идет речь. Может вы занимаетесь тем, что читаете N полей из таблицы, отображаете их на форме, контролируете ввод пользователя на предмет того, что в число нельзя добавлять буквы, проверяете введенные значения на попадание в заданный диапазон, после чего записываете измененные поля обратно.
Может вы занимаетесь тем, что читаете N полей из таблицы, отображаете их на форме, контролируете ввод пользователя на предмет того, что в число нельзя добавлять буквы, проверяете введенные значения на попадание в заданный диапазон, после чего записываете измененные поля обратно.
...то есть тем, что кратко называется перекладыванием джейсонов.
Конкретно мой опыт с агентами - средние относительно рутинные задачи. Типа добавить новые возможности во внутренний язык запросов для получения данных из базы с динамической схемой (когда все значения одного типа пихают в одну таблицу). Или переделать аутентификацию в сервисе под новые тенденции в проекте. Люди вокруг вайбкодят много чего покруче и много чего проще.
Ещё можно учесть тот факт, что для человеческого мозга гораздо проще и энергоэффективнее что-то отвергнуть, сгенерировав 1000 аргументов, чем в это погружаться. Мои коллеги 50 +/- лет с 30 годами опыта за рюмочкой чая наглядно и в деталях могут обрисовать почему ИИ это не о чём, правда чуть позже выясняется, что они по факту не пробовали толком с ним работать)
Хмм,
1. Вот тут хочется какое-то конкретное исследование увидеть, а не "слова". Ну хотя бы понять, на каком именно бенчмарке неточные формулировки улучшают результаты.
2. Нет, агенты категорически не понятливы. Они пытаются делать иллюзию понятливости (потому что так обучены), но понятливости им неоткуда взять.
3. Нет, здравого смысла у моделей нет. У них есть статистическое представление о том, чем их учили, но заметная часть текстов для обучения не содержит и зачатков здравого смысла, увы. Но сверить свои выводы с реальным миром модели не могут, так как (пока еще) у них нет модели реального мира. И контекст из "воздуха" модели брать, увы, не умеют.
4. С моделями надо общаться не так, как с людьми - это да. Для них важны другие вещи, другие детали, другое описание контекста. И для разных моделей - важно разное, что делает разработку под модели еще интереснее, вспоминаются времена браузерных войн...
5. Модели многое делают лучше человека. А многое - хуже. Это утверждение - не имеет смысла.
Автор статьи говорит о том, что средний человек (без специальных умений и знаний) не сможет сформулировать "а что ему надо", для этого нужен специалист, которого традиционно называют программистом. И хороший программист (инженер) всегда и отличался умением переводить с русского на русский и умением задавать правильные вопросы, а знание языков программирования было уже вторичным.
И вот этот навык пока еще у человека получается лучше.
А кодеры - да, вымрут. Как вымерли наборщики перфоркарт.
А буде т вот что - куча нагенеренного кода будет разгребаться за отдельные деньги. То есть будет быстрый стпрт, работа с прототипом в продакшне, а на заработанные на этом деньги рефакторинг.
Slopfix — это команда из трех опытных инженеров, которые проводят рефакторинг кода, написанного на Vibecode, для обеспечения возможности его сопровождения.
Как-то так
Думаете, это вам шуточки? А вот нет, это реально продаваемый сервис.
Мне кажется, тут есть ещё один аргумент в пользу вашего вывода, причём он почти не зависит от того, насколько хорош станет следующий Opus.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация, и как проверить, что получившаяся система соответствует тому, что на самом деле требовалось?
«Claude, напиши мне новую операционку» — это не спецификация. За этой фразой скрываются тысячи решений: требования, интерфейсы, инварианты, допустимое поведение, обработка ошибок, безопасность, совместимость и так далее. Всё это кто-то должен формализовать.
А затем нужен независимый от генератора слой проверки: тесты, типы, статический анализ, формальные методы, интеграционные стенды — в зависимости от задачи. То есть мало получить программу, нужно ещё иметь способ верифицировать её против требований.
И отсюда, кстати, забавный вывод про языки высокого уровня. Они нужны не только потому, что человек не умеет писать машинный код. Это удобный промежуточный слой, на котором можно выражать структуру системы, ограничения и свойства, о которых можно рассуждать и которые можно проверять. Причём он полезен и самой модели.
Поэтому исчезнуть вполне может программист в смысле «человек, который большую часть дня вручную набирает код». Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного Claude никуда не девается.
Более того, чем больше кода модель способна произвести за час, тем важнее становится этот второй слой. Иначе мы просто получаем очень быстрый способ производить огромное количество непроверенного бинарного продукта, внешне похожего на софт.
Поддержу - продукт кодосодержащий, идентичный натуральному, получать было легко еще во времена индийского кода, а это примерно давно. С тех пор подросло целое поколение. Граница, как и раньше проходит по формализации мышления, что отличает кодера от программиста. А кожаный кодер или песочный - не так уж и важно.
Допустим даже, что модель научилась генерировать идеальный код и вообще никогда не ошибается при переводе точной спецификации в программу. Проблема всё равно остаётся: откуда берётся эта точная спецификация
Классика жеж!
P.S. Нейрокартинка паровоза — низачот.
ну скорее не код, а алгоритм, но да забавно
ну скорее не код, а алгоритм
Код есть представление алгоритма, выраженное средствами конкретного языка программирования. Суть эквивалентно
А еще точнее не алгоритм, а система требований (статья в Википедии так себе, про программирование в ограничениях получше, но микроскопически). Например, из алгоритма "возьми столбец чисел, умножь на вот эту таблицу, пропусти покомпонентно через такую-то функцию и так 20 раз" никак не следует что получится по итогам: чье ухо на вот этой свадебной фотографии или какой ход сделать в данной позиции на шахматной доске?
Дружелюбный русский алгоритмический язык, который обеспечивает наглядность (сокр. ДРАКОН)
"У меня есть отличная документация: она вся на C." (c)
«Код предназначен для описания, что должно происходить. Комментарии предназначены для описания, почему должно происходить именно это, и именно таким образом.»
"The compiler doesn't read comments and neither do I"
— девиз вайбкодера?
Страуструп. Не знаю, вайбкодит ли он сейчас, но в то время, когда он это говорил — точно нет.
Так читать комментарии и не обязательно. Если вас не интересует результат. ©
Коментарии предназначены не для того, чтобы программа правильно заработала сейчас — коментарии предназначены для того, чтобы облегчить жизнь честолюбивым дублёрам. Если же они предпочитают протанцевать по минному полю, по которому уже прошли мы... Ну, не смотрите на карту безопасных проходов, которую мы для вас оставили.
Ну, не смотрите на карту безопасных проходов, которую мы для вас оставили
Звучит довольно забавно в свете того, что пишущий комментарии одновременно является пишущим код. Т.е. это не только картограф, но и ландшафтный дизайнер. Не устанавливайте волчьи ловушки и не расставляйте минные поля, тогда и карты безопасных проходов не будут нужны.
Не устанавливайте волчьи ловушки и не расставляйте минные поля, тогда и карты безопасных проходов не будут нужны.
Классный совет, да!
Проблема в том, что мы вынуждены работать с произведениями не столь щепетильных аффтаров. У нас тупо нет выбора.
Совет очень классный, потому что он не про что-то эфемерное, типа, "пишите код без UB", когда человек может и не знать, что там UB. Он конкретно про комментарии, т.е. человек знает, что тут в общем случае будет ни черта не понятно по коду, но почему-то вместо того чтобы поправить код решает написать эссе.
Как комментирование будет выглядеть в вашем случае, когда сегодня приходит
ЗАГОЛОВОК1, ЗАГОЛОВОК2
значение1, значение2
, а завтра может прийти
значение1,,,,,,,, ЗАГОЛОВОК 100500, упячка))0)нольноль, значение 2
, потому что на той стороне всем плевать на то, в каком виде они отдают данные, я не очень представляю. Можно, конечно, написать что-то типа: "If parsing fails look at the input and fix parser accordingly" — но до этого я и без комментария додумаюсь.
человек знает, что тут в общем случае будет ни черта не понятно по коду, но почему-то вместо того чтобы поправить код решает написать эссе
По коду может быть понятно, что делается. Но вот почему делается именно так - понятно не всегда. Почему задан именно этот коэффициент, почему выбран именно такой порядок вычислений, почему вместо библиотечной функции используется самописная и т.п.
Выбор алгоритмов и прочее это то, что должно быть написано в документации.
Какие-нибудь видеокодеки — яркий пример проектов, где будет много самописных функций, неочевидных data layout'ов в структурах, магических констант, которые заменяют привычные группы вычислений и прочего — объясняют и обосновывают эти решения именно там, а не заспамливает исходники тирадами о том почему вот тут (а там дальше 200 строк ассемблера) можно сэкономить три такта если расположить инструкции именно так, а не как компилятор бы их расположил, и ссылками на доказательства теорем, которые обосновывают применимость неочевидных математических трюков.
Выбор алгоритмов и прочее это то, что должно быть написано в документации.
Одно другому не мешает. В комментарии достаточно написать “ассемблерная вставка экономит три такта, см. 12.5.7с-IX в документации”. И не придётся штудировать всю документацию когда понадобится понять небольшой участок кода.
Выбор алгоритмов и прочее это то, что должно быть написано в документации.
Десинхронизация документации? Не слышали!
Обсуждали с коллегами, что такое плохо комментированный код, ну там были истории про комментарии на румынском и так далее. Самая прикольная история была про большую компанию, которая купила другую компанию со всеми их наработками. Когда стали разбираться в коде новой компании, то выяснилось, что большая часть написана китайцами, а добил их комментарий перед злобной реализацией некого алгоритма на несколько страниц: «описание алгоритма смотри в тетрадке у Чуня». Где тот Чунь уже было неясно:)
Эти рассуждения вполне применимы и к команде разработчиков. Кто-то принимает десятки решений по каждым мелочам, и как-то нужно решить, получилось ли то, что задумано.
Но программирование как формализация требований, декомпозиция и построение проверяемой системы от появления более умного 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 создавался, чтобы заменить ассемблер для научных вычислений, т.е. опять же цель это математические формулы и точная логика, а не естественный язык.
Тут, на мой взгляд, в один мешок свалены две разные вещи: высокий уровень абстракции и конкретные закрытые визуальные конструкторы. Проблема начинается не тогда, когда язык выше 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. Помнится, у Бурбаки была предпринята попытка полнейшей формализации математики. Не получилось.
Очень хорошая, глубокая статья.
Действительно, не всегда просто перейти от абстрактного желания заказчика к поведению конкретных пикселей (простите за вульгарность) на экране. А иногда и сам заказчик не до конца понимает что ему надо.
Добрый день. Статья интересная, спасибо. Комментрии тоже интересны. Выскажу две мысли, которые м.б. кто-то уже высказывал и частично есть в самой статье.
Спор по поводу Экспертизы программистов и Вайбкодинга не имеет ни кого смысла ! Почему:
Дело вообше не в этом, не в технологиях - дело в другом - если есть Экономический рост, Рост произвоства товаров и услуг, Расширения рынков, Развитие бизнеса и т.д. то будут востребовано и то и то. А если нет будет Экономического роста (основанного преимущественного на росте ТПН и услугах, не сырьевой или с/х), то в меньшей степени нужно будет и то и другое. Этим и объясняется "Парадокс Джевонса" - и это не парадокс, а наоборот поянятная Логика - если общество Развивается, Растет (Экономически, Демографически ит .д.), то растет и сложность устройство Общества, и Виды и Количество различных взаимодействий, операций в Мире. Конечно в современном Мире программисты нужны и в других направляниях - оборона, войны и т.д., но это скорее отрицательный пример для людей в целом, чем положительный (не здоровый рост).
Если смотреть узко, в рамках технологии Программирования, о чем большинство споров и комментариве. То здесь тоже Правда и там и там. Развитие технологий ( в данном случае Программирования, обработка информации в целом) показывает четко, что мы движемся от Низкоуровневых инструментов к более Продвинутым инструментам и Стандартизации рутины - поэтому, Да многое будет упрощено и автоматизировано. Но Востребованы будут и Программисты потому что иммено они обладают Одновременно - Экспертизой в технологии и спобностью решать Новые, Оригинальные и/или Сложные, Комплексные, не Стандартные задачи, а это нужно будет всегда, хоть через 1000 лет.
отладки, оптимизации производительности (одна из областей где даже всемогущий Клод плавает аки топор и говноклодит, только успевай комиты реджектить)
В корне не согласен. Даже Opus 4.8 вполне замечательно справлялся с оптимизацией шифрования, встраивая SIMD-инструкции, и добавив бенчмарки для сравнения реализации.
мои недавние проекты говорят обратное, https://youtu.be/Tt1CYGt2goo?si=rAqiWGyzgfkdSJDi
клод действительно хорош в написании нового кода, возможно, но не в оптимизации уже существующего, особенно если это связано с памятью. Надеюсь мне дадут апрув на статью про это и можно будет показать, что ИИ не видит в упор
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Английский вместо кода