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

Учимся писать промпты правильно

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

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

Но в любом случае, даже это не приучило меня как-то сидеть и расписывать, потому что ты никогда точно не знаешь, куда поведет агента на чем он запнется. Тебе мерещится одно, а он начинает тупить ваще в неожиданном месте.

А потом появился режим планирования. И в этот момент, все эти обучалки и принципы того как надо заранее хорошо подумать над задачей превратились в тыкву. Даже если вы начинаете мычать что-то в терминале, современные агенты сами направят, сами зададут вопросы и подсветят важные моменты. Главное в целом понимать что вам нужно и каким будет финальный результат. В этот момент мне перестало быть стыдно.

Вдруг меня осенило, слишком сильное обдумывание до начала работы в агентской разработке (последние полгода), стало чем-то сродни преждевременной оптимизации. Поработав с большим числом моделей и агентов, могу сказать, что если вы будете сами все продумывать, то заставите работать более менее нормально даже самые тупые модели, но вы никогда не поймете границы их возможностей, где они могут еще больше взять на себя освободив вас от рутины. А модели и агенты постоянно развиваются, там где раньше надо было подсказывать, теперь они могут сами. Плюс если вы работаете над AGENTS.md, скилами и mcp, то и тут мы ловим буст.

Поэтому сейчас я иду по такому пути. Включаю режим планирования и дальше даю короткое описание задачи и подробный контекст.

Для упавшего ci это выглядит так:

1. Поправь тесты

2. Прошу посмотреть последний запущенный билд на github actions

Баг в браузере:

1. прошу открыть страницу (он это делает через mcp chrome) и самому изучить

Для рефакторинга:

1. Переводим вот это на это

2. Вот эталон (тут ссылка на файл)

Для фичи:

1. Нужно реализовать такую фичу

2. Даю пример или говорю с помощью какого инструмента

И все. Самые продвинутые модели типа opus 4.6 или codex 5.3 справятся самостоятельно с большинством острых углов. Сами спросят объем, посмотрят разные варианты, изучат доку и так далее. Модели по тупее, не сделают глубокого анализа и ничего особо не спросят, но именно тут вы поймете где их надо вести и включать свой мозг чаще. Хотя хорошие модели настолько сильно помогают, что я физически не могу использовать более простые для задач планирования. Они хороши в авторежиме только для работы по аналогии, рефакторинг, написание тестов и так далее.

Даже если вы что-то забудете или пропустите сразу, все это можно будет доуточнить, попросить показать примеры кода, сходить открыть браузер. Если в процессе появляются вещи, которые агент делает из раза в раз, например, пытается выяснить где что-то лежит, как работать с какой-то частью системы, то постепенно это выносится в AGENTS.md и с определенного размера и уровни сложности (когда уже нужны скрипты например и команды) выносится в skill.

Разработка: Оркестровка агентов по ролевым кластерам (MSF)

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

Microsoft Solutions Framework (MSF) когда‑то предложил модель ролевых кластеров для проектных команд. Идея проста: каждая роль отвечает за свою часть жизненного цикла, а вместе они образуют сбалансированную спираль. Если перенести это на мир ИИ‑агентов, мы получаем оркестровку по ролевым кластерам.

🧩 Смешанная модель

• Люди: держат контекст, принимают стратегические решения, задают намерения и проверяют ценность.

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

• Оркестровка по MSF: роли распределяются так, чтобы каждый виток спирали был сбалансирован — часть работы делает человек, часть агент.

🎭 Пример

• Архитектор‑человек задаёт CASE‑скелет.

• Vibe‑агент генерирует код по его намерению.

• Тестировщик‑агент прогоняет сценарии.

• Координатор‑человек принимает решение: «идём дальше» или «возвращаемся».

• Бизнес‑агент симулирует нагрузку, а живой менеджер проверяет, совпадает ли это с реальными целями.

  🔧 Пример: смешанная команда разработки по MSF

  Ситуация: корпорация запускает новый сервис аналитики.

  Роли и участники

  • Архитектор‑человек: задаёт CASE‑скелет, фиксирует блоки и связи.

  • Vibe‑агент: генерирует код по намерению архитектора.

  • Тестировщик‑агент: прогоняет юнит‑тесты и нагрузочные сценарии.

  • Координатор‑человек: принимает решение о переходе к следующему витку спирали.

  • Бизнес‑агент: симулирует сценарии использования, проверяет ценность изменений.

  🎭 Как это работает

  1. Архитектор формулирует задачу: «Нужен модуль аналитики с API для отчётов».

  2. Vibe‑агент генерирует код, интегрируя новый модуль в систему.

  3. Тестировщик‑агент прогоняет тесты, выявляет узкие места.

  4. Координатор‑человек решает: «фиксируем итерацию» или «возвращаемся».

  5. Бизнес‑агент симулирует нагрузку: «При 10k запросов в минуту система держится».

  6. Команда делает следующий виток спирали — добавляет новые функции.

