Вирт:

Уменьшение сложности и размера должно быть целью на каждом этапе — в спецификации системы, дизайне и детальном программировании. Компетентность программиста следует оценивать по способности находить простые решения, а не по производительности, измеряемой в «количестве строк, выбрасываемых в день».
Плодовитые программисты способствуют определенной катастрофе.

Дорабатываю фрагмент статьи, нашел прекрасную цитату.

Всем хорошего дня.

#codemonsterslog

🚀 Со-творчество с машиной: как я создал валидатор контрактов без единой строки кода

Представьте: инженер надевает "костюм супергероя" в 5 утра, садится за Claude терминал и за 10 часов создает production-ready инструмент на Go с 300+ тестами, НЕ НАПИСАВ НИ ОДНОЙ СТРОКИ КОДА вручную.
Научная фантастика? Нет, реальность 2025 года.

🎯 Суть эксперимента:
Вместо Pact создал с машиной валидатор контрактов между микросервисами по AsyncAPI 3.0 спецификациям.

Идея простая: зачем писать дополнительные pact тесты в BDD-стиле, если спецификации уже содержат всю информацию о контрактах?

💡 Ключевые открытия:

TDD + ИИ = магия
- Маленькие итерации от тестов к коду
- Машина обнаружила 2 критических бага в процессе
- Ноль переписываний благодаря четкому проектированию модулей и структур сообщений для модулей

Проектирование решает всё
- Схемы иерархии модулей на бумаге
- Псевдокод основной функции
- Railway-oriented Programming для обработки ошибок, для упрощения потока программы
- "Один модуль — одна функция"

Роль инженера меняется кардинально
Из кодировщика в архитектора: формулируешь техзадание, рисуешь схемы, валидируешь результат. Машина делает всю рутину.

🔥 Результат:
Полнофункциональный валидатор контрактов с модульной архитектурой, исчерпывающим тестированием и стандартизированной обработкой ошибок. Готов к production.

💭 Главный инсайт:
Принципы структурного программирования 70-х + современные ИИ-ассистенты = мощнейшая комбинация.
Качественное проектирование становится единственным критическим навыком.

Читать статью

Мы живем в уникальном срезе реальности, где сбываются мечты программистов о "средствах автоматизации кодирования" из 1973 года.

Читать код валидатора контрактов

#codemonsterslog

Spec-driven development: программируем через спецификацию

Сначала была лаконичная спецификация. Потом был код на Go.
Без some-driven development сейчас ты не девелопер.

Наткнулся на статью, которая отлично дополняет мой эксперимент по кодированию с ИИ. Я тоже описывал задачу в README машине — и это работает.

Написать лаконичную спецификацию перед тем, как начнёшь кодить — правильный цикл разработки.
Причём сейчас, в эпоху ИИ-ассистентов, это не просто best practice, а рабочий инструмент.

Я заметил, что многие привыкли работать без предварительных «зарисовок» и описания желаемого результата.

Потом можно провести встречу без повестки, доски, стикеров, без протокола, просто походить и почесать языком часов 8 — и ты уже герой, получаешь 💰. Но результата ноль.

Цикл разработки прост:

1. Отредактируй спецификацию в main.md или README.md
2. Попроси ИИ-агента скомпилировать её в код Go
3. Запусти и протестируй приложение
4. Если что-то работает не так — обнови спецификацию

Повторяй, пока не получишь нужный результат.

Подробнее: https://github.blog/ai-and-ml/generative-ai/spec-driven-development-using-markdown-as-a-programming-language-when-building-with-ai/

#codemonsterslog #dev2dev

https://youtu.be/mfv0V1SxbNA?si=-1iRVOo0xTJYLob1

Linus собирает Linus-у комп и обсуждает много тем
#vibe

В конце года в 4-м квартале мы запустили Бэкенд Академию для аналитиков и тестировщиков, чтобы переквалифицировать сотрудников в бэкенд инженеров и дать возможность развиваться по бэкенд треку.
Для меня это стало настоящей отдушиной в конце необычного и классного года.
Я люблю инженеров и видеть рост компетенций у ребят - это большая радость.
Меня это сильно заряжает и мотивирует.

Я собрал команду единомышленников, мы провели первичный отбор из 67-ти инженеров отобрали 26.
Выстроили и постоянно улучшаем процессы, например процесс поэтапной аттестации, чтобы отслеживать насколько качественно усваивается материал и выполняются домашки.
Наша цель на выходе получить настоящих инженеров.
Программу построили от теории к практике, так как я убежден, что универсальные теории студенты смогут применять в карьере вне зависимости от стека.
Обучение построено по стандарту, который мы разрабатываем в параллель с инженерами.
От API First, Doc as Cod, до компонентных тестов и качественного проектирования софта до установки в кубер и сопровождения.
Про тестирования мы отдельно даем теорию и практику, чтобы инженер понимал, что от количества тестов качество софта не зависит. Что писать код программы и код тестов нужно меньше - так как это работа, которая стоит денег, а мы строим эффективное производство при котором меньше пишем, больше катим и меньше ошибаемся, а если ошибаемся и роняем, быстро поднимаем.

Про мифы тестирования и введение в структурное программирование собрал материал из классических трудов отцов основателей, просто понятно раскрыта суть вопроса без лишних модных терминов.
https://codemonsters.team/blog/2025/12/12/structured-programming-essential/

