Программирование *

Дорожная карта Agentic AI. Level 1. Основы LLM и промпт-инжиниринг

Начну нашу дорожную карту Agentic AI с языковых моделей.

Сразу оговорюсь: важнее не глубина знаний про их устройство, а умение разбираться в широте возможностей и многообразии их применения. Иными словами, учимся профессиональному вождению, а не сборке автомобиля.

Важно ознакомиться с принципами работы моделей, генерации токенов, вариаций архитектур — на уровне того, чтобы понимать:

• параметры моделей и основные термины (размер, веса, токены, контекстное окно, галлюцинации),

• способы оптимизации (квантизация, прунинг, дистилляция),

• способности к размышлению, ведению диалога, следованию инструкциям, обработке не только текста, но и медиа-контента.

Главное — практиковаться. Я взял себе за правило: каждую задачу сначала через ИИ. Пишу код? Промпт. Анализирую данные? Промпт. Пишу письмо? Промпт. Делаю презентацию? Промпт.

Чтобы делать это качественно — прокачивайте навык писать промпты, изучите гайды по промпт-инжинирингу от вендоров. Результат на выходе зависит от качества контекста и точности инструкций.

Изучите гайды, пробуйте разные модели, начните с топовых: ChatGPT, Claude, Gemini, DeepSeek, Qwen. Отечественные: YandexGPT, GigaChat.

Прокачайте насмотренность, набейте руку, пройдите по аренам, лидербордам, бенчмаркам — научитесь понимать, в чём одни модели сильнее других.

На выходе будете как рыба в воде: выбирать модель под задачу и качественно с ней работать.

📚 Материалы

• Как работают LLM: Prompting Guide, визуализации — LLM Visualizer и Transformer Explainer, наш плейлист с объяснениями основ.

• Промпт-инжиниринг от вендоров: OpenAI Cookbook, Anthropic Prompt Engineering, Claude 4 best practices.

• Выбор модели: видео-гайд, лидерборды — LM Arena, LLM Arena RU, SWE-bench. Хаб моделей: Hugging Face.

🔔 Следующая тема: AI-driven разработка — как грамотно ускорять разработку в X раз.

⬅️ Предыдущая тема: Дорожная карта Agentic AI. Интро

Подписывайтесь, пожалуйста, чтобы не пропустить!

🎓 Бесплатные мероприятия на этой неделе

• 📅 9 апреля, чт 18:00 — Онлайн-разбор продакшен-кейса «ИИ-агент консультанта 1С»

• 📅 13 апреля, пнд 16:00 — AI-driven практикум «ИИ-агент с нуля за один эфир»

👉 Записывайтесь на мероприятия в наших ботах: Telegram или ВКонтакте

Ознакомьтесь с нашей траекторией роста по AI-driven разработке и ИИ-агентам.

ИИ-код и линтеры: статический анализ проекта на 85 000 строк

ruff (Python) — 73 замечания на 63 000 строк. 1.2 на 1000 строк.

Состав: 39 неиспользуемых импортов, 17 неиспользуемых переменных, 6 forward references, 5 f-строк без подстановок, 5 лямбд вместо def. Ноль ошибок, от которых код падает в рантайме.

ESLint (React/TypeScript) — 0 ошибок, 5 warnings на 21 000 строк. Все пять — рекомендация Next.js использовать <Image> вместо <img>.

Для сравнения:
- Зрелый проект с CI-линтингом — 0–2 замечания на 1000 строк.
- Без линтинга — 5–15.
- Легаси — 20–50.

У нас 1.2 и 0.24, при том что CI-линтинга в проекте нет. Claude и Codex запускают ruff и eslint сами на каждое изменение — я вижу это в логах. Результат соответствующий.

Безопасность

ruff и ESLint проверяют стиль, не безопасность. По совету из комментариев прогнал bandit — security-сканер для Python.

1 432 находки. Реальных уязвимостей: 0.

• 2 HIGH — SHA1 для fingerprint'а шахматных партий. Это не криптография, а генерация коротких ID для внутренней классификации. Подделывать бессмысленно.

• 5 MEDIUM «SQL injection» — bandit видит f-string в SQL-запросе и сигнализирует. Но внутри f-string стоят только ?-плейсхолдеры, данные идут параметрами. Классическая параметризация, инъекция невозможна.

• 4 MEDIUM «url open» — HTTP-клиенты Lichess, Chess.com, OpenRouter. URL из конфига, пользователь не контролирует.

• 1 421 LOW — 1 250 assert'ов (bandit предупреждает, что assert удаляется при запуске с -O, но Django и Celery никто так не запускает), остальное — try/except/pass в опциональных ветках.

