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

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

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

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

Я собираюсь рассказать о том, как правильно тестировать код в изоляции (интеграционные тесты — зверь из соседнего вольера, и о нем — в другой раз). Для этого нам потребуется пара определений. Фаззинг (от английского fuzzing) — это способ тестирования, при котором программе скармливают огромные объемы случайных, полуслучайных или вообще намеренно испорченных данных, с надеждой выявить уязвимости или баги. Изначально этот метод применялся в академической среде для поиска дыр в безопасности, но быстро перекочевал в руки здравомыслящих разработчиков. Property-based testing, в свою очередь, представляет собой подход к тестированию, где вместо проверки конкретных примеров типа «дважды два — четыре» мы формулируем общие свойства системы. Например: «если функция принимает список и возвращает список, то длина результата не должна превышать длину входа». А дальше уже инструмент генерирует тысячи, миллионы вариантов входных данных и проверяет, соблюдается ли это условие.

С Новым Годом и добро пожаловать в Gas Town!

Gas Town - это новый взгляд на IDE для 2026 года. Gas Town помогает вам справиться с рутиной запуска множества экземпляров Claude Code. Вещи теряются, трудно отследить, кто чем занимается, и так далее. Gas Town помогает со всей этой рутиной и позволяет вам сосредоточиться на том, над чем работают ваши Claude Code.

В этом посте "Claude Code" означает "Claude Code и все его идентичные конкуренты", то есть Codex, Gemini CLI, Amp, Amazon Q-developer CLI, бла-бла-бла, потому что именно этим они и являются. Клоны. Индустрия - это постыдная детская футбольная команда, гоняющаяся за форм-фактором CLI Claude Code образца 2025 года, вместо того чтобы создавать то, что будет дальше.

Я пошел вперед и создал то, что будет дальше. Сначала я предсказал это еще в марте в статье Месть начинающего разработчика. Я предсказал, что кто-то свяжет верблюдов Claude Code вместе в колесницы, и это именно то, что я сделал с Gas Town. Я приручил их настолько, что вы можете продуктивно использовать 20–30 штук одновременно на постоянной основе.

Gas Town имеет свое мнение - во многом как Kubernetes или Temporal, на которые Gas Town похож, по крайней мере, если прищуриться так сильно, что глаза почти полностью закроются. Я включу сравнения как с k8s, так и с Temporal в конце этого поста. Немного удивительно, насколько они похожи, несмотря на радикально разные основы.

Но сравнение должно служить предупреждением: Gas Town сложен. Не потому, что я этого хотел, а потому, что мне приходилось добавлять компоненты до тех пор, пока он не стал самодостаточной машиной. И те части, которые у него теперь есть, ну, они выглядят так, как будто Kubernetes спарился с Temporal, и у них родился очень уродливый ребенок.

Но это работает! Gas Town решает проблему MAKER (Ханойская башня из 20 дисков) вообще элементарно. Просто генерируешь по формуле "цепочку" на миллион шагов - и готово. Вчера ради интереса прогнал 10 дисков за несколько минут: доказал, что тысяча шагов для нас - это не проблема, хотя в статье MAKER говорится, что нейронки ломаются уже через несколько сотен. На 20 дисков закладываю часов 30. На этом мой импровизированный TED Talk окончен.

Все это обретет полный смысл, если вы дочитаете до конца следующих 23 страниц.

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

Beads занимает совершенно уникальную нишу. Все сосредоточены на создании инструментов планирования, в то время как Beads - это инструмент исполнения. Это всё равно что поставить вашего ИИ-агента на отлично смазанные лыжи. Возможно, лучшим названием было бы Agents on Rails («Агенты на рельсах»). Но название «Beads» (Бусины) хорошо передает идею того, что инструмент сфокусирован исключительно на отслеживании (трекинге) и ни на чем другом: маленькое имя для маленькой системы.

Сейчас, спустя почти 6 недель своего пути, Beads стал намного, намного стабильнее. Это была безумная гонка, порой менялось по 50 тысяч строк кода в день. И никто из нас, контрибьюторов, даже не просматривает этот код. Он на 100% написан ИИ («vibe coded»), сейчас в нем 130 тысяч строк на Go, и примерно половина - это тесты. Десятки тысяч людей используют его в своих повседневных рабочих процессах. Люди говорят мне, что им это так нравится, что они используют его даже для личных списков дел (TODO). А другие направо и налево встраивают его в более крупные оркестраторы. Это также потрясающий строительный блок.

Мы сохранили небольшой объем функционала. Прислушиваясь к мнению сообщества, я отвергаю всё, что не должно быть частью ядра Beads. Поэтому у Beads нет пользовательского интерфейса (UI), но есть множество примеров UI, которые люди создали как проекты «для души» (passion projects). У нас их уже как минимум четыре или пять. Мой приятель и соавтор Джин Ким даже создал свой собственный UI для Beads на Java Swing! Он был так взволнован, когда показывал мне его. И это действительно было очень круто.

Итак, никакого UI, и у Beads также нет системы планирования. Он не для этого. Но он отлично интегрируется с любой системой планирования - просто составьте план, а затем попросите агента создать в Beads эпики и задачи (issues) для этой работы. После того как эпики будут готовы, вы можете натравить на них любое количество агентов, чтобы они их «разгребли».

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

Я занимался вайб-кодингом (vibe coding) как одержимый сорок дней и сорок ночей. Это долгая история, поэтому я резюмирую её в этих трех картинках.

Слева, 3 недели назад: я вайб-кожу на пляже за ужином в Кабо-Сан-Лукас, Мексика, с неподражаемым Торстеном Боллом, нашим приятелем Мэттом Манелой и другими коллегами из Sourcegraph на корпоративном выезде. Кто-то сделал это фото, потому что я отказывался убрать компьютер.

