Machine Head - Александр О

Скиллы для Codex и Claude Code

2026-06-04T12:26:24.617Z

3 этих скила в 10х прокачают ваш рабочий процесс разработки. Протестрован в бою на больших production проектах с сотнями тысяч строк кода.

В наборе 3 скилла:

brainstorm - помогает структурировать идеи как реализовать ту или иную вещь. Не форсит, подсказывает, легко возвращает агента в канву разговора даже если вы отвлеклись на пару других вопросов. На выходе профессионально составленный дизайн документ.
planner - скормите ему дизайн документ и получите четко структурированный план разработки, разбитый по спринтам. Запускайте каждый спринт в отдельной сессии по очереди - контекстного окна в 97% случаев хватит, чтобы выполнить спринт целиком.
code-review - скилл специально заточен на проверку спринта. Просто укажите в промпте ссылку на дизайн-документ и план разработки и получите детальное ревью, сфокусированное на проверке точности следования указаниям и продуманному дизайну.

Пользуйтесь с удовольствием! Обратная связь приветствуется!
Ссылка на скилы на Github - https://github.com/pridees/skillforce

Оставайтесь на связи и подключайтесь к сообществу в Тг MachineHead.

Раньше мы писали на Assembler, но с современными языками нам не нужно знать как он работает!

2026-06-02T18:04:04.755Z

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

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

За обработку естественного языка отвечает биологическая машина - наш мозг. Естественный язык формируется из картины мира и формирует ее. У нас бы не было проблем договариваться, не существовало фразы "Я тебя неправильно понял" если бы естественный язык на 100% был формален по отношению к сущности передаваемой информации. Он слишком емкий и полагается на многослойный контекст нашего опыта, убеждений, предпочтений и многое другое.

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

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

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

Вы можете справедливо заметить - мы же пользуемся приемами формализации задачи в спецификации! Да, верно, мы сужаем (как умеем) естественный язык до некоего формального оптимума, комфортного людям разных специализаций. Но и он не лишен двусмысленности. То есть, чтобы AI создал нам определенный код с какой-то гарантией, нам нужно дать прямое указание на генерацию конкретного поведения программы вплоть до отдельных строк. Де-факто, это то же программирование, только без строго синтаксиса. Но даже в этом случае мы не можем (в данный момент) утверждать, что сгенерированный код соответствует ожиданиям.

Стартап широко известного в узких кругах Андрея Бреслава CodeSpeak пытается сыграть на этом поле. Его идея как раз в построчном описании генерируемого нейронкой результата. Application.cs.md по задумке должен превратиться в Application.cs, что должно дать выигрыш в уменьшении кодовой базы до нескольких раз и снятия требований к знанию синтаксиса конкретного языка для изменения программы - его смогут читать и понимать не только программисты. Идея интересная, но:
- как дебажить ошибки не связанные с требованиями? Так нам все еще нужно знать асинхронную модель Java или CLR?
- как, не проваливаясь к синтаксису ЯП, связать код объявленный в модуле А с кодом в модуле Б?
- как отлаживать поэтический стиль Пети, который генерирует код с ошибкой?

И масса других вопросов.

Если все это требует перехода к формализму синтаксиса ЯП, то выигрыша как будто бы и нет.

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

Тизер. В следующем посте обсудим в каком на самом деле состоянии сейчас рынок труда. Оставайтесь на связи с MachineHead.

Так заменит ли AI разработчиков?

2026-06-02T17:57:01.498Z

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

Я проработал с агентом почти год. Однозначно позитивные эффекты:

1) Время отладки проблем уменьшается на порядки.
2) Время выполнения микрозадач так же на порядки.
3) Время на выполнение средних задач такое же, как если бы я делал руками.

А вот время на выполнение сложных задач увеличилось.

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

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

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

И всё это ощущается как припарка, но не замена. Не считая минус вайб к программированию в целом.

Я каждый день слышу, что кто-то там дирижирует оркестром claude-кодов, но почему-то не видно продуктов из этой адской кузни. Новости типа той, что claude переписал bun с Zig на Rust не в счет. Невелика заслуга сконвертировать отполированный людьми код с одного языка на другой.

Так что нет, не заменит. Не Claude. Ни GPT. Ни кто-либо другой. Также не будет AGI на llm моделях. Пора перестать вестись на pre-IPO маркетинг и дозировать допинг с работой головой и руками.

Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned! ✌️

TL:DR к статье, для тех кто не тимлид и не руководитель, но хочет резко прокачать свою работу с агентами

2026-06-02T17:54:14.633Z

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

Для этого, путем многих итераций был создан скилл brainstorm. Он организует весь этот цикл. Просто попробуйте. Работает в Codex, Claude Code, и более менее других популярных агентах. Обычно, в промпте я триггерю скилл вручную и начинаю фразу "давай спроектируем/продумаем и тд". Крайне полезно после перечислить UserStory или верхнеуровневые требования. Самая крутая фича этого скила: возможность обсудить проблему/подход/решение с агентом и когда вопрос уточнен, он сам возвращается на прежний трек последовательных вопросов-ответов. Без форка сессии, с сохранением в контексте потока мыслей и гипотез.