Фронтенду отдельный security-сканер не нужен: React экранирует HTML автоматически, dangerouslySetInnerHTML не используется, фронт не работает с БД, файлами и процессами.

85 000 строк, три сканера, ноль реальных уязвимостей. ИИ-код не нуждается в оправданиях — он нуждается в проверке. Проверили. Чисто.

p.s. Проверку проходил код из статьи Вайбкодинг по Chess’ноку. 1. e4

Как за 11 лет разучиться дебажить: когнитивная атрофия от AI-инструментов

На Reddit разработчик с 11-летним стажем описал тревожный момент: он не смог отладить баг в собственном коде без Claude. Не потому что баг сложный, а потому что разучился генерировать гипотезы самостоятельно.

Что произошло

Разработчик столкнулся с нестабильным багом сетевых таймаутов в продакшене. Сервис писал сам, два года назад. Раньше подобная проблема решалась за час методичной работы. Теперь 40 минут пинг-понга с Claude без результата.

Когда он закрыл чат и попробовал разобраться сам, обнаружил: внутренний диалог, который раньше подсказывал «проверь пул соединений», «может retry storm», «посмотри балансировщик», стал заметно тише.

Баг он в итоге нашёл. Но медленнее, чем три года назад, когда AI ещё не использовал.

Почему это не про «AI плохой»

Автор подчёркивает: инструменты полезные, он пользуется ими каждый день. Проблема в другом. Навык генерации гипотез в условиях неопределённости деградирует без практики.

Это подтверждает концепция Cognitive Offloading. При систематическом переносе мыслительных операций на внешние инструменты ослабевают нейронные связи, отвечающие за эти процессы.

Классический пример — GPS-навигация. Исследование в Nature Communications (2017) показало: люди, которые постоянно ездят по навигатору, хуже справляются с задачами пространственной ориентации, чем те, кто периодически строит маршруты сами.

Где это ломается у разработчиков

На практике выделяются три зоны риска:

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

Валидация решений
Раньше разработчики продумывали архитектуру и решения самостоятельно. Теперь часто тянутся к AI за подтверждением. В итоге снижается доверие к собственной экспертизе.

Коммуникация
Некоторые прогоняют через AI даже сообщения коллегам. Возникает размывание авторства мысли: это ты формулируешь или инструмент за тебя.

Контраргумент: а Stack Overflow?

Частое возражение: разработчики годами копировали решения с Stack Overflow и не деградировали.

Разница в модели взаимодействия:

1. Нужно сформулировать проблему

2. Найти релевантный ответ

3. Адаптировать решение под свой контекст

С AI можно просто описать симптомы и получить готовый ответ. Порог входа ниже, а значит выше риск делегировать мышление полностью.

Что делать: практические подходы

Правило 5 минут
Перед тем как открыть Claude, потратить 5 минут на самостоятельный анализ stack trace. Это простой способ «включить» мышление.

Unplugged-сессии
Периодически дебажить без AI. Например, один час в неделю. Это не ограничение, а тренировка.

Приходить с гипотезами
Разница между джуном и сеньором в работе с AI: джун ждёт решение, сеньор приносит несколько гипотез и использует AI как инструмент проверки.

Рефлексия после решения
После решения с помощью AI зафиксировать, какие гипотезы ты мог бы выдвинуть сам. Это возвращает осознанность процессу.

Честно

Я не демонизирую AI-инструменты. Сам использую ежедневно. Но когнитивная атрофия — реальный риск, который стоит учитывать.

Если вы программируете много лет и замечаете, что раньше справлялись быстрее без AI, это не паранойя. Навык требует практики, а делегирование мышления — это решение с определённой ценой.

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

Если кто-то вдруг использует мой Licensedog для сбора информации о техстеке.

С сегодняшним обновлением, оно успешно разыскало в интернете и проверило все 5546 зависимости одного из наших проектов, кроме 4 мусорных внутренних библиотек.

Научил работать с Java (раньше были только Python, JS и Go). Починил целую пачку багов.

Это такой краулер, который принимает на вход SBOM (в виде CSV или cyclonedx) и потом сомневается в нем: старается обойти интернет, и на самом деле физически найти файлы с лицензиями. Выкачать их репозиториев, распаковать из архивов, или даже открыть в барузере их сайты и распарсить веб-странички. И фактически проверить на соответствие. В отчете описывает, что и откуда взялось, и почему она думает что лицензия на самом деле не MIT а GPL. На выходе получается CSV или JSONL файл, который можно отгружать безопасникам на ревью.

Исходники - как всегда, на GitVerse.

https://gitverse.ru/anarchic/licensedog

Дорожная карта Agentic AI: от основ до production-ready агентных систем

Друзья, я решил в апреле разобрать горящую тему этого года - что надо знать и уметь для разработки production-ready ИИ-агентов.

