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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для этого, путем многих итераций был создан скилл 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! ✌️

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

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

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

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

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

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

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

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

Сегодня расскажу об одной загадочной штуке под названием 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.

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