Заключение

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

CASE + Vibe + MSF + ИИ: Думаю, Будущая архитектура разработки

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

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

Но если соединить CASE + Vibe, через ИИ и дополнить принципами MSF (Microsoft Solutions Framework), мы получаем новую парадигму — инженерию намерения.

CASE: скелет

CASE-модели позволяют фиксировать архитектуру системы: связи, блоки, уровни. Проблема в том, что переход от схемы к живому коду всегда был мучительным. Программисты ненавидели CASE за «рисование картинок», которые потом приходилось вручную превращать в тысячи строк.

Vibe Coding: энергия

Вайб-кодинг — это поток идей. Разработчик формулирует намерение, ИИ тут же выдаёт код. Это быстро и драйвово, но хаотично. Без структуры такие системы рассыпаются при первой нагрузке.

MSF: спираль

Microsoft Solutions Framework изначально создавался как гибкая методология управления проектами. Его спиральная модель идеально ложится на задачу балансировки изменений: каждый виток фиксирует достигнутое, проверяет целостность и готовит систему к следующему шагу.

ИИ: мост

ИИ становится универсальным переводчиком. Он умеет:

• превращать вайб в CASE-модель;

• разворачивать CASE в рабочий код;

• делать обратный ход — извлекать архитектуру из существующего кода;

• проверять целостность пирамиды при каждом изменении.

Что это даёт

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

2. Двухсторонняя верификация: можно не только генерировать код из схемы, но и извлекать схему из кода.

3. Спиральная разработка: каждый виток добавляет плотность — вайб даёт энергию, CASE фиксирует, ИИ проверяет.

4. Блочная архитектура: вместо переплавки всего кода можно пересобирать подсистемы как Лего, сохраняя пирамиду целостности.

5. Прогон стратегий: структура позволяет моделировать изменения и балансировать нагрузки до внедрения.

Эффект для индустрии

• Для программистов: исчезает «тайное знание», код становится прозрачным и управляемым.

• Для корпораций: хаос уходит, появляется возможность прогнозировать реструктуризации и управлять динамикой изменений.

• Для поля: это новый уровень плотности — разработка превращается в управление реальностью через блочные пирамиды.

Заключение

CASE + Vibe + MSF + ИИ — это не просто очередная методология. Это живая архитектура, где код перестаёт быть бетоном и становится кристаллом: он держит форму, но готов перетекать в новую, когда меняется намерение.

Эта структура позволяет не только писать программы, но и прокатывать стратегии, балансировать нагрузки и управлять корпоративной эволюцией.

И именно к этому программистам и корпорациям придётся готовиться. Потому что хаос больше не будет оправданием. CASE + Vibe + MSF + ИИ превращают хаос в прозрачную пирамиду, где каждая ошибка становится видимой, а каждое верное решение — мгновенно масштабируется.

Эра «писать код руками» заканчивается. Наступает эра «инженерии намерения». И вопрос теперь не в том, «заменит ли ИИ программистов», а в том, кто сумеет стать архитектором этой новой реальности — а кто останется в прошлом.

GitHub визуализировали в цифровой город в проекте gitcity. В рамках проекта представлен сайт, на котором можно летать по «городу», где каждое здание это аккаунт разработчиков. Высота небоскребов = количеству коммитов. Летая по городу, можно искать интересные и популярные аккаунты, либо находить что-то новое и недооцененное.

Низкая экспертность на Хабре — или "алгоритм" размытия экспертности

Забудьте про токсичность и войны фреймворков. Давайте поговорим о чистой "математике" и о том, почему на Хабре невозможна экспертность.

Теорема об Интеграле и Яблоках

Представьте: Десятиклассник (не берем Эксперта - Профессора по математике) пишет статью. Там суровая база, математические доказательства и элегантный вывод через тройной интеграл. Он потратил десять лет, чтобы это понять, и еще два дня, чтобы это описать. Красота? Безупречность!

В это время мимо проходит Первоклассник. В его мире всё просто: есть яблоки, их можно сложить или вычесть. Он открывает статью и видит «кракозябры».

Три стадии «экспертной» защиты Первоклассника

Что делает Первоклассник, столкнувшись со сложностью, которую не может объять его мозг?

1. Стадия «Агрессивное непонимание»:

   • Мысль: «Что это за херня? Я этого не знаю, значит, это не нужно».

   • Действие: Комментарий: «Автор, а попроще нельзя? Зачем тут эти формулы, если в реальном проде мы просто копипастим со Stack Overflow?»

2. Стадия «Уязвленное эго»:

   • Мысль: «Он что, считает себя умнее меня?!»

   • Действие: Тихий, трусливый минус посту. Без аргументов. Просто потому, что статья заставила его почувствовать себя маленьким.