По сути, это будет своеобразная дорожная карта Agentic AI Engineering — по этапам, от основ до зрелых систем.

Я буду выкладывать небольшие посты с раскрытием важных тем и ссылками на полезные материалы.

Пройдем по следующим темам, которые нужно освоить, чтобы создавать агентные системы готовые к продакшену:

• Основы языковых моделей и промпт-инжиниринг,

• Работа с LLM API и структурированный вывод,

• AI-driven разработка с ИИ-агентами,

• Мультимодальность — голос, изображения,

• Local inference — локальный запуск моделей,

• RAG — как передать агенту знания о вашем бизнесе,

• Agents — агенты с памятью, инструментами и планированием,

• MCP — стандарт интеграции агентов с внешними системами,

• Observability & Evaluation — мониторинг и оценка качества RAG-систем и агентов,

• Security & Guards — безопасность агентных систем,

• Управление датасетами и промптами,

• Сontext-engineering — работа с большим контекстом,

• Skills — навыки агентов,

• Agent harness — решение сложных задач, субагенты и планирование,

• Multi-agents — мультиагентные системы.

В конце серии сформируется понимание того, что и в каком порядке осваивать, чтобы создаваемые решения работали в реальных условиях, а не оставались брошенными игрушками.

Это вводный пост с приглашением подписываться, чтобы не пропустить следующие темы.

Кстати, если есть пожелания по темам, что стоит добавить, то пишите в комментариях, пожалуйста.

🔔 Следующий пост: основы языковых моделей — с чего всё начинается.

Больше про ИИ-кодинг и ИИ-агентов в ТГ и ВК.
Приглашаю ознакомиться с нашими онлайн-курсами по ИИ-разработке ИИ-агентов.

Разработчик Александр Гомес Гайгалас (Alexandre Gomes Gaigalas), автор библиотеки coral для создания переносимых shell-скриптов, опубликовал проект C89cc.sh. Это компилятор для языка C, написанный целиком на Shell.

Компилятор поддерживает стандарт C89 и может генерировать исполняемые файлы в формате ELF64 для систем x86-64. Исходный код проекта содержит около восьми тысяч строк и открыт под лицензией ISC.

Будет слишком по девчачьи сказать, что я плакала из-за код ревью?

Это было года три или четыре назад, когда я ещё не нашла общий язык со своим новым тех.лидом. Тогда много всего накопилось, и каждый новый комментарий, хоть он и был очень корректным, ощущался как еще один удар сверху. Помню было что‑то из серии: «Тут надо изменить нейминг».

Ничего такого, вроде все ок. Но я смотрела на него и зависла в моменте: а что именно не так то? Есть какие то правила в новой команде, о которых я еще не знаю? Нужно переименовать только эту переменную или мне нужно пройтись по всему файлу?

Начинаешь писать ответ, ждешь уточнения, потом опять ответ... В какой то момент я просто закрыла ноут и разревелась. Я уже находилась в состоянии нервного клубка и такие комментарии добивали больше, чем любой жёсткий разнос.

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

Мне захотелось поделиться своими мыслями на тему код-ревью, о том как формулировки влияют на скорость работы и состояния людей:

Ссылка на статью

Если хоть раз сидел и думал: «что от меня тут вообще хотят?» — ты точно поймёшь :)

Как делать бизнес-процессы как в n8n — безопасно и масштабируемо? Узнаете на конференции GoCloud 2026 ☁️

Расскажем, как обойти лимиты n8n для enterprise- и ИИ-систем: живой трейсинг и метрики из коробки, предсказуемое масштабирование, нативная работа с кастомными моделями машинного обучения и мультиагентными системами. Плюс бесшовный импорт сценариев из n8n без простоев. В финале — живая миграция реального воркфлоу за минуты.

Спикер: Владислав Янковский — старший Go-разработчик, Cloud.ru

Трек: Прикладной ИИ

📅 Когда: 9 апреля в 16:40–17:00 мск
👉 Зарегистрироваться

А пока ждете выступление, загляните в блог: NoCode инструменты для создания AI-приложений с RAG: быстрый старт

Cursor или Harvi Code: какой ИИ для кодинга в 2026 году реально работает в России без VPN и головной боли с платежами

В 2026 году почти каждый разработчик в России стоит перед одним и тем же выбором: хочешь мощный ИИ, который реально ускоряет разработку, или хочешь, чтобы всё работало просто, без посредников и ежемесячных нервов с оплатой.

Cursor — это сейчас, пожалуй, самый продвинутый AI-редактор на рынке. По сути, это VS Code, в который встроили настоящий искусственный интеллект на стероидах. Composer позволяет одной командой править сразу десяток файлов, агент понимает весь проект, хорошо справляется с рефакторингом, поиском багов и даже архитектурными решениями. Качество кода от Claude Sonnet 4.5 или свежих GPT часто вызывает искреннее «вау».

