Привет!

У меня на этой недели был леденящий душу опыт с хэппи эндом.

Я всю неделю активно девелопал новый сервис в Проекте Э и при этом активно экспериментировал с оптимизацией потребления РАМ и временем старта тестов.
И делал всё это вместе GPT-5 low reasoning через бесплатный план Windsurfa-а.

И он реально хорош. Он на порядок-два лучше GPT-4 и Sonnet-4. Практически не глючит и в 9 из 10 случаев быстрее меня решает WTF-ы со Спрингом. Например, у меня был value object в Sdj-модели с кастомным конвертером. И SDJ не мог найти конвертер. Я по привычке залез в кишки спринга и увидел, что конвертер доступен. Но не работает. Тут меня чёрт дёрнул спросить у гопатыча и он через минуту-две сказал, что я лупень и в модели импортнул не тот класс - у меня после экспериментов остался второй такой же класс в другом пакете. Мой опыт показывает, что я на такой фигне мог залипнуть на пару часов.

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

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

Однако сегодня я смог таки победить бездушную машину. В WTF-е с kover-ом. У меня была проблема с тем что конфиг на Kotlin DSL не компилялся. Тут я уже наоборот сходу пошёл к гопатычу и он начал глючить как не в себя. И не решил проблему. Тогда я сам вдумчиво прочитал сообщение об ошибке и решил проблему за минуту.

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

Но думать в направлении адаптации ЭП под нейронки - всё равно буду:) Соображения на этот счёт есть, но в другой раз напишу:)

В общем:
1. Для популярных фреймворков GPT 5 - нереально крут. Срочно пробуйте если ещё нет.
2. Но он всё ещё СЛАУ-переросток, не одупляет что он делает и в нестандартных случаях всё ещё бесполезен

#ai@ergonomic_code #project_e@ergonomic_code

Привет!

У нас в группе вчера зашла речь про использование ИИ в кодировании.

А я как раз последний месяц сам код практически не пишу и активно занимаюсь отстройкой процесса разработки на базе ИИ:)
Поэтому я и в группе подробно ответил и сюда решил репостнуть:)

Общий сетап:
1. Платная подписка на OpenAI за 23 евро
2. Идея для работы с кодом самому
3. VS Code + Codex для работы с агентом

Сейчас у меня процесс устроен так:
1. Я: завожу рабочую директорию задачи
2. Я: в режиме потока сознания сливаю постановку задачи в файл
3. Я: пуляю exec-spec-space-prompt.md (см. аттачи) в модель
4. Gpt-5.2 medium reasoning (в сложных на мой взгляд случаях - high/extra high): задаёт вопросы
5. Я: отвечаю
6. Модель: генерит 4 варианта реализации
7. Я: вот тут идёт самая вариативная часть
7.1. выбираю вариант
7.2. задаю доп вопросы и выбираю вариант
7.3. вижу что какой-то рефакторинг упростит решение -> обсуждаю его с моделью -> прошу сгенрять краткую постановку задачу на рефакторинг -> "делаю" рефакторинг -> на п. 6 с новыми вводными
7.4. даю уточнения к одному из вариантов модели и выбираю его
7.5 вкидываю свой вариант -> на п. 6
8. Модель: генерит 02-solution-options.md, 03-solution-hld.md и пишет транскрипт чата
9. Я: полуяю exec-spec-prompt.md в новый чат
10. Модель: генерит ТЗ
11. Я: тщательно ревьювлю ТЗ.
11.1 Если есть замечания: мелкие правлю сам, больше отдаю модели
12. Я пуляю промпт "реализуй ТЗ" в новый чат с GPT-5.2-Codex low
13. Модель реализует ТЗ
14. Я: смотрю результаты запуска тестов в чате и если их нет, или запущен не полный набор - запускаю сам. Если не прошли - скидываю логи модели и говорю починить.
15. Я: ревьювлю код и
15.1 мелочь правлю сам
15.2 большие куски прошу поправить модель
16. Я: прошу модель записать транскрипт чата реализации
17. Профит