3. Стадия «Гордое молчание»:

   • Мысль: «Я сделаю вид, что этого не существует».

   • Действие: Пройти мимо, оставив Эксперта наедине с его пустотой.

Конфликт с системой «лайков»

И вот тут случается магия. Поскольку первоклассников в системе всегда больше, чем тех, кто понимает интегралы, «коллективный разум» Хабра выносит вердикт:

• Сложная, глубокая, ценная статья тонет в минусах или игноре.

• Пост «Как я переложил джейсон и не вспотел» залетает в топ.

Вывод: Система лайков — это не мерило ценности знаний, это "термометр средней температуры по больнице" (А она, как "известно", 36,6 градусов, вместе с моргом).

Эпилог: Так что мы имеем в сухом остатке? Эксперт пришел "поделиться, передать знания", а в итоге его просто никто не замечает (низкий охват) или еще лучше - получил по лицу "учебником арифметики". Карма в минус - "запрет публиковать материал".

P.S. И хотя, иногда находишь интересный глубокий материал... это скорее исключение, чем правило для Хабра.

Весенние вакансии в SSP SOFT: Ждем резюме

Про нас как работодателя: компания SSP SOFT работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошедший 2025 год мы наняли 179 новых сотрудников. По размеру компании — мы «средний бизнес» с проектами федерального уровня.