Но есть большая ложка дёгтя. Cursor — американский продукт, и российские карты он не принимает. Чтобы купить подписку Pro, приходится либо использовать виртуальные карты через крипту, либо платить посредникам (Oplatym и подобные), либо покупать готовые аккаунты (что рискованно). Сам редактор после оплаты работает без VPN, но первоначальная настройка оплаты — это отдельный квест. Бесплатная версия быстро упирается в лимиты, особенно если активно юзаешь мощные модели.

Harvi Code — Первый в России AI кодинг-агент. Российский ответ на все эти заморочки. Это полноценный AI-агент прямо внутри VS Code. Пишешь задачу в чате — он генерит код, рефакторит, фиксит баги, работает с контекстом всего проекта. Не тормозит, контекст держит хорошо, интерфейс привычный.

Самое приятное — модели на любой бюджет. Есть топовые (Claude Sonnet 4.5, GPT-5.4 и другие). А главное — очень низкая стоимость токенов. Для каждой модели есть свой коэффициент стоимости. Для большинства повседневных задач их хватает с головой, и можно вообще почти не тратить деньги. Оплата — российскими картами или СБП, без всяких посредников и VPN.

Коротко по делу:

• Если тебе нужен мощный multi-file agent и ты готов один раз настроить оплату через проверенного посредника — бери Cursor. Он до сих пор в топе по возможностям.

• Если хочешь работать стабильно, без лишних телодвижений и не думать каждый месяц про «как бы оплатить» — Harvi Code сейчас выглядит гораздо практичнее для российского разработчика.

А вы как сейчас кодите с ИИ? Пробовали оба варианта? Что в итоге оставили в основном редакторе? Пишите в комментариях, интересно почитать реальный опыт.

Господа, добрый день! Я собираюсь выпустить статью о языке программирования Lean.
Он сочетает в себе два назначения: это одновременно и язык программирования, и средство доказательства теорем. И они помогают друг другу. На языке программирования Lean можно писать тактики, которые помогают упростить доказательства, а при помощи средств доказательства можно гарантировать, что наша программа корректна!

Язык очень молодой, сообществу нужны программисты, а не только математики, чтобы сделать язык готовым к промышленному применению. Сейчас очень не хватает многих прикладных библиотек. Язык то вышел в этом десятилетии! Причём многие из этих библиотек - низко висящие фрукты - их довольно легко написать!

Скажите, о чём бы вы хотели прочитать в моей будущей статье? Какие аспекты вам наиболее интересны? Решение какого-нибудь примера? Или просто обзор языка и его экосистемы? Может быть, рассказ о том, как для написания доказательств используют искусственный интеллект?

Предлагайте свои варианты и задавайте вопросы.

Делаем мир чуть чуть лучше

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

Буквально недавно я так дебажил одну рубишную либу и выяснилось что там внутри есть косячки. Не долго думая, прямо в той же сессии я попросил агента собрать ишью дал линк на репу и потом просто скопировал это туда на гитхаб (наверное можно было попросить его сделать ишью автоматом, попробую так в следующий раз). Получилось очень обстоятельно с примерами кода, описанием того где ошибка. При желании можно было бы сразу пулреквест кинуть, но я не был уверен в какую сторону решит пойти автор либы. Вот кстати тот ишьюс. И фикс был сделан буквально в тот же день.

В общем не ленитесь, помогайте разработчикам опенсорс либ, которые вы используете. Это и вам плюс в карму (и в портфолио) и благодарность людям, на которых держаться наши проекты

Большинство ИИ-агентов работают так: сгенерировал — опубликовал. Что получилось — то и вышло.

Наш агент Фроня (Фронезис) устроен иначе. Прежде чем что-то опубликовать, он устраивает совет внутри себя — и только при согласии двух из трёх действует. Byzantine consensus: если один ошибается или галлюцинирует, остальные блокируют.

Но этого мало. Каждое решение запечатывается криптографической подписью до выполнения — не после. Это Leibniz Layer™, наш протокол верификации. Любое действие агента можно проверить по хэшу в любой момент.

Скриншот ниже — реальный пример: агент заблокировал свой собственный пост и рефлексирует по этому поводу.

Не побоимся этого слова — первый в мире агент который подписывает свои решения до действия и позволяет любому их проверить. leibniz.fronesislabs.com

29 демо-уроков для тех, кто не стоит на месте

Привет, Хабр. Эти уроки проводят преподаватели курсов Отус в преддверии старта новых потоков. На них можно узнать о формате обучения, пообщаться с экспертами и заодно закрыть пробелы в знаниях по интересующей теме. Это бесплатно. Приходите!