В центре, 2 недели назад: фотография, на которой я фотографирую сам себя, пока еду на скорости 100 км/ч (60 миль/ч) по шоссе в Беллингем, чтобы забрать гитары, занимаясь голосовым вайб-кодингом всю дорогу туда и обратно. Глупо и чертовски опасно. Мне было плевать. Застрял в пробке на несколько часов. Всё равно плевать. Я упоминал, что это вызывает привыкание? Вайб-кодинг вызывает привыкание.

На последнем кадре: мы с женой в торговом центре на прошлой неделе, наслаждаемся приятным днем с кофе, наблюдаем за людьми и вайб-кодим вместе с Моцартом (на фото он в своей любимой сумке). Лин прячется за компьютером - так я получил разрешение руководства на публикацию снимка.

Я никуда не хожу и не делаю ничего, даже не сплю, без своего ноутбука. Ну, разве что когда бегаю - там я ещё не совсем раскусил, как вайб-кодить. Но я близок. Это тема для отдельного поста, но у меня наконец-то работают агенты на GCP с Terraform и Tailscale. Так что скоро я смогу вайб-кодить и с телефона.

Агенты никогда не должны отдыхать.

Автор: Денис Аветисян

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

Большинство гайдов по C# в Интернете или давно утратили актуальность, или содержат лишь небольшие вкрапления новых возможностей, но лишены последовательности. Есть и другая крайность - ИИ простыни сгенерированного текста под видом статей, которые очень тяжело читать. Я хочу сделать свою попытку изменить ситуацию.

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

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

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

Представьте себе такую картину: пятничным вечером вы нажимаете кнопку воспроизведения видео на Netflix. Не проходит и нескольких секунд, как в ответ на это в недрах системы оживают сотни контейнеров. Обеспечение эффективной работы большого количества контейнеров в Netflix — это один из краеугольных камней обеспечения качественного потокового видео для миллионов пользователей со всего мира. Для того чтобы обеспечить высокую скорость реакции системы таких масштабов, мы модернизировали нашу среду выполнения контейнеров (контейнерный рантайм, container runtime), но, сделав это, мы столкнулись с неприятной неожиданностью, сдерживающей рост нашей системы. Это — архитектура процессоров.

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

Сегодня мы поговорим про такую, казалось бы, простую и привычную штуку, как функция drop в языке Rust. Что может быть банальнее?

Создали переменную, и в конце области видимости она сама очистится. RAII за нас делает всю работу, а мы просто выдыхаем и не боимся утечек памяти. Но не все так радужно!

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

Как работает чистый код?

Ниже моё облыжное мнение о том, почему «Чистый код» — чистой воды инфоцыганщина, и почему если вы слышите в аргументации собеседника эти слова — нужно бежать, ведь разговаривать с зомби бессмысленно.

Разработка с ИИ-ассистентами часто напоминает поездку с талантливым, но забывчивым штурманом. Он отлично знает карту (код), но постоянно забывает пункт назначения (бизнес-задачу) и пройденный маршрут (контекст).

Мы привыкли работать в режиме "Prompt & Pray": написали длинный промпт, получили код, внесли правки. Но на дистанции сложной фичи контекст размывается. Агент начинает галлюцинировать, терять детали или переписывать одно и то же. Проблема не в модели, а в отсутствии долгосрочной памяти и четкого контракта.

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

OpenSpec - чтобы зафиксировать "что и зачем мы делаем" (Spec-Driven Development).

Beads - чтобы управлять тем, "как и в каком порядке" это выполнять (граф задач).

Cursor - как среду, которая связывает их воедино.

Если вы устали от того, что ИИ теряет нить повествования на середине рефакторинга, этот подход для вас.

Я как-то писала про Claude Code. По ощущениям, многие вайбкодеры сейчас выбирают его как основную CLI-среду для агентского кодинга. Между Codex, Gemini и Claude Code часто выбирают последний- за быстрые итерации и удобство. Собрала в одном месте полезные ресурсы про Claude Code. 

Всем привет! 👋👋👋👋👋 Мы Java-разработчики Т-Банка: Андрей, Арсений, Роман, Константин и Константин. Собираем интересные новости, статьи, туториалы и другие материалы из мира Java-разработки и делимся этим со всем сообществом.

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

Всем привет! Я Егор, недавно перешел из программирования в менеджмент и стал руководителем отдела разработки одного продукта в «Консист Бизнес Групп». В статье расскажу, как я решился на это, что мне помогло и чем я теперь занимаюсь. Она будет полезна студентам, джунам, ищущим себя и жаждущим перемен (а еще она смешная, надеюсь). 

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

Привет, Хабр! Новый год — отличное время для увлекательных экспериментов и творчества. Под катом — подборка пет-проектов, которые можно реализовать за новогодние праздники, от простых до сложных. Выберите свой, сохраните подборку и вдохновитесь на идеи для начала года! 🎄

Привет! Хочу рассказать о своем новом небольшом проекте - pg-status. Это очень легкий и производительный микросервис, который помогает определять статус хостов postgresql. В первую очередь его задача - помочь вашему backend найти живого мастера и достаточно синхронную реплику.

Одним солнечным днём мне прилетела задача - написать асинхронный механизм выгрузки данных по API.

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

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

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

Вы тоже устали? Устали объяснять ChatGPT структуру вашего проекта в десятый раз? Устали от того, что Cursor "съедает" ваши лимиты? Платные подписки нужны ради их мощных моделей, но обидно тратить драгоценные токены на бесконечные уточнения контекста.

Встречайте OpenSpec - конец vibe-кодинга. Это инструмент, который не просто "еще одна обертка над GPT", а смена парадигмы. Мы переходим от AI-чатов к Spec-Driven Development.