Если модель лажает в кодировании - я пока просто в режиме свалки скидываю указания в AGENTS.md.

Касательно эффективности этого процесса у меня объективных данных нет.
Субъективно:
1. Этап проектирования и написания ТЗ - эффективнее, так как я люблю затупить при генерации или выборе вариантов, а потом не люблю аккуратно их расписывать, поэтому делаю это со множеством перекуров, перекусов, переписов и перекаков.
2. Этап реализации - пожалуй, не быстрее чем делать самому, если в потоке. А если делать на морально-волевых - модель, пожалуй, быстрее справляется. Плюс тут пока модель работает, можно самому заняться чем-то другим
3. Как альтернатива работе со стажёрами/джунами - намного эффективнее. На самом деле, раньше я и с юниорами примерно в таком же режиме работал и это было очень долго. Плюс у модели лучше получается мимикрировать под окружающий код (читай: под ЭП).

Я несколько раз слышал, что соннет лучше код пишет, но не осилил подтвердить у них телефон:)

#ai@ergonomic_code #tips@ergonomic_code

Привет!

ИИ похмелье...

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

Это ужас. Он там и найденные правила гайдлайна нарушил, и не нашёл нужные правила (но тут косяк фреймворка, наверное) и не реализовал требования, которые явно были в ТЗ.

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

Отдельную пикантность ситуации придаёт то, что буквально на этой неделе OpenAI релизнули версию Codex с очень бесячим и очевидным багом, который сводит автономность агента практически к нулю.

Когда-то слышал, что есть два типа гонищков:
1. первых находит предел сцепления машины с дорогой снизу - начинает ехать медленно и разгоняется пока не улетит
2. второй находит предел сцепления сверху - сразу топит на все деньги, а улетев превращается в первый тип

Вот я в этот раз был гонщиком второго типа. Теперь стал первого:)

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

И немного инсайтов:

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

2. Попробуйте добавить в системные инструкции "Chat answers must be at least 2x shorter than your natural default." - это заметно снижает объём ии слопа для ревью, а просадки в качестве я не заметил.

3. пишите файлы контекста своими руками, а потом отдавайте на ревью/перевод ИИ.

—

* примеры скиллов: "определить границы фичи", "составить список эндпоинтов, которые будут затронуты", "составить список критериев приёмки", "спроектировать рест апи", "закодировать приёмочный тест", "реализовать модель", "реализовать операцию"

#ai@ergonomic_code

Привет!

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

1. d-r-q/dot-agents - мои личные предпочтения и скиллы для работы агентов.
2. ergonomic-code/dot-agents - актуальная версия фреймворка.
3. ergonomic-code/dot-ai - архив с первым подходом к фреймворку.

Ну и первый, на мой взгляд полезный кусочек нового фреймворка - скилл генерации человеко-читаемого описания REST API.

С ним можно написать Codex-5.3 low:

[$describing-rest-api](skills/describing-rest-api/SKILL.md)

Опиши апи [NewsAdminController.kt](NewsAdminController.kt) .createNews

И получить такую штуку.

Или можно попросить Codex-5.3 medium:

[$skills/describing-rest-api/SKILL.md)
Опиши как изменилось апи NewsAdminController.kt .createNews в коммитах 39b4bf9d, 1abf8b1e, 05f01a28, f4622e63, b60daa6d, 0f4e2031

И получить такую штуку.

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

—

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

И вот с семантикой диффа, видимо, надо делать не один скилл/промпт, а многошаговый workflow:
1. собираем что вообще надо описать
2. с новым контекстом собираем ir что было и здесь и далее процедурно валидируем его
3. с новым контекстом собираем ir как стало
4. с новым контекстом, из что было, что стало, кодом и историей гита, собираем хинты диффов - какие эндпоинты поменяли пути, имена и структуру моделей, но продолжают выполнять ту же роль
5. с новым контекстом из данных пп 2-4 собираем ir с диффом
6. процедурно генеряем md

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

#ai@ergonomic_code #tools@ergonomic_code

Привет!

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

Мысль первая: а что если "ум" ИИ растёт не по экспоненте, а по логарифму?