• 25 марта 20:00
  РазвИИтие на основе ClickHouse: базы данных для искусственного интеллекта

• 25 марта 20:00
  Кракозябры vs Java: как победить кодировки и стать гуру Unicode?

• 25 марта 20:00
  Типы данных, переменные и функции в Rust

• 25 марта 20:00
  Инструменты профилирования и оптимизации в Go

• 25 марта 20:00
  Механизмы блокировок в PostgreSQL

• 26 марта 20:00
  Путешествие запроса в PostgreSQL: от разбора до исполнения (от parser до executor)

• 26 марта 20:00
  NestJS и архитектура масштабируемых серверных приложений на Node.js

• 26 марта 20:00
  Проектирование RAG систем

• 30 марта 19:00
  Расширение возможностей автоматизации через REST API

• 30 марта 20:00
  Чтение CSV — вход в Spark

• 30 марта 20:00
  Spring Boot Actuator: основы мониторинга и управления приложением

• 30 марта 20:00
  Индексы в PostgreSQL

• 30 марта 20:00
  Стили взаимодействия микросервисов: 5 секретов, которые изменят ваш подход к backend-разработке

• 30 марта 20:00
  Основные шаблоны проектирования в системном дизайне

• 31 марта 20:00 SQL:
  Оконные функции — когда GROUP BY уже не хватает

• 1 апреля 20:00
  Scala + Cats: аккумулируем ошибки с Validated без боли

• 1 апреля 20:00
  Создание интерфейсов с помощью OpenAPI

• 2 апреля 20:00
  Анатомия памяти: типы данных, способы хранения, аллокации и работа GC

• 6 апреля 20:00
  Ошибки системного аналитика при описании REST API

• 9 апреля 20:00
  PostgreSQL как векторная база данных: ИИ-поиск без лишних сервисов

• 9 апреля 20:00
  Realtime на Node.js и TypeScript: создаём WebSocket-чат и разбираем архитектуру backend

• 9 апреля 20:00
  Модели восстановления в SQL Server: как не потерять данные и настроить бэкапы правильно

• 13 апреля 20:00
  Как работают структуры данных C# «под капотом»

• 13 апреля 20:00
  Telegram-бот с искусственным интеллектом на Python

• 14 апреля 20:00
  Case classes и pattern matching: суперсила Scala на практике

• 14 апреля 20:00
  Влияние нефункциональных требований на архитектуру

• 15 апреля 18:00
  Основы протокола HTTP

• 15 апреля 20:00
  OpenAPI + Spring

• 15 апреля 20:00
  Основы проектирования бизнес-логики в микросервисной архитектуре

Еще больше бесплатных уроков от преподавателей курсов можно посмотреть в календаре мероприятий.

Ускоряем разработку в разы: специалист по ИИ собрал пять репозиториев для Claude Code, чтобы автоматизировать большинство задач в рутине программиста:

• Superbase CLI — управление миграцией БД на PostgreSQL, генерирует типы из схемы БД, создаёт аутентифицированные HTTP-запросы.

• Skill Creator — позволяет создавать агентные скиллы без лишних заморочек, постоянно улучшаете и оттачиваете навыки Claude для конкретных задач.

• Get shit done — создаёт легковесную систему разработки с контекстным инжинирингом и поддерживает Claude Code, OpenCode, Gemini CLI, Codex, Copilot, и Antigravity.

• Notebooklm-py — обеспечивает программный доступ к фичам NotebookLM, который очень хорошо будет смотреться с агентами Claude Code, Codex, и OpenClaw.

• Obsidian.md — аналог NotebookLM со схожим функционалом, который работает в России и в него можно интегрировать Claude, чтобы получить мощный ворфлоу.

Сделал процедурное сердечко на движке игры - получилось прикольно!

Как обычно, используются только символы с обычной клавиатуры. Не вращаются, не масштабируются и не искажаются. Почти текстовый режим с единственным исключением - вывод в произвольных координатах.
Новый вариант движка игры отрабатывает отлично! На этой сцене у меня стабильно 200fps на моем неттопе.
Сердце полностью процедурное. Никаких моделей - только формулы.