Рабочие места у нас в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в департамент разработчики в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, поддерживающая атмосфера, где работать — продуктивно, без выноса мозга и микроменеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Горячие вакансии марта (переадресация, дождитесь загрузки вакансии):
1️⃣ Разработчик DWH
2️⃣ Data Аналитик
3️⃣ Технический писатель
4️⃣ Разработчик 1С
(на остальные вакансии см. ссылку ниже, перейдя на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Фундаментальная база для AI Advanced

Или каких "Косяков" стоит избегать, чтобы результаты LLM стали лучше

🛸 Косяк №1 — по незнанию или скупости использовать не Frontier модели
Значимый рост в глубине и качестве рассуждений наступил после Opus 4.5, а лучше 4.6 + Codex 5.3 xhigh

А вот например как выглядит API GitHub Copilot на 2026 год
"id": "gpt-4.1",
"is_chat_default": true,
"is_chat_fallback": true,

Это значит, что GPT 4.1 — стандартная модель в GitHub Copilot, которой уже почти год. И она не создавалась для агентной работы

Следовательно, некорректно все вокруг называть "Я пробовал ваш ИИ и он выдает фигню". Между Opus 4.6 и GPT 4.1 огромная разница

Туда же пойдет косяк 2

---

🛸 Косяк №2 — юзать сервисы по типу CURSOR / Replit / Lovable / Copilot

Всё это AI врапперы разной сложности, но суть одна — это врапперы, которые в большинстве своем используют модели Claude / GPT через API

Бизнес модель подобных сервисов заключается в том, чтобы с вас взять больше, а за API Usage заплатить меньше. Следовательно, AUTO выбор модели в таких сервисах почти всегда идет не от того, какая модель лучше в моменте, а какая модель на текущий момент времени будет дешевле для сервиса враппера

Ну и в дополнение — API в среднем дороже подписки в ~10 раз

Следовательно, условный CODEX / CLAUDE CODE даст вам в ~10 раз больше запросов, чем тот же самый CURSOR

При активном использовании нативный тул (Claude Code, Codex) выгоднее врапперов — нет прослойки, которая зарабатывает на марже между вашей подпиской и реальной стоимостью API

---

🛸 Косяк №3 — плохой Context Engineering

У меня есть любимая цитата

Good context engineering means finding the smallest possible set of high-signal tokens that maximize the likelihood of some desired outcome

Каждое словосочетание здесь — это большой и сложный домен. И чем лучше вы понимаете эту цитату, тем лучше будет ваш результат

При работе с моделью важен Spec Driven Approach — чем лучший контекст ты задаёшь для модели, тем лучше результат

---

🛸 Косяк №4 — не использовать Claude Code CLI для работы с Claude моделями

Помимо самого качества моделей еще немаловажным фактором является model-tool co-optimization.

Claude модели лучше работают с Claude Tools
Gemini модели лучше работают с Gemini Tools
Codex модели лучше работают с Codex Tools

Разработчики отмечают, что одна и та же модель Claude работает драматически лучше в Claude Code, чем в Cursor. Programmatic Tool Calling позволяет оркестрировать несколько вызовов в одном round-trip — ~37% сокращение токенов на сложных задачах

Ну и вообще, это база всех продуктов — свое работает лучше со своим

---

🛸 Косяк №5 — бездумно заполнять 1 000 000 Context Window

Часто слышу "А вот у гугл моделей 1 000 000 контекстное окно, я туда вгружаю все подряд кааайф"

Текущие модели — трансформеры — стали прорывными за счет механизма Attention, где каждый токен следит за каждым токеном

Что значит квадратичный рост compute — aka стоимость вычисления каждого следующего "слова"

Attention у трансформеров масштабируется квадратично. Стандартный контекст сегодня — 100K-200К токенов. От 100K до 1M — это 10x по длине. 10² = 100x по compute. Если бы 1M контекст реально работал на всю длину, каждый запрос стоил бы в 100 раз дороже. Но он не стоит — потому что создатели моделей используют всякие улучшалки по типу sparse attention, sliding window, KV-cache compression

По простому — компрессия ваших входных данных будет тем выше, чем больше "важного мусора" вы попытаетесь сунуть в контекстное окно

А если еще проще — чем больше вы засовываете в одну сессию, тем хуже будет ответ

Я вообще стараюсь начинать новую сессию уже после заполнения Context Window на 60к токенов

Итого

Использовать Frontier модель + нативный тул под нее + правильно оркестрировать контекст = намного качественнее результат

Уже нет смысла гоняться за лучшими моделями — важнее развивать метанавыки работы с ИИ и агентами

31 сервис для бесплатного обучения: бэкенд, фронтэнд, нейронки, докер, Java, Web-3 и многое другое:

• HTML.com — полный справочник тегов и атрибутов для новичков, делающих первые шаги в разметке веб-страниц;

• Web.dev — обучающий курс от Google с практикой: современная вёрстка, гриды, флексы и всё, что нужно для красивых макетов;

• Javascript.info — настольная книга по JS: от базового синтаксиса до сложных тем типа прототипного наследования и async/await;

• Reactplay.io — площадка, где React учат не по учебникам, а через живые проекты и челленджи;

• Learnvue.co — компактные и понятные туториалы по Vue.js без воды;

• Angular.dev — официальное руководство от создателей Angular: шаг за шагом от нуля до рабочего приложения;

• Git-scm.com — полноценный учебник по Git и контролю версий;

• Learnweb3.io — школа Web3-разработки: блокчейн, децентрализация и всё вокруг этого;

• Learnpython.org — онлайн-тренажёр Python: пишешь и запускаешь код прямо в браузере, ничего не устанавливая;

• W3schools.com — культовый справочник с встроенной песочницей, где можно тут же тестировать SQL-запросы и не только;

• Cryptozombies.io — геймифицированный курс по смарт-контрактам;

• Nextjs.org — обучалка по главному React-фреймворку, который делает веб-приложения реактивно быстрыми;

• Elementsofai.com — курс по основам ИИ от Хельсинкского университета, написанный так, что поймёт даже филолог;

• Phptherightway.com — руководство по написанию чистого PHP-кода в соответствии с актуальными стандартами;

• Rapidapi.com — практические уроки по подключению и использованию сторонних API в своих проектах;

• Learn-golang.org — экспресс-курс по Go для тех, кто метит в высоконагруженные сервисы;

• Rust-lang.org — официальный портал языка Rust: максимальная скорость и безопасность на системном уровне;

• Refactoring.guru — топовый ресурс о паттернах проектирования и искусстве рефакторинга спагетти-кода в чистую архитектуру;

• Typescriptlang.org — руководство по TypeScript — типизированной надстройке над JS, без которой не обходится ни один серьёзный проект;

• Cplusplus.com — фундаментальный справочник по C++: переменные, указатели, работа с памятью и всё между ними;

• Docs.oracle.com — официальные обучающие треки по Java от тех, кто этот язык придумал;

• Dotnet.microsoft.com — портал по экосистеме .NET: разработка на C# под любую платформу — от десктопа до облака;

• Swift.org — точка входа для тех, кто хочет создавать приложения под iOS и экосистему Apple;

• Djangoproject.com — введение в Django — самый мощный Python-фреймворк для веб-приложений;

• Flask.palletsprojects.com — гайд по Flask: минималистичный Python-фреймворк, идеальный для микросервисов;

• Docker.com — основы контейнеризации: как упаковать приложение так, чтобы оно запускалось на любой машине без сюрпризов;

• Kubernetes.io — руководство по оркестрации контейнеров и управлению кластерами в продакшене;

• Linuxjourney.com — пошаговый маршрут от полного нуля до уверенного администрирования Linux;

• Tryhackme.com — обучение кибербезу и этичному взлому в игровом формате с реальными симуляциями;

• Roadmap.sh — структурированная дорожная карта: что учить и в каком порядке, чтобы стать DevOps-инженером;

• Cloudskillsboost.google — практические лабораторные и курсы по Google Cloud с бейджами за прогресс.

Смертельный марш: почему ваш проект обречен и как в этом выжить

Если вы работаете в разработке, то рано или поздно вы оказываетесь в ситуации, когда дедлайн был вчера, бюджет сократили до стоимости обеда, а команда напоминает выживших после кораблекрушения. Эдвард Йордан в своей классической книге назвал это «Смертельный марш. Выживание в безнадежных проектах» (Death March).

Самое важное, что нужно понять: это не досадный сбой менеджмента. Это — стандартная, осознанная и часто эффективная (с точки зрения бизнеса) модель работы.

Генезис катастрофы: Политика, политика и еще раз политика

Йордан честен: большинство безнадежных проектов рождаются не из-за технических сложностей. Они рождаются из-за того, что кто-то наверху играет в свои игры. Маркетологи наобещали невозможное, чтобы закрыть сделку; менеджеры побоялись сказать «нет» вице-президенту; а высшее руководство живет в мире, где девять женщин могут родить ребенка за один месяц.

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

Классификация неизбежного: В каком аду вы находитесь?

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

1. «Невыполнимая миссия» (Mission Impossible): Шансы на успех — 1 к 10, но команда верит, что они избранные. Это чистый адреналин. Если получится — вы станете легендами компании. Если нет — вы хотя бы попробовали прыгнуть выше головы.

2. «Камикадзе» (Kamikaze): Здесь нет веры в успех. Есть только осознание финала. Но проект дает доступ к технологиям, которые сделают ваше резюме золотым. Вы идете на дно вместе с кораблем, но с полными карманами ценного опыта и крутым стеком в портфолио.

3. «Отвратительные» (Ugly): Самый грязный вариант. Вы — просто «сжигаемый ресурс». Менеджеру нужно дотянуть до конца квартала, получить бонус и уволиться, оставив после себя выжженную землю и дергающихся от каждого уведомления сотрудников. Здесь нет места героизму, только эксплуатация.

4. «Самоубийственные» (Suicidal): Проект мертв, смысла нет, прогресса нет. Все сидят и ждут, когда здание наконец рухнет, просто потому что страшно или лень увольняться. Это чистая стагнация.

Принцип «Сортировки» (Triage)

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

Вы понимаете, что 80% функционала, о котором мечтает заказчик, никогда не будет реализовано. Профессионализм здесь заключается в том, чтобы сосредоточиться на тех 20%, которые позволят системе выдать хоть какой-то результат в день релиза. Всё остальное — белый шум и декорации. Вы просто игнорируете второстепенные задачи, не тратя на них ни капли энергии, даже если менеджер бьется в истерике.

Эстетика процесса

Безнадежный проект — это странное место. Когда результат предопределен (провалом), у вас исчезает страх перед этим самым провалом. Вы становитесь свободны. Вы можете писать код так, как считаете нужным, не оглядываясь на KPI и бесконечные совещания о «светлом будущем».

Смертельный марш — это не про успех продукта. Это про вашу личную устойчивость в условиях тотального хаоса. Пока вы сохраняете дистанцию и понимаете, что это просто роль в плохой пьесе, вы остаетесь профессионалом.

P.S. Циатата:

Когда я впервые услышал эти истории [о неразумном корпоративном поведении], я пришел в недоумение, однако после тщательного анализа я разработал сложную теорию, объясняющую такое странное поведение. Она заключается в следующем: люди - это идиоты.

Включая меня. Идиоты все, не только люди с низкими интеллектуальными показателями. Единственная разница между нами заключается в том, что мы идиоты по отношению к различным вещам в различное время. Неважно, насколько вы остроумны и находчивы, все равно большую часть дня вы проводите как идиот.

Русский язык программирования.


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


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


Если вы начинающий автор или уже имеете хороший ЯП, пишите в комментарии и оставляйте ваш GitHub\GitFlip и название вашего языка.

Каждый ЯП посмотрю, проверю, изучу.

Задача о сравнении чисел

Привет, Хабр! Как насчет небольшой задачи, чтобы вкатиться в рабочую неделю?

Условие

В IT-компанию N привезли экспериментальное устройство для автоматизации расчетов. Оно работает на урезанном интерпретаторе Python: никаких условий, сравнений или встроенных функций — только арифметика и битовые операции.

Знаки сравнения (>, < == и другие) использовать не получится, интерпретатор их не поймет и выдаст ошибку. Однако без них писать код довольно сложно. Придется реализовать базовую логику выбора большего из двух чисел.

Задача

Есть два числа: a и b. Найдите наибольшее из них, используя только сложение, вычитание, деление и умножение, а также битовые операции.

Нельзя использовать операторы сравнения (>, <, ==, != и т. д.), тернарный оператор, функции вроде max(), min() и прочее.

Попробуйте справиться с заданием. А один из вариантов решения показываем в Академии Selectel.

ИИ в разработке: экзоскелет, а не замена человека

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

Но выбор инструмента — отдельная задача. GitHub Copilot, Claude, ChatGPT, DeepSeek, Tabnine — у каждого своя ниша, и кажется, что универсальной нейросети не существует.

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

Читайте полный обзор на сайте Рег.облака.

Приглашаем на доклад Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation

Привет! Если на выходных судьба занесёт вас в Новосибирский Академгородок, приходите на технический доклад с мемами от нашего коллеги Даниила Степанова на самой ламповой Java-конференции Сибири — SnowOne 2026 ❄️.

📌 28 февраля, 14:00–15:00 (время Новосибирска)
👨‍💻 Даниил Степанов — разработчик-исследователь в Veai, к.т.н., преподаватель ИТМО

Deep Dive into JVM JDI: Capturing Live Execution for Automatic JUnit Test Generation

Глубокий технический разбор архитектуры инструмента, который использует Java Debug Interface (JDI) для захвата состояния работающей JVM и автоматического синтеза валидных unit-тестов.

Что будет в докладе:

• Deep Dive в JDI. Подробный рассказ про JDI, преимущества и недостатки, а также как его использовать в нестандартных сценариях для безопасного захвата Heap и Stack Frame в реальном времени.

• Реконструкция объектов. Reverse Engineering JVM-состояния для воссоздания сложных графов объектов.

• Синтез Java-кода. Как превратить сырой дамп памяти в чистый, валидный JUnit-тест.

• Роль LLM. Для решения каких проблем мы используем искусственный интеллект?

Доклад будет полезен Java-разработчикам, тем, кто интересуется внутренним устройством JVM, и всем, кто хочет автоматизировать написание тестов.

Технологии: Java, JVM, JDI (Java Debug Interface), Mockito, JUnit, LLM.

Отличной пятницы и увидимся на SnowOne 🖖

Встречаем март с новыми вакансиями в SSP SOFT

SSP SOFT — компания работает в сфере заказной разработкой ПО и предоставления выделенных команд на ИТ-аутсорсинг для крупных клиентов. У нас всегда есть открытые вакансии — за прошлый год мы наняли 179 сотрудников.

Рабочие места предоставляются в московском офисе, который открылся в 2025 году у самой Красной площади. А еще есть вакансии в офис разработчиков в Томске и на удаленку из любой точки России.

Работа в SSP SOFT — это реальные проекты, дружная атмосфера, где работать — продуктивно, без выноса мозга и микро-менеджмента. В марте 2026 ищем опытных спецов, кто готов в новое профессиональное будущее вместе с нами.

Самые горячие вакансии прямо сейчас:
1️⃣ Разработчика DWH
2️⃣ Data Аналитика
3️⃣ Технического писателя
4️⃣ Fullstack QA Engineer (Java/Kotlin)
(см. ссылку на остальные вакансии ниже на ХХ-ру)

Что предоставляет экосистема SSP SOFT:
✅ Мы пишем код, который формирует завтрашний день. Никакой скучной рутины.
✅ Центр компетенций и личное менторство ускорят развитие до максимума.
✅ Офис, гибрид или фулл-удаленка? Есть все варианты.
✅ Время — ваш ресурс. Мы его уважаем.

Подробности о вакансиях читайте на нашей странице ХХ.ру, но там откликаться необязательно. Ждем резюме напрямую в ЛС нашей HR Lead Алине (https://t.me/AONikitina).
Не забудьте добавить «секретную фразу» в сопроводительное письмо, «Увидел(а) вашу вакансию на Хабре».

Желаем всем хабровцам успешной карьеры в 2026 году 🚀

Не пойму — чего за кипишь? Или почему ИИ — это просто новый «питон»

Последнее время из каждого утюга кричат: «ИИ заменит программистов!», «Джуны больше не нужны!», «Учитесь на сантехников, пока не поздно!».

Давайте выдохнем, отставим смузи и разберемся по-простому, «на пальцах», что вообще происходит.

1. Программист — это не «печатающая машинка»

Главная ошибка паникеров в том, что они путают набор текста с программированием. Если ваша работа заключалась в том, чтобы копипастить методы из Stack Overflow и менять там названия переменных — да, у меня для вас плохие новости. ChatGPT делает это быстрее и без обеденного перерыва.

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

2. Эволюция «костылей»

Вспомните историю. Раньше писали на перфокартах. Потом на Ассемблере. Потом на Си, потом на Питоне. Каждый раз кричали: «Ну всё, теперь порог входа стал таким низким, что программисты не нужны!». И что? Программистов стало только больше. Просто мы перестали думать о том, в какой регистр положить байт, и начали думать о том, как построить архитектуру сервиса.

ИИ — это просто следующий уровень абстракции. Это новый «язык программирования», где вместо скобочек мы используем новый язык -конструкты чистого смысла

3. Проблема «идеального мусора»

ИИ — это зеркало вашего мышления. Если вы дадите нейронке кривое, логически дырявое задание — она выдаст вам идеально написанный, быстрый, оптимизированный... мусор. Чтобы управлять ИИ, вам нужно иметь в голове структуру еще более четкую, чем раньше. Теперь цена ошибки в логике выросла. Если раньше вы ошибались в синтаксисе — программа не заводилась. Теперь она заведется, но уедет не туда.

4. ИТ-поликлиника

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

А кого вообще не заденет? (Спойлер: Работы будет завались)

Если вы думаете, что ИИ — это такой терминатор, который выкосит всё ИТ-отделение, то вы плохо представляете, как устроена реальная «цифровая больница». Есть куча специализаций, где человеческий фактор — это не баг, а фича.

• Архитекторы сложных систем (System Architects): ИИ может нарисовать типовой домик. Но построить небоскрёб на болоте, учитывая старое «дырявое» железо, бюджет заказчика и планы на 10 лет вперёд... ИИ не видит контекста «выживания» системы, он видит только код.

• Инженеры кибербезопасности (SecOps): Тут идёт вечная война хитрости. ИИ может искать паттерны, но он не может предугадать нестандартный «выверт» хакера-человека. Безопасность — это интуиция и паранойя, а у нейронок с этим туго. Гы)))