Я начал упражняться с агентами в начале-середине весны 25 года с Junie. И это был крайне разочаровывающий опыт - он у меня в целом не завёлся и не написал ни строчки кода из-за каких-то багов, не помню уже точно каких.

Затем в конце весны-летом, случился качественный скачок - Junie и Windsurf (не помню с какими моделями) у меня хоть как-то заработали и начали хоть что-то писать. Но толку от этого было крайне мало - они всё делали очень медленно, часто вообще не могли решить проблему, а когда могли - делали какую-то дичь.

Затем, в августе вышел GPT-5 и это был ещё один качественный скачёк, который меня изрядно шокировал и напугал - теперь гопатыч стал лучше меня раскапывать всякую дичь со спрингом.

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

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

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

Это, конечно, может быть наивная надежда на чудо, свойственная кожаным мешкам, но что уж тут поделаешь:)

#ai@ergonomic_code

Мысль вторая: компиляторщики всё ещё не вымерли

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

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

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

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

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

#ai@ergonomic_code

Привет!

Мы тут в группе три дня делились опытом внедрения ИИ в практику - присоединяйтесь, если ещё нет:)

Ну и походу дела возникла идея одного опроса и я пока писал пост захотел провести второй (открытый) опрос - сейчас их заведу

#ai@ergonomic_code

Привет!

Потока создания пост.

Мысль первая

Пока мне было не до интернета, практически одновременно Саша Гранин написал, что разработка с ИИ у него не работает, а Макс Морев, что у него работает.

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

По этим двум причинам (текущий подход меня тормозит, а не научиться в ИИ страшно) я сейчас мигрирую от хайпового SDD к максимально ленивой спецификации - на входе брифы задачи и решения на 1-2 странички максимум, а дальше весь дизайн just in time™️ в цикле ТДД.
И всё это на ручной тяге - брифы я пишу сам руками, потом агент их ревьювит на предмет дыр/недоспецификации, а потом цикл ТДД я веду руками же с ручным ревью каждого шага.

В общем, у меня как всегда - выходит какой-то свой алтернативно одарённый мейнстриму велосипед. Но раз вы здесь - видимо вам тоже быть серой массой мейнстрима стрёмно 😂 Так что может вам мой велосипед больше понравится или он натолкнёт вас на свой велосипед:) Когда будет готов.

Хотя... Мой велосипед в части спеки/дизайна - это как раз то, как весь мейнстрим работал ещё пару лет назад. Так что может я просто быстрее остальных вернулся к адекватности:)

Да и SDD - выглядит как тот самый пресловутый водопад, от которого отказались 30 лет назад.

Мысль вторая

Судя по всему, для того чтобы получить кратный рост скорости разработки от применения ИИ - надо параллелить работу. При том на 3-4+ потока.

И тут я вижу две проблемы:

1. не все люди (я - точно) готовы работать в параллельном режиме. Я ещё готов вести одновременно с основной задачей разработки 1-2 мелких утилитарных задачки или баг фикса. Но вести одновременно две (или 6 🤯) полноценных задачи - нет, не мой путь.
2. не все организации (моя - точно) готовы обеспечить команду 3-4 x <размер команды> независимыми потоками работы.

—

Вобщем продолжаем наблюдать за ситуацией. Я всё ещё не берусь предсказать куда эта вся эпопея вырулит.

#ai@ergonomic_code #dot_agents@ergonomic_code

Привет!

Я тут подбил немного пугающей статистики:
1. во второй половине 25-ого года, когда я ещё львную долю кода писал сам, у меня было ~1 баг на 175 строк кода.
2. а в 26-году, когда я перешёл на ИИ-разработку - уже примерно по багу на 80 строк кода 😱

Помним, конечно, что есть ложь, наглая ложь и статистика, но... Двукратный рост... Двухкратный, Карл.

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

#ai@ergonomic_code

Отдельно стоит рассказать про "Полез копаться".

Сначала я методом пристального вглядывания начал втыкать в свой первый фикс, пытаясь понять что за фигня. Повтыкал минут 5 иии... пошёл к Codex-у с гопатычем 5.5 medium-xhigh.