Базовый код очень простой:

    public void GenerateHeart(int n, string str, Color color, float minDistance = 1.01f) {
        float r, y, theta;
        float goldenRatio = (1f + Mathf.Sqrt(5f)) / 2f;
        float offset = 2f / n;

        for (int i = 0; i < n; i++) {
            y = (i * offset - 1) + (offset / 2);
            r = Mathf.Sqrt(1 - y * y);
            theta = 2 * Mathf.PI * i / goldenRatio;
            PutCharToHeart(theta, Mathf.Acos(y), str[i % str.Length], color, minDistance);
        }
    }
    
    public void PutCharToHeart(float u, float v, char ch, Color clr, float minDistance, float scale = 1f, CharAnim chanim = null) {
        float sinV = Mathf.Sin(v);
        float cosV = Mathf.Cos(v);
        float sinU = Mathf.Sin(u);
        float cosU = Mathf.Cos(u);
        float x = sinV * (15 * sinU - 4 * Mathf.Sin(3 * u));
        float z = sinV * (13 * cosU - 5 * Mathf.Cos(2 * u) - 2 * Mathf.Cos(3 * u) - Mathf.Cos(4 * u));
        float heartY = 8 * cosV;
        Vector3 point = new Vector3(x, heartY, z) * scale;
        bool tooClose = false;

        foreach (var existing in points)
            if (Vector3.Distance(point, existing) < minDistance) {tooClose = true; break;}

        // Add
        if (!tooClose) {
            points.Add(point);
            pointsView.Add(point);
            codes.Add(ch);
            colors.Add(clr);

            if (chanim == null) {
                flags.Add(0);
                anims.Add(null);
            } else {
                flags.Add(FLAG_ANIM);
                anims.Add(chanim);
            }
        }
    }

Получилось вроде симпатично! Думаю добавить в игру. Не забудьте поиграть в текущую версию игры на Steam.

Как развивается и куда движется «русское техно»? Обсудим на ИТ-вечере 26 марта 😎

Поговорим про особенности инженерной культуры в больших ИТ-компаниях, практики внедрения ИИ в разработку, автоматизацию код-ревью и использование LLM без ущерба для безопасности. В программе эксперты из МТС Web Services, СберТех, red_mad_robot и Авито.

Будет интересно бэкенд- и ML-разработчикам, которые строят современные российские ИТ-системы, а также всем, кто интересуется ИИ-практиками в разработке. Участников ждут актуальные кейсы, дискуссии, активности от MWS GPT, нетворкинг и атмосфера техно-вечеринки с ИИ-треками.

📅 Когда: 26 марта (четверг) в 18:00 по мск

📍 Где: офлайн в парке Сокольники в Москве + онлайн 

Успевай записаться — количество участников ограничено.

👉 Зарегистрироваться

Недавно перешел с Nixpkgs на Nix Flakes. После третьего флейка начал задумываться над их публикациями и обнаружил, что репозитория для флейков по сути нет. Поиск проектов на гитхабе не различает nix репозитории по типам. Есть NUR (Nix User Repository), но он появился до флейков и просто так добавить в него чистый флейк репозиторий без дополнительных приседаний нельзя. Плюс процесс публикации требует прохождения ревью, что весьма неинклюзивно и мешает развитию экосистемы.

Flakes стали относительно зрелыми и решают проблему центрального репозитория. Однако в репозитории Nixpkgs на GitHub всё ещё остаётся более 5 тысяч открытых задач и сопоставимое количество пулреквестов, и он продолжает ежедневно получать множество коммитов. Добиться включения пулреквеста с новым инструментом в Nixpkgs может быть сложно — файл README репозитория Nixpkgs прямо не рекомендует пользователям добавлять свои «любительские» проекты. На nix форуме существует "вечная" тема посвященная пулреквестом оставшимся без внимамия.

Флейки, это чистные самодостаточные функции, которые должны компноваться значительно легче файлов с произвольными nix выражениями, но до сих пор не отвлекли внимание от nixpkgs. Считаю, что причиной этому может быть отсутсвтие конвенционального репозитория с возможностью поиска зависимостей и удобным интерфейсом для публиции того, что не хватает по мнению автора.

Репозиторий Nixpkgs огромен. Он содержит более 120 тысяч пакетов, но большинство из них не являются нативными для Nix. Например, около 10% составляют импортированные пакеты Haskell. Поэтому такое большое число не может служить надёжным показателем того, насколько хорошо развит процесс публикации в Nix. К примеру, только в репозитории PyPy сейчас насчитывается почти 900 тысяч пакетов. Аналогичные подход можно встретить и в Java - Maven Nexus, и в NodeJS - npm, и в Perl - CPAN...

Также важно отметить, что Python — самый популярный язык программирования общего назначения, и его процесс публикации был разработан программистами для программистов. Однако в этом рабочем процессе нет этапа пулреквеста! По сути, интерфейс работает по принципу «загрузил и забыл», что положительно влияет на конверсию пакетов Python.

Flakes легко устанавливать, но процесс их публикации пока недостаточно отлажен. Текущий подход к распространению flakes, по-видимому, унаследовал многие черты рабочего процесса Nixpkgs.