• SRE и DevOps (Те, кто спасают сервера в 3 часа ночи): Когда у системы «инфаркт», данные текут, а клиенты кричат — нужен человек с железными нервами, который примет решение «резать или шить». ИИ в критической ситуации может просто выдать ошибку 404, потому что такого случая не было в его обучающей выборке.

• Бизнес-аналитики и «Психотерапевты заказчика»: Это те, кто переводят с «бреда руководства» на человеческий. ИИ никогда не поймет, почему директор хочет «кнопку как у конкурентов, но чтобы она была синей, но красной».

• Процессные аналитики (BPM): Они рисуют, как ходят бумажки и данные между отделами. ИИ учтёт, что бухгалтер Марья Ивановна просто не отдаст отчёт вовремя, потому что обижена на айтишников?

  Итог

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

ИИ — это просто наш новый, очень мощный экзоскелет. Но куда в нем идти и зачем — решать всё равно вам.

Так что идите пить чай, делайте зарядку для мозгов и учитесь формулировать. Это единственный навык, который у вас никто не отберет.

Как далеко видит lookup в C++?

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

Совсем недавно мы проверяли проект OpenCV и нашли там довольно интересную ошибку. Рассмотрели её подробнее и написали новую статью специально для тех, кто хочет разобраться с механизмом поиска имён в C++, в частности с поиском имён по аргументам.

