Комментарии 23
Тема плинтуса не раскрыта.
Еще хочу отметить, что авторы, использующие обороты вида "всегда, слышите, всегда", ставят читателя в позицию несмышленного ребенка младшего школьного возраста.
Еще хочу отметить, что авторы, использующие обороты вида "всегда, слышите, всегда", ставят читателя в позицию несмышленного ребенка младшего школьного возраста.
Ирония в том, что "не ребенкам" или хотя бы "смышленым ребенкам" эта статья не нужна: не ребенок все это знает сам из опыта, а смышленый ребенок легко дойдет своим умом путем нехитрых рассуждений
Спасибо за мнение. Вопрос в другом. Мы только что открыли очередную коробочку любопытной девушки Пандоры и не знаем что из неё вылезет... Валидацию кода биологическими нейросетями пока это не отменяет, но...
Самое лучшее что я заметил в режиме AI-кодирования. Переход от режима программиста в режим менеджера. Это непросто смена позиции - это другие требования к концентрации. Прервавшись не нужны 15 минут для погружения в поток и не нужно время на выход из потока. Это хорошо и удобно (если тебя отвлекли, нет шансов, что код будет исправлен только частично, например...), но именно способность к глубокой концентрации и отличает ИМХО хорошего программиста от посредственного.
Мы пишем программы для компьютеров, которые являются той самой "машиной Тьюринга", для которой Алан Тьюринг еще в 1936 году строго доказал, что, простыми словами, "полностью проверить на наличие ошибок программу нельзя".
Сильное заявление. Вполне существует формальная верификация. Из примеров с такой верификацией есть seL4
Нам, разработчикам, нужно продолжать развивать мозги, тренируя их через решение задач по математике, статистике, терверу, реализации алгоритмов, изучение новых, математически точных языков программирования и иностранных языков и стараться, разумеется, вести здоровый образ жизни, ибо в здоровом теле - здоровый дух.
Rust и точный язык программирования? Про cve-rs уже все забыли?
Кто когда-нибудь интересовался темой создания профессиональных prompts, то видел, какие они сложные и запутанные на самом деле, и понятно, что их пишут уже не люди
Вы по ссылке-то ходили? Что там сложного и запутанного? Где признаки, что их писали не люди?
Приветствую!
Доказать, что в коде нет багов мешает не только проблема останова, но и Теорема Гробовой Крышки. Она же Теорема Райса.
Она утверждает, что если какое-то свойство встречается у одних программ, и не встречается у других, мы не можем для любой из программ доказать, что она обладает этим свойством.
Но тут ключевое слово "для любой". Есть куча программ, для которых мы можем доказать очень многие свойства!
Проблема останова разрешима! Пусть и не в общем случае. Но есть даже специальные языки программирования, которые называются тотальными. Если программа на них скомпилировалась, можно быть уверенным: она завершит свою работу.
Один из тотальных языков - это любимый мною Lean. В нём можно доказать, что функция обязательно завершается. А если это так, то Теорема Гробовой Крышки немного ослабляет свои позиции, и мы можем доказывать разные свойства о наших функциях.
Тотальные языки - это очень интересная тема. О ней я выпущу отдельную статью.
Особенно понравился практичный чеклист процесса разработки с ассистентом — после него сложно продолжать относиться к AI как к магии, а не к инструменту, который усиливает сильных, но не спасает от отсутствия инженерной культуры.
Спасибо за пост. Интересно как в целом поменяется мнение автора спустя год, два
Я как раз из тех, кто за 16 лет разработки, из которых 8 лет профессионально, почти никогда не писал тесты, искренне не понимая, зачем они, так как на отладку тратил всегда мало времени и без них.
У меня свои проекты, на работе тоже проект библиотеки, который начинал сам с нуля, на которой крутятся рабочие проекты, которые создают другие. Обычно баг ловится сразу - запускаю рабочий проект, и ничего не рисуется или рисуется коряво. А дальше ртладчиком смотрю туда, где недавно что-то менял, и быстро нахожу причину.
За всё время получилась только пара smoke/fuzz тестов с кастомным сетевым протоколом и ещё одном месте, где ловил много багов, но я изначально ожидал их там встретить.
Помогает продуманная архитектура без дублирования кода и раскиданные по функциям ассерты-контракты. Код максимально переиспользуется благодаря универсальным абстракциям, поэтому кода, который нужно отлаживать, довольно мало, и почти все ветки кода ядра задействуются сами собой.
Если писать юнит-тесты, то при каждой итерации рефакторинга их придётся переписывать, а на это всегда было лень тратить время с учётом того, как мало его уходило на отладку и много на продумывание архитектуры.
Но с внедрением ИИ агентов стал покрывать тестами, и при обнаружении бага требовать воспроизводить его падающим тестом. Теперь ИИ агенты навёрстывают, покрывая код, и если надо, перепишут сами при рефакторинге, а потом сами будут их вызывать, подтверждая, что они действительно сделали задачу, а не сломали всё. Тут тесты реально стали нужны, чтобы вручную не просить агента переделывать по 10 раз по кругу.
Я тоже много проектов сам, искренне каюсь, писал без тестов и они работают до сих пор как часы годами. Проблемы начались, когда к проектам стали подключать разработчиков, которые не читали взрослых книг по разработке типа "Effective Java" Джошуа Блоха и стали безответственно комитить безумные вещи. Еще я подсмотрел, что почти во всех развивающихся opensource проектах на github тоже пишут тесты, т.к. работает сразу много людей над кодом. И да, согласен полностью, пусть AI-ассистент теперь пишет тесты, он, кстати, умеет делать это неплохо и это прекрасно!
Надо просто признать, что практически никто не любит писать тесты (отдельные уникумы, которым это в кайф, возможно существуют). И довольно мало людей умеют писать качественные тесты, которые проверяют поведение, не завязываются на конкретную имплементацию, не перебарщивают с моками и при этом понятны при чтении. Писать качественные тесты — это сложная работа, которая порой занимает больше времени и трудозатрат, чем написание самого кода. И если тесты пишутся быстрее, чем код, у меня обычно начинают возникать вопросы, а что собственно эти тесты проверяют и как.
Недавний пример — делал хотфикс для серьезного инцидента в проде. Сложились вместе дырки в сыре и выстрелило одно место, где несколько лет назад забыли вставить проверку на ошибку. Я насчитал 6-7 разных слоев абстракции, где можно было бы это поймать, если дополнительно обработать граничный случай, который в целом и так обрабатывался общей логикой. Фикс потребовал пять минут и меньше пятнадцати строк, добавляющий дополнительные проверки в нескольких местах. Написать тест, который воспроизводит проблему (при известных и очень простых шагах для воспроизведения), ломается, если откатить фикс, проходит если наложить фикс, не имеет ложных срабатываний ни в одну сторону, и написан так, что ясно, что именно он проверяет, занял около сотни строк и три с половиной часа.
А еще почти десять лет назад я написал программу, которую нужно было бесшовно проинтегрировать с пайплайном разработки, и ничего не сломать. Мне нужно было собрать доказательства того, что все работает корректно, нигде нет ошибок и багов, и это безопасно внедрять. Проблема была в том, что юнит-тестами там покрывать было нечего — отлично продуманная архитектура и разделение слоев абстракции привели к тому, что весь код тривиален. Но кода много, входные-выходные данные сложные, и целиком трансформация данных довольно сложная. Чем придумывать тесты самостоятельно, мне оказалось проще написать и прикрутить к ci скрипт, который в течение месяца шпионил за всеми пр в проекте, отлавливал те, где должна была работать моя программа, копировал файлы из пр, прогонял программу, сравнивал результаты с тем, что получалось без программы, и создавал мне ПР, добавляющий файлы в директорию, по содержимому которой я параметризовал один единственный тест. Результаты отличные, была найдена пара минорных багов, все проинтегрировано и работает. Недавно спрашивал бывших коллег, оно до сих пор работает, не глючит, хотя с тех пор никто к этому коду не прикасался вообще. Написать скрипт и собирать тест-кейсы с реальных данных было гораздо легче, чем писать тесты для проверки того же самого.
Хорошие тесты — это правда сложно.
Поэтому зачастую гораздо лучше работает подход, как в расте — сделать некорректный код невыразимым. Через ограничения системы типов и сигнатур функций добиться ситуации, когда код не может получить входные параметры, с которыми он не может корректно работать. Этот метод не панацея, тоже сложен, и требует хорошей инженерной дисциплины и опыта. Но в целом способен убирать широкий класс проблем и гарантировать ожидания даже лучше чем многие автоматические тесты. Отдельный плюс — такой код, зачастую хорошо самодокументирован. И по моим наблюдениям, это метод, который интуитивно предпочитают опытные специалисты, которые не хотят писать тесты.
Меня вот кстати всегда забавляла одна деталь в вайбкодерских сайтах, упомянутого agents.md тоже касается. Ни разу не фронтендер, но насколько я понимаю, чтобы ассеты нормально грузили везде, для них надо настроить адресацию, а не использовать артефакты next/static. Иначе сайт выглядит как месиво если не отключить кэш, и летит ошибка 304 в корпоративной сети.
Очарование от бямов сходит на нет, за ним идет обычная бытовуха.
Если максимально обобщать, то тесты это проверяемая спецификация. И по хорошему сами спецификации написанные на понятном агенту языке и являются в итоге тестами. Я это называют Agent Interface который расширяется в A2A коммуникацию и AX - агентский опыт.
Что касается математики, то проблема Геделя и Кантора в подмене объекта представлением, из-за чего и возникает тавтология. Нарраьив неограничен, поэтому он не полон и неконсистентен. Можно описать яблоко раздора в двух словах, а можно в двадцати томах. И это вмего лишь разный нарратив.
В борщ никто не кидает нарезанные страницы рецептов. И чем скорее великий алл это поймет, тем скорее теории валидации перестанут искать опору в разнузданных теориях множеств
“А еще - стоимость токенов постоянно снижается.”
Нет. Мир токеновых субсидий уходит в прошлое
https://github.blog/changelog/2026-04-20-changes-to-github-copilot-plans-for-individuals
"To prioritize service quality for existing paying customers, we will be pausing new signups for our Student, Pro, and Pro+ plans. Copilot Free remains open for new signups, and existing users can still upgrade between plans." Никаких новых подписок
"Opus models are no longer available on Copilot Pro. Opus 4.7 remains available on Pro+. As previously announced, Opus 4.5 and 4.6 will also be removed from Pro+." Никакого Опуса вне подписок дороже
даже не читая статью не ошибусь, если скажу что автор опять дудел про необходимость использования нейрокода в рабочем процессе. Все утюги нынче дудят синхронно.
И вот что бы я ему сказал на все его доводы.
Все, кто радостно побежал хватать и применять Клода и его друзей чтобы не остаться без работы - вы подобны тем, кто заряжал тазики с водой под Чумака и Кашпировского.
Да, вы подумали про свою личную жопу. А теперь подумайте про общую жопу.
Общая жопа в том, что отрасль, в которую не придут джуны сдохнет очень быстро.
Вопрос Вашего сокращения с навыками жизни с Клодом и без этих навыков уже решен.
Вы не обгоните приход AGI.
А как известно, чем выше залез - тем больнее будет падать. Меняйте стратегию.
Когда корабль тонет - крысы бегут.
Отсутствие притока джунов это и есть признак неминуемого потопления.
Особенно меня в этой ИИ-истории расстраивают архитекторы.
Хотя нет, вру, я всегда знал что 99% архитекторов - "ни о чем".
Архитекторами имеют право называться лишь те, кто создал принципиальные решения. Хотя бы какие то. Хотя бы одно.
Всем остальным, которые всю жизнь штамповали паттерны и сейчас пытаются "натягивать Клода на архитектуру" хочется сказать - вы должны быть ПЕРВЫМИ, кто скажет что ЗАВИСИМОСТЬ(Клод) это плохо.
Вы - продукт эпохи, когда вся архитектура с самого первого включения ЭВМ строилась по принципу избавления от зависимостей.
Утоните достойно, не позорьтесь.
Прочитайте плз. пост, я в нем о другом пишу, как раз поддерживаю Вашу позицию в том числе.
Anthropic блокирует погромистов с России и Беларуси так что автор опуса сдулся 🤷 Уничтожено буквально всё https://selectel.ru/blog/vendor-lockdown-anthropic-blocks-access-to-claude-from-russia/
С этими штуками БЯМ ассистентами пропадает чувство что что-то делал. Вроде весь день что-то делаешь, а по факту ничего. И делаю это не я. Виброкодинг превращается в цикл запросил-получи, не работает - правь само.
И никакой ответственности за то кто это писал и чей это код. Код ИИ естественно.
"Возникает вопрос, а не проще ли сразу написать программу на более строгом языке программирования..."
разумеется проще! напишу ниже про это отдельно.
меня прямо поражает насколько быстро все сдались в плане "подумать" -
весь опыт существования гомосапиенс нам обьяснял во всех доступных формах что нет и быть не может священного грааля одинаково хорошо помогающего всем и всегда. А тут нате....тазик с водой, заряжайте. С чего вы решили что универсальный ИИ в принципе будет "закрывать задачи" ?
Автор правильно описал историю с промптами - если погрузиться в модель, разложить промпт на параметры и покрыть все кейсы задачи тестами тогда да, о каком то применении в задачахз требующих верификации говорить можно. Правда остался один вопрос - пока модель генерит свое решение - сходить покурить? или ради этого мы сегодня изобретаем квантовые ПК?
Почему все кинулись к моделям для решения задач, которые гораздо правильнее и дешевле было бы закрывать при помощи DSL ?
DSL даст быстрое, верифицируемое(гораздо проще) решение.
Вы же не просите у ИИ выбрать вам данные из SQL БД ? А пользуетесь SQL.
Чтобы запросить те же данные из той же базы вам придется упомянуть все значимые части запроса. И тут нужен просто транслятор, а не универсальный ИИ с террабайтным аккумулятором(модель).
И это прекрасно - у нас появится больше свободного времени на самосовершенствование.
нет
Программирование с AI-ассистентом — похороните меня под плинтусом