Для Nixpkgs это был естественный путь развития, поскольку все деривации образуют большое и связанное Nix-выражение, разбитое на множество файлов внутри одного Git-репозитория.

Размышления выше мотивировали меня написать сайт для управления классическим репозиторием специально заточенным на флейки.

a-piece-of-flake-nix-repository

5 правил программирования Роба Пайка:

• Правило 1. Невозможно предсказать, где программа будет тратить время. Узкие места возникают в неожиданных местах, поэтому не пытайтесь угадывать и использовать ускорение, пока не докажете, что именно там находится узкое место.

• Правило 2. Измеряйте. Не оптимизируйте скорость, пока не измерите, и даже тогда не делайте этого, если только одна часть кода не превосходит остальную.

• Правило 3. Сложные алгоритмы медленны, когда n мало, а n обычно мало. Сложные алгоритмы имеют большие константы. Пока вы не узнаете, что n часто будет большим, не усложняйте алгоритмы. (Даже если n станет большим, сначала используйте Правило 2.)

• Правило 4. Сложные алгоритмы содержат больше ошибок, чем простые, и их гораздо сложнее реализовать. Используйте простые алгоритмы, а также простые структуры данных.

• Правило 5. Данные доминируют. Если вы выбрали правильные структуры данных и хорошо всё организовали, алгоритмы почти всегда будут очевидны. В программировании центральное место занимают структуры данных, а не алгоритмы.

Уточнения:

• Правила 1 и 2 Пайка перефразируют знаменитую максиму Тони Хоара: «Преждевременная оптимизация — корень всех зол».

• Кен Томпсон перефразировал правила 3 ​​и 4 Пайка как «В случае сомнений используйте грубую силу».

• Правила 3 ​​и 4 являются примерами философии проектирования KISS (Keep It Simple, Stupid).

• Правило 5 ранее было сформулировано Фредом Бруксом в книге «Мифический человеко‑месяц». Правило 5 часто сокращают до «пишите глупый код, использующий умные объекты».

Все эти споры о Новой Технологии — «Вайб‑Кодинг»... да было это все уже...

Только в 90-х называлась «парное программирование» XP (Extreme Programming)... только подручными средствами.

Найдете книгу — Кент Бек Экстремальное программирование (eXtreme Programming, XP)... Ну и вопрос прост — где вы с ним встречались? Ответ — нигде...умерло и чего? аааа... так как предназначалось для решения узкого круга задач — посмотрите и пределы и ограничения... а посмотрев как развивалось — увидите.. такой подход узко применим, он будет, но в мелкий соответствующих задачах, и большую систему на нем не построишь.

Сейчас то же самое, только вместо одного из программеров, рядом — тупые агенты с их «Чего господин молодой программист — желает» )))

Следующая проблема — агенты... с их «Будь полезен».. тоже методологическая проблема «Почему принцип „будь полезен“ убивает команды и ИИ‑агентов»

Да и вообще.... то что наваяли по Agile — не сработает, и проблема снова та же — отсутствие знания базовых технологий! Agile то.. это облегченная технология для спиральной разработки.

И Agile — та же история. Облегчённая версия спиральной разработки Боэма. 1988 год. Взяли — упростили — потеряли главное. Спиральная разработка учитывала риски, архитектуру, масштаб. Agile оставил итерации и выбросил всё сложное )))

Большую систему на «спиральной» по Agile не построишь — нужен водопад с правильно выстроенной архитектурой на входе. А на Agile большую систему не построишь вообще — там каждые две недели спринт и никто не думает о том что будет через год )))

Полная «спиральная разработка» — включает баланс между Каскадная модель (Waterfall model) + Итеративная модель (Iterative model). Agile и Scrum — игнорирует структурную часть.

И молодые разработчики не знают ни Боэма ни Руча ни даже нормального RUP. Знают Scrum и думают что это всё что есть )))

Олдфаги помнят CASE (Computer‑Aided Software Engineering)‑системы из 90-х — это была первая великая попытка «запрограммировать программирование». Тогда нам тоже обещали мир без кода. Не взлетело, потому что инструменты были кривые, а сложность систем росла быстрее, чем наши навыки моделирования. Сегодняшний ИИ — это CASE‑система, которая наконец‑то заработала.

Почему CASE — это «дедушка» ИИ (и почему тогда не взлетело):

1. Та же фигня, вид в профиль: Тогда тоже кричали: «Кодеры больше не нужны! Будем только рисовать квадратики!». Но выяснилось, что чтобы нарисовать «квадратики» правильно, нужно обладать еще более жесткой логикой, чем для написания кода. ИИ сегодня — это CASE‑система на стероидах, которая наконец‑то научилась понимать не только стрелочки, но и живую речь.

