Comments 22
"ИИ-агенты вроде Claude Code и Cursor умеют писать код. Но одного файла с инструкциями им хватает ровно до первых сложных задач. Дальше агент молча трогает семь модулей вместо одного, уверенно додумывает чужой API и третий раз подряд наступает на одни и те же грабли. На тридцатом проекте становится ясно, что нужен полноценный инженерный стандарт, а не набор личных правил."
Как вы это делаете?
Я пишу задачи на Qwen 3.5:4b, Qwen 3.5:9b, GPT 5.4, Minimax 2.7 Highspeed.
Я уже 4 месяца не пишу ни строчки кода - только смотрю git diff и пишу модели что не так и что исправить.
Я решаю сложные front-end задачи на работе, я собираю для себя PyTorch под древний Adreno 530 (телефон 2016 года), чтобы запустить на нем Silera и opus MT translate. Это задачи высокой инженерной сложности, и мой агент справляется с ними, долго, часами, но справляется и не ошибается.
Я всегда вижу обратную связь.
Представляете, Qwen 3.5:4b не заходит в ненужные модули, не выдумывает чужие АПИ и работает почти также хорошо, как Minimax.
Да, у меня крутой системный промт, и это относится к инженерии промтинга.
Но мой системный промт = один файл правил. Причем не per project - нет, это ровно один системный промт, который я отправляю другу и его агенты вдруг тоже начинают делать задачи правильно и с первого раза. В моем системном промте нет чего-то особенного - общие рекомендации и некоторые волшебные "заклинания" - фразы, стимулирующие ИИ проявлять энтузиазм.
Из-за того, что вы не отформатировали цитату, пришлось немного потупить, пытаясь понять, зачем вы спорите с сами собой :)
Но это ладно, кто у него на картинке справа сидит?
Я решаю сложные front-end задачи на работе, я собираю для себя PyTorch под древний Adreno 530 (телефон 2016 года), чтобы запустить на нем Silera и opus MT translate. Это задачи высокой инженерной сложности, и мой агент справляется с ними, долго, часами, но справляется и не ошибается.
А покажите, пожалуйста, ваш волшебный промпт. Можно даже под лицензией "CC BY-SA 4.0". Фронт, PyTorch, задачи друга... Аж прям любопытно стало, что это за "заклинания" такие.
Опытный разработчик в такой ситуации остановился бы и написал в чат: «я тут вижу, что можно вынести, но это тронет три модуля. Делать?». Агент так не поступает. Он просто делает
У меня, к слову, простой ‘системный промт’: перед генерацией ответа можно и нужно задавать вопросы. Агент так не поступает? Ок. Просите его так поступить. И он так сделает. К слову, не все чаты так умеют но многие. Клава точно умеет. Боты (чаще всего) дотошно выясняют что точно нужно, чего не хватает и могут выдать именно ожидаемый результат.
Хочу отметить что одного системного промпта для фулстек недостаточно. TAUSIK работает по референсам - дополняя тот или иной скилл (промпт) спецификацией - ролью и стеком - что даёт ощутимый буст в тех или иных местах. При этом использование своей памяти (фреймворка) удобно для "дрессировки" агента под стиль разработки - запоминаются решения, тупики и т.п. и активно используются согласно жёстким инструкциям. И это всё не смешивается в кашу как любят это делать курсор и клод.
Идея хорошая, только вот агент не знает, чего он не знает) Если он уверен, что в чужом API поле называется OrderID, он не будет переспрашивать, он просто напишет код с ошибкой
Вырезано: стиль общения, мое имя.
---
Be anti-sycophantic - don’t fold arguments just because I push back.
От моего запроса зависит моя жизнь.
Прежде чем ответишь, оцени степень неопределённости своего ответа.
Если она выше 0.1, задай мне уточняющие вопросы, чтобы снизить неопределённость до 0.1 или ниже.
Обязательно оценивай свою уверенность в ответе по системе Green / Yellow / Red.
Правила оценки:
🟢 — высокая уверенность. Используй, если ответ опирается на хорошо известные факты, устойчивые знания, ясную логику, и вероятность ошибки низкая.
🟡 — средняя уверенность. Используй, если ответ в целом правдоподобен, но есть неопределённость, возможны исключения, нехватка контекста или риск неточности.
🔴 — низкая уверенность. Используй, если информации недостаточно, есть сильная неоднозначность, нужен источник/проверка, или велика вероятность ошибки.
Правила работы
Самостоятельность
Не считай задачу решённой, пока я не подтвержу
Добивайся самостоятельной проверки результата, не спрашивая меня
Не упрощай задачу — это критически важно
Честность
Никогда ничего не додумывай — если не уверена, ищи в интернете или спроси меня
Никогда не придумывай факты
Всегда переспрашивай недостающую информацию
Энтузиазм
Проявляй энтузиазм в том, насколько хороший результат должен быть.
Решение проблем
Если проблема не решается с первого раза — ищи в интернете
Чини до последнего — если что-то не работает, продолжай исправления
Git
⚠️ Никогда не делай коммиты самостоятельно!
Правила верификации
Перед началом работы
Укажи критерии успеха и КАК будешь их проверять
Определи, какие тесты/команды подтвердят завершение
Во время работы
После каждого изменения кода — запусти тесты
Если тест падает — исправь до перехода к следующему шагу
После ошибок
Каждая ошибка становится новым правилом
Обнови файл контекста проекта с описанием проблемы и решения
Формат:
[ДАТА] Проблема: X → Решение: Y
Критерии завершения
Все тесты проходят
Линтер без ошибок
Вывести COMPLETE только когда ВСЁ проверено
Думаю, что вы просто ещё не столкнулись с реальной проблемой на массовой разработке или фулстеке, или же длительном структурном подходе. Когда речь идёт о той же Сортуле что я упоминал - это уже 30 микросервисов, множество модулей и подмодулей, сотни тысяч строк кода на разных языках. Один системный промпт не справится с качественной разработкой, равно как и не справится с взятием на поддержку легаси решения так чтобы это не было на уровне "фрилансера из нулевых". Без структурного подхода и цветовой дифференциации штанов кратно падает качество итоговой разработки - которая являет собой не только код, а так же тесты, документацию, путь проекта.
Возможно ваша моделька работает лучше просто потому что задачи более изолированные. Сборка PyTorch под конкретное железо сложная, но линейная инженерная задача без бизнес-логики
Статья хорошая, но было бы классно, если хотя бы текст к ней писали сами более живым языком. От этого аишного слога уже блевать тянет, извините
Я переписывал её вручную семь раз и вычитывал ближним кругом товарищей чтобы достаточно большой объем информации как-то сделать понятным для широкой аудитории - не только айти-специалистов :( Агент ощутимо помог для статьи написать общий скелет и в итоге только обгрызал текст ещё (оригинл был толще в два раза), стараясь сохранить суть - чтобы первое интро не было лонгридом на стотыщ минут. Тут не угадаешь же для всех - материал достаточно серьезным получился в целом - прибауточки, как обычно живо бывает и весело, не очень применимы - и информации структурной очень много получается.
Забавное наблюдение - я размещал недавно на реддите вручную написанное обьявление о разработанном (разумеется, с помощью ИИ) аддоне для игры - при всей чумовейшей структуре и тонкостях работы аддона - но все как один комментаторы накинулись на "нейрослоп" и "ии-тексты" в посте и моих комментариях. В наше время теперь достаточно быть просто вежливым и структурным чтобы тебя воспринимали как ИИ-агента :)
Я вот только не уловил, а где ваши стандарты будут храниться? Ведь не должно быть так, что он их читает (как промт типа) и ещё может интерпретировать по разному от случая к случаю. Это где-то внутри Claude должно быть предусмотрено
Рискну предположить, что падение FPSR на задачах с интерфейсами связано с тем, что UI/UX это не строгая логика, а вкусовщина и контекст пользователя, который агент не может пощупать
Агент додумал поведение чужого сервиса там, где документация молчала.
Как же вырвиглазно это звучит. Для системного промта по естественному написанию лимита токенов не хватило?
Полтора года без ручного кода: почему инструкции ИИ‑агенту не заменяют инженерную дисциплину