Далее. Эту спеку я перекладываю в скилл Planner. Этот скилл разбивает спеку на спринты так, чтобы с 90% вероятностью 1 спринт уложился в 1 контекстное окно и выполнен за 1 заход. Кто бы что ни говорил, а 1М контекста в клоде либо оверюзает токены, либо качество деградирует. Модель держит форму до 400К, но после ... такое себе. GPT 5.5 стал есть драматически меньше токенов и я перестал сталкиваться с ухудшением результатов после автокомпакта.

На выходе обоих скиллов я получаю 2 артекфакта: спека + план. Далее я приступаю к методичной работе plan-implement используя простейший промпт, как например этот, когда делал дешборды аналитики в Prospect Guide:

Бери в работу Sprint 1 плана content-section-analytics-plan.md

И финалочка - скилл code-review. Через него я прогоняю результат работы по спринту.

/code-review Sprint 1 of content-section-analytics-plan.md

Не доверяясь целиком машине, ревьюю глазами, правлю, слежу за полной тестов и тд. В масштабе 1 спринта, делать это комфортно, есть возможность сверяться со спекой.

Вы вероятно спросите, почему это лучше популярного набора скилов superpowers, в котором есть brainstorm, write-plan, implement и другие?

1. Их brainstorm не дает подумать или изменить решение. Задает 3-4 вопроса, зачастую просто подтверждая указанные требования и фиксирует их в спеке. Я хочу, чтобы вопросов было больше, они были глубже, агент фильтровал их по значимости, исследовал код и нашел проблемы, невидимые с поверхности и обсудил и со мной. А потом убедился, что он правильно понял мое намерение.

2. write-plan пишет готовые вставки куда код воткнуть. Это дичь, которая меня дико бесила. Я хочу, чтобы спека и план формулировали ЧТО я хочу и КАК это лучше сделать, а не впихивали в план готовые куски кода, чтобы потом растасовать их по файлам. Ну и этот план нереально рабивать на куски. Useless вообщем. Хорошо для замены примитивного промптинга, но для серьезной работы никуда не годится.

Вот мой пак скилов завернутый в набор Skillforce на Github, забирайте, пользуйтесь, кидайте идеи и фидбек. Ставятся на изи, стандартным способом в любой репозиторий.

Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned! ✌️

ИИ в больших инженерных командах

2026-06-02T17:50:22.962Z

Давно собирался расписать.

В разговорах с тимлидами и CTO постоянно одна и та же картина: дали кодерам ИИ (тот же Cursor), надеялись на буст продуктивности, а бустанули число инцидентов или просто замедлились в тех или иных местах.

Поначалу я думал, дело в инструментах. Потом в зрелости команд. Потом в моделях. Оказалось, нет. Подход. Административная инициатива "сверху-вниз" без ясного понимания как это будет работать на местах, не работает с разработчиками высоких грейдов.

Расписал, как с этим жить.

Туториал для IT руководителей как дать ИИ команде, чтобы пересадить ребят на работу с агентами:

1️⃣ почему решение спущенное сверху-вниз проваливается,
2️⃣ что такое «подчинённая проактивная позиция» агента
3️⃣ три фазы интеграции агентского кодинга.

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

Подписывайтесь на MachineHead и делитесь с друзьями! Stay tuned! ✌️

https://habr.com/ru/articles/1030314

End of file (EOF)

2021-04-29T08:51:35.389Z

#programming

Сегодня расскажу об одной загадочной штуке под названием EOF. "Спецсимвол в конце файла!" - воскликнет юный падаван будет не прав. Разберемся, что за мазафака такая.

EOF - это особая ситуация! Которая может быть проверена с помощью средств стандартных библиотек любого языка программирования. Не существует никого особого символа на манер символа new line "\n".

Чтобы убедиться в этом достаточно вспомнить, что в Unix системах, терминал умеет имитировать ситуацию EOF с помощью сочетания клавиш Ctrl-D, которая прерывает поток ввода более гуманным способом, чем SIGINT.

Ситуация "End of file" это набор признаков, при которых можно сделать вывод что файл закончился. Если пойти "в лоб" и попытаться читать файл посимвольно, в надежде, что цикл прекратится на последнем символе - то можно обратить внимание, что кол-во прочитанных символов будет больше, чем мы ожидаем. При при отсутствии проверки на EOF, последним символом окажется - 0. В этот момент цикл упирается в конец файла и зависает, без передачи управления дальнейшим инструкциям.

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

Читаем файл из Python:

with open('somefile') as openfileobject:
    for line in openfileobject:
        do_something()

че вообще? какой EOF. Закончились строки - вышел из цикла.

В то же время Си-шнику стоит быть начеку:

while ((ch != '\n') && (ch != EOF)) {
// read the next ch
}

Внимательный юзер заметит что char проверяется на EOF, аналогично \n, будто это символ такой. Как же так? Дело в том что char - беззнаковое число. В случае, если достигнут конец файла EOF вернет -1.

Способ проверки концовки файла в разных языках разный. Вот такая загогулина.