Дай пять.🙌

#codemonsterslog

Модульность программы: как писать код, который не превратится в хаос

  Модуль — это последовательность логически связанных фрагментов кода, оформленных как отдельная подпрограмма (функция, класс, сервис).

  Ключевой принцип: один модуль — одна функция.

  5 главных правил модульного кода:

  1. Один вход, один выход — модуль должен возвращать управление тому, кто его вызвал
  2. Небольшой размер — обычно 20-200 строк. Если больше — разделяй
  3. Единственная ответственность — функция модуля должна выражаться одной фразой: "Валидировать email", "Создать карточку клиента", "Вычислить возраст"
  4. Вертикальное управление — модуль может вызывать только подчиненные модули уровнем ниже. Главные решения принимает головной модуль
  5. Черный ящик — вызывающий модуль не должен знать о внутреннем устройстве вызываемого

  Почему это важно:
  - Проще тестировать
  - Легче вносить изменения
  - Меньше багов
  - Код можно переиспользовать

  На практике: начинай с нисходящего проектирования (top-down).
Сначала определи общую функцию программы, затем разбей на подфункции, потом детализируй каждую.

  Головной модуль — это краткий конспект всей программы.

 Читать полностью: ссылка на статью

https://codemonsters.team/blog/2025/12/15/program-modules/

#codemonsterslog

Математическое доказательство корректности программ

Собрал очень ценную статью про математическое доказательство правильности программы и формальное доказательство, которое мы используем при кодировании. https://codemonsters.team/blog/2025/12/30/program-correctness/

Для меня это особенно важная работа.

Показывает, как от математики мы переходим к инкапсуляции в ООП и типизации (формальному доказательству)

Правильная архитектура даёт нам 100% покрытие бизнес-логики юнит-тестами. Управляемое тестирование, а не тестирование ради процентного покрытия.

Взгляд на пирамиду тестирования уточняется.
Компонентные тесты превращаются в точную верификацию API, а не попытку протестировать крайние точки. Т.е. так мы можем на простом языке описать инструкцию к API нашего черного ящика, которая будет тестироваться автоматом и тут BDD раскрывается в полную силу.
Я напишу далее про это с отсылками к трудам отцов основателей.


Формируется мощный фрейм для программирования на русском языке с AI-ассистентами.
От классических основ к современному синтезу работы человека с машиной.

Бежим дальше.

#codemonsterslog

Увлекательная статья

https://cursor.com/blog/self-driving-codebases

Относитесь к модели как к блестящему новому сотруднику, который разбирается в инженерии, но не знает специфики вашего кода и процессов.

Увлекательный отрывок словно из соцреализма

Когда мы требовали 100% корректности перед каждым коммитом, это приводило к серьёзным проблемам с сериализацией и замедлению эффективной пропускной способности. Даже одна небольшая ошибка, например, изменение API или опечатка, могла привести к полной остановке всей системы. Рабочие выходили за рамки своих полномочий и начинали исправлять несущественные вещи. Множество агентов набрасывались друг на друга, пытаясь исправить одну и ту же проблему.

#vibe

Привет.
Две книги, на которые не жалко ни одной из четырёх тысяч недель.

Первая — «Четыре тысячи недель на всё». Оливер Беркман объясняет, почему попытки всё успеть — ловушка. И предлагает смотреть на время иначе.
Не как ресурс, который надо оптимизировать, а как ограничение, с которым стоит подружиться.
В сущности, я и есть время. Несмотря на то, что я старался держать мысли о конечности жизни в оперативке(вспоминал Хагакурэ), последние два года изрядно выбили из меня всю дурь.
Я иначе смотрю на своего пса, которому 9 лет — и времени вместе осталось не так много.
Я вернулся к вопросу: а чего хочу действительно я? Что мне дорого?

Обожаю мысленный эксперимент: как бы я провёл последний день на этой прекрасной планете?

Пошёл на Физикл 3.0, добавил больше прогулок, активности, силовых. Хочу выстроить для себя в систему адекватный ЗОЖ.
Недель у меня не так много. Хочу прожить и качественно. Энергии прибавилось, настроение улучшилось.

Вторая — «Как устроен мир на самом деле». Вацлав Смил настойчиво снимает розовые очки и показывает, на чём мир реально держится. Сталь, бетон, аммиак, энергия.
Без этого ни электромобили, ни ИИ — ничего нам не скажут.

После прочтения берегу две эти книги.

Если читал — поделись в комментах: чем тебя зацепила книга? Что изменил в своей жизни?

#codemonsterslog

Привет!
Меня зовут Максим Морев.

В серии коротких видео я
Просто рассказываю про научно обоснованную дисциплину рациональной разработки софта с ИИ.
Работал в ИТ джуном, СТО и начальником департамента.

Зачем мне это?
Потому что я двадцать четыре года собирал знания.
И теперь хочу передать это тебе.
Чтобы ты не наступал на те же грабли.
Чтобы ты не писал лишнего, как говорится не делал лишних движений.
Нафига страдать, когда можно не страдать?

Чтобы ИИ работал на тебя, а не жрал твой бюджет.
Чтобы ты уходил домой вовремя и жил жизнь.

Больше контента https://t.me/codemonsterslogs
#codemonsterslog #vlog #rationaldev