На Upwork появилась вакансия, которая отражает состояние индустрии ИИ-разработки: заказчик ищет вайбкодера, чтобы доделать приложение, которое не доделал предыдущий вайбкодер. Завершив уже больше половины работы, прежний исполнитель вдруг обнаружил, что у него больше «нет времени».

Вакансия гласит: «У нас есть незаконченный проект на GitHub, который был доведён при помощи вайбкодинга примерно до 75% готовности. У прошлого вайб-одера нет времени доделать его. Мы предоставим документацию и цели, чтобы вы могли использовать ИИ и свои навыки для завершения работы». Исполнителю предлагают создать персональный API-ключ, чтобы тот не тратил свой.

Вакансия понравилась пользователям Reddit. «Ищу несертифицированного хирурга, чтобы исправить неудачную операцию, выполненную предыдущим несертифицированным хирургом», — иронизирует один. «Ищу несертифицированного инженера-конструктора, чтобы починить дом, который рухнул из-за предыдущего вайб-инженера», — добавил другой. Кто-то отметил, что «75% готовности — это минус 20% готовности. Разгрести то месиво, которое уже накодили, займёт больше времени, чем написать всё с нуля». Кто-то напомнил принцип Парето, мол, оставшиеся 20% — на самом деле 80% работы.

Практический Тренажер по Java — самый популярный тренажер по Java на Stepik