2. Проблема «Грязного входа»: В 90-х CASE‑системы разбивались о то, что люди не могли внятно нарисовать, чего они хотят. «Мусор на входе — мусор на выходе». Сейчас с ИИ ровно та же история. Если у тебя в голове каша, то никакая нейронка (как и Rational Rose в своё время) тебе рабочий продукт не выдаст.

3. Уровень абстракции: CASE пытались поднять нас над кодом. ИИ делает то же самое. Но тогда «процессорной мощности» мозгов у массы айтишников не хватило, чтобы перейти от «ковыряния в гайках» к «проектированию смыслов» (была даже UML (Unified Modeling Language)). Сейчас — дубль два. Только теперь отсидеться в окопах синтаксиса не получится.

P. S. Вот и смотрю... с каким рвением изобретают «велосипед»... может книги почитать нужно? про указанные в посте технологии?

P. S.S. И вот реально, я бы порекомендовал ознакомиться — UML (Unified Modeling Language).

Зелёные тесты ≠ хорошие тесты

Впервые в истории писать тесты стало легко и совсем не страшно. Вокруг теперь у всех покрытие 80%, 90%, а то и вовсе 100%. И вот тут начинается проблема: зелёные тесты ≠ хорошие тесты.

Проблема в метрике, которой мы все привыкли доверять. Code coverage считает строку протестированной, если она выполнилась во время теста. Всё. Не «поймает ли тест баг в этой строке», не «проверяет ли он правильность результата» — просто выполнилась. Можно написать тест без единого assert, и покрытие вырастет. 500 тестов, 90% coverage, а пользы ноль.

Мутационное тестирование — это совершенно другой путь. В простейшей реализации этот инструмент тупо берёт твой код и намеренно ломает его: меняет > на >=, + на ‑, True на False. Каждая такая поломка — мутант. Если после мутации все тесты по‑прежнему зелёные — значит они ничего не проверяют. Покрытие есть, защиты нет.

Почему это важно именно сейчас?

Потому что нейронка любит зелёненькое. Чем больше зелёных тестов — тем субъективно лучше. 100 тестов внушают больше доверия, чем 10, правда? А внутри там assert response.status_code == 200. assert result is not None. assert len(items) > 0. Тест проверяет, что функция вернула хоть что‑то — и радостно зеленеет. Поменяй логику условия, перепутай знак, сломай граничный случай — тест всё равно зелёный. Потому что он проверяет не правильность, а наличие.

Мутационное тестирование — единственный автоматический способ это поймать. Метрика называется mutation score: процент убитых мутантов. 60% — плохо. 90%+ — тесты реально что‑то защищают.

Кое‑какие инструменты для такого тестирования уже есть: mutmut и cosmic‑ray для Python, Stryker для JS/TS, PIT для Java. Медленно? Да, значительно медленнее обычного тест‑рана. Но запускать его не нужно на каждый коммит — достаточно на PR в критические модули.

Но есть нюансы. А где их нет, правда?

Первый: мутации рандомные. Замена > на >= — это не баг, который кто‑то реально допустит. Это синтетическая поломка. Половина мутантов генерирует код, который в реальности никогда не появится. Ты тратишь время на убийство мутантов, которые не имеют отношения к настоящим ошибкам. Это как тестировать замок, ковыряя его вилкой — формально проверка, по факту мимо.

Второй — ещё хуже. Чтобы убить мутанта, тест должен зафиксировать конкретное поведение. Каждую ветку, каждое значение, каждый edge case. Доведи mutation score до 100% — и ты прибил гвоздями каждую строчку кода. Буквально. Теперь попробуй отрефакторить. Переименовал внутренний метод — 40 тестов красные. Поменял порядок полей в ответе — ещё 20. Тесты превращаются из страховки в кандалы: код работает правильно, но тесты падают, потому что они проверяют не поведение, а реализацию.

Это реально ловушка. Слишком гонишься за mutation score — получаешь хрупкие тесты. Не гонишься — получаешь видимость тестирования.

Перемены — впереди!

И вот тут становится по‑настоящему интересно. Представь, что мутации генерирует не тупой набор правил «замени плюс на минус», а нейронка, которая понимает контекст. Которая знает, какие баги реально встречаются в таком коде. Которая мутирует не синтаксис, а логику: меняет порядок проверок, путает граничные условия, забывает обработать edge case — ровно так, как ошибается человек. Или другая нейронка.

Сейчас есть явный сдвиг в сторону таких инструментов, но всё еще ничего достойного не вышло. Но уже скоро точно появится. И это будет совсем другой уровень. Не «выжили ли тесты после рандомной поломки», а «выжили ли тесты после правдоподобной ошибки».

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

Ждём, когда мутанты станут умнее.