Гопатыч долго (часа 3 в разных сессиях) и упорно втирал мне про, то что проблема в количестве запросов подключений и длине очереди, рисовал мне всякие формулы в духе "время обработки запроса = размер очереди * время обработки одного запроса" и т.п. И в целом был довольно убедителен.

Но у меня в голове картинка не сходилась - я не мог понять как эта очередь выстраивается так, что какой-то из запросов не получал подключение в течение 30 секунд.

Я уже было отчаялся и решил забить - проблема-то решена, по факту, пока можно жить дальше.
Но решил попробовать в вебе GPT-5.6 Sol/Xhigh и он сразу ткнул меня носом в то, что подключения тупо заканчиваются и загрузка агрегатов уходит в дедлок.

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

Мораль этой басни:
1. Все врут. В том числе и топовые ЛЛМки.
2. Если в чате с ЛЛМкой вы чувствуете себя дебилом - скорее всего дебилом является ЛЛМка.

#ai@ergonomic_code

Привет!

Простые CRUD-приложения - это сложно

Если помните, я уже писал, что с момента перехода GPT-4 -> GPT-5 я качественных скачков в росте пользы от агентов больше не видел.
И вот, вышел GPT-5.6-sol - а я снова не чувствую никакой разницы с GPT-5.*

Недавно я в Проекте Э сделал с ним не совсем тривиальную задачку: обеспечить синхронизацию обработки аутбокса на нескольких репликах, которая требует обращения во внешнюю систему.

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

И при этом грешил гопатыч ровно тем, чем грешили мои коллеги из "лихих годов":

1. локальные хаки и костыли, вместо пересмотра модели
2. привнесение надуманной сложности, которая не имела практической пользы
3. бездумный перенос кусков кода из одного контекста в другой, где они теряли смысл и вообще ломали смысл окружающего кода
4. хрестоматийные ошибки дизайна - дублирование смысла кода, с немного разным выражением (DRY); нарушение CQS; нарушения баланса захвата/освобождения ресурсов; неуместные граничные/специальные случаи; нарушение зон ответственности (do one thing)

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

В прошлом году я скрипя сердцем признал, что всю жизнь занимаюсь всего лишь "простыми CRUD-приложениями", которым не нужны ни ЧА, ни DDD, ни ФА, ни любая-другая-крутая-аббревиатура. И чтобы как-то повысить ценность и значимость своей работы, а так же обосновать необходимость ЭП, я даже придумал термин "сложные CRUD-приложения".

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

И всё это сподвигло меня начать писать новый большой пост с разбором этих сессий кодирования с вариантами названия "Шок! GPT-5.6 не может написать простую крудилку!" и "Простые CRUD-приложения - это сложно".

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

Полезняшка №1: роллауты сессий

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

А у этого скилла куча применений:
1. основное у меня - я большинство правок своего фреймворка (он, кстати, жив и развивается) идёт через скилл fix-framework-context куда я пишу ид сессии, что агент сделал не так и как надо было. И гопатыч по роллауту разбирает почему агент в сессии сделал не то что надо и как это поправить.
2. я сейчас отчёты о работе за месяц для заказчика формирую гопатычем и на вход среди прочего подаю эти сессии
3. ну и в контексте этого поста - по этим сессиям гопатыч восстановил мне хронологию наших с ним метаний во время решения задачи с привязками ко времени, промптам и бэкапам - без чего я бы вряд ли смог так подробно разобрать что происходило, как это делаю сейчас

Полезняшка №2: Бэкапы

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

И одна из особенностей этой системы заключается в том, что для моих рабочих директорий у меня снимаются снапшоты каждые 5 минут и для 8 последних дней хранятся все эти снапшоты.

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

Для бэкапов системы (на Linux) я использую Timeshift, для бэкапов рабочих файлов, архивов и конфигов - backintime, а для синка файлов между устройствами - syncthing с нодой с шифрованием на VDS-е за 900р/мес.

—

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

#ai@ergonomic_code #tips@ergonomic_code