В 2024 году я опубликовал курс «Практический Тренажер по Java» на платформе Stepik. Тогда это был просто практический курс с задачами — без воды, без длинной теории, только код и постоянная тренировка.

Прошло несколько лет.

Сегодня курс проходит более 19 000 учеников, и это самый популярный тренажёр по языку Java на платформе Stepik.

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

И я хочу заново пригласить вас в этот проект.

Почему Java?

Java — один из самых востребованных языков программирования в мире.

Он используется в:

— веб-разработке

— мобильной разработке (Android)

— корпоративных системах

— финансовых сервисах

— высоконагруженных backend-проектах

Java — это стабильность, масштабируемость и высокий спрос на рынке труда.

Что представляет собой курс сегодня?

Это полностью практический формат обучения. Только задачи и реальная практика.

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

Кому подойдёт курс?

— начинающим разработчикам

— тем, кто хочет перейти в backend

— Android-разработчикам

— QA Automation инженерам

— тем, кто готовится к собеседованиям

Я приглашаю вас присоединиться :)

➡️ Java Тренажер на Stepik

14 открытых уроков для бэкенд-разработчиков

Привет, Хабр. Делимся подборкой бесплатных уроков, которые скоро пройдут в Otus. Опытные практики проведут занятия онлайн — вы сможете узнать больше о формате обучения и задать вопросы экспертам. Выбирайте свою тему и присоединяйтесь.

• 24 февраля 20:00. «Работа с реляционными БД: от ADO.NET до EF Core». Записаться
  ^{Открытый вебинар курса «C# Developer. Professional»}

• 24 февраля 20:00. «Первые шаги в Java». Записаться
  ^{Открытый вебинар курса «QA Automation Engineer»}

• 24 февраля 20:00. «Создание микросервиса». Записаться
  ^{Открытый вебинар курса «Архитектура и шаблоны проектирования»}

• 25 февраля 20:00. «Знакомство с Rust. Первые шаги». Записаться
  ^{Открытый вебинар курса «Rust Developer. Basic»}

• 25 февраля 20:00. «Каналы Go без пробок и утечек». Записаться
  ^{Открытый вебинар курса «Golang Developer. Professional»}

• 25 февраля 20:00. «Разработка REST API на Laravel». Записаться
  ^{Открытый вебинар курса «Framework Laravel»}

• 26 февраля 20:00. «JDBC — ваш швейцарский нож для работы с данными». Записаться
  ^{Открытый вебинар курса «Java Developer. Professional»}

• 2 марта 20:00. «Изучаем Java с нуля на примере простой консольной игры». Записаться
  ^{Открытый вебинар курса «Java-разработчик»}

• 4 марта 20:00. «Саги vs распределённые транзакции: как моделировать рабочие потоки в распределённой архитектуре». Записаться
  ^{Открытый вебинар курса «Domain Driven Design и асинхронная архитектура»}

• 5 марта 20:00. «Знакомство с Kotlin: пишем первый код». Записаться
  ^{Открытый вебинар курса «Kotlin Developer. Basic»}

• 10 марта 20:00. «Реализация простого HTTP сервера на Java». Записаться
  ^{Открытый вебинар курса «Java-разработчик»} 

• 10 марта 20:00. «Дженерики в Go: от синтаксиса до смысла». Записаться
  ^{Открытый вебинар курса «Golang Developer. Professional»}

• 10 марта 20:00. «Мультитенантная архитектура в Laravel: как масштабировать проекты под десятки и сотни клиентов». Записаться
  ^{Открытый вебинар курса «Framework Laravel»}

• 11 марта 20:00. «Сообщения, которые не теряются: Брокеры против хаоса в Java». Записаться
  ^{Открытый вебинар курса «Java Developer. Professional»}

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

Приветствую, Хабравчане!

Задумывались ли вы, насколько высок современный налог на железо в разработке ПО?

У меня в руках настоящий «старичок» из 2002-го: сокет 478, матплата GA-8IR2003, Celeron 1700 МГц (по силам как Pentium III на 1 ГГц, но с поддержкой SSE2), 2 Гб ОЗУ, GeForce 4 MX и верный HDD на 40 Гб.

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

На борт успешно встают Windows 7 и Debian 11, что открывает доступ к актуальному софту, IDE и библиотекам. Хочется понять: реально ли на таком непотребстве поднять бэкенд на C# или собрать что-то серьезное на C++?

Запасной вариант, если основному ПК не хватит инструкций.

В запасе ПК: Athlon x4 640, 8гб ОЗУ, ssd 256.

На нем, отключая ядра и понижая частоту можно добиться симуляции ПК начиная с 2000-ого по 2010 год. Думаю этот вариант будет предпочтительнее. Но начну конечно с celeron'а.

Что планирую потестить:

1. C# под Linux: Запустить бэкенд и посмотреть, не «умрет» ли система.

2. Базы данных: Погонять PostgreSQL 9.4 (она еще дружит с 32-битными процессорами).

3. C++: Сравнить скорость сборки проекта с модулями и без них.

4. Безумный челлендж: Попробовать собрать userver. В чате разработчиков сказали "вряд ли взлетит", а мне тем более интересно проверить.

5. IDE: Какая версия Visual Studio оживет и можно ли в ней работать без боли.

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

Будет интересно сделать вывод: пригоден ли древний ПК хоть для какой-то разработки сегодня, или «налог на железо» стал неподъемным. Жду ваши предложения!

Update: Поправил текст, ошибки и очепятки.