"One more feature, bro, one more fix — и точно полетит"
Классическая ловушка, в которую с завидной регулярностью попадает почти любой технарь или фаундер. Мы готовы ночами вылизывать архитектуру, переписывать промпты и пачками сжигать токены OpenAI. Потому что писать код и ковырять пайплайны — это понятно, безопасно и полностью подконтрольно.
А вот маркетинг, продажи и кастдевы — это больно, непредсказуемо и требует выхода из зоны комфорта.
В итоге разработка превращается в психологическое убежище. Но суровая реальность бизнеса проста: рынку плевать, сколько бессонных ночей вложено в красивый код. Если о продукте никто не знает и им никто не пользуется — продукта не существует. Всё остальное — это не стартап, а просто дорогое хобби и добровольное спонсирование счетов IT-гигантов за инфраструктуру.
Самый полезный "коммит", который вы можете сделать для своего проекта — это закрыть IDE и пойти писать потенциальным клиентам. Спрашивать, рассказывать.
Классическая ловушка, в которую с завидной регулярностью попадает почти любой технарь или фаундер. Мы готовы ночами вылизывать архитектуру, переписывать промпты и пачками сжигать токены OpenAI. Потому что писать код и ковырять пайплайны — это понятно, безопасно и полностью подконтрольно.
А вот маркетинг, продажи и кастдевы — это больно, непредсказуемо и требует выхода из зоны комфорта.
В итоге разработка превращается в психологическое убежище. Но суровая реальность бизнеса проста: рынку плевать, сколько бессонных ночей вложено в красивый код. Если о продукте никто не знает и им никто не пользуется — продукта не существует. Всё остальное — это не стартап, а просто дорогое хобби и добровольное спонсирование счетов IT-гигантов за инфраструктуру.
Самый полезный "коммит", который вы можете сделать для своего проекта — это закрыть IDE и пойти писать потенциальным клиентам. Спрашивать, рассказывать.
👍21🔥9
Готовлю доклад "Препарируем Harness" — про то, как агенты устроены под капотом.
На опыте своих печальных ошибок и полуночного препарирования того, что сейчас есть на рынке, разберём типовые компоненты и главные грабли их реализации. Поговорим о том, почему писать свой harness категорически не нужно, но как сделать это с минимальными потерями, если деваться некуда.
Полезем в кишки — потому что это интересно, и потому что это понимание помогает работать с агентами эффективнее.
На опыте своих печальных ошибок и полуночного препарирования того, что сейчас есть на рынке, разберём типовые компоненты и главные грабли их реализации. Поговорим о том, почему писать свой harness категорически не нужно, но как сделать это с минимальными потерями, если деваться некуда.
Полезем в кишки — потому что это интересно, и потому что это понимание помогает работать с агентами эффективнее.
🔥32👍6
Хочу однажды написать книжку "Как навести порядок в компании без денег и полномочий".
Первая глава будетне очень объёмной и содержать всего одно слово: "никак".
А вот в последующих главах будет рассказано, как наработать полномочия, деньги, сформулировать договорённости и не привлечь внимание санитаров.
Первая глава будет
А вот в последующих главах будет рассказано, как наработать полномочия, деньги, сформулировать договорённости
Spec Driven Development в эпоху LLM — сомнительная фигня на грани карго-культа.
Фронтирные модели способны виртуозно выкручиваться, когда их заваливают километровыми спеками. Достаточно пары случайно оброненных слов в ТЗ — и сетка радостно нагородит оверинжиниринг на три слоя абстракций, о которых никто не просил. И виноват будет, конечно "этот ИИ, который никогда не заменит Настоящих Программистов".
Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.
Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?
Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC".
Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.
Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.
Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.
И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.
"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.
Фронтирные модели способны виртуозно выкручиваться, когда их заваливают километровыми спеками. Достаточно пары случайно оброненных слов в ТЗ — и сетка радостно нагородит оверинжиниринг на три слоя абстракций, о которых никто не просил. И виноват будет, конечно "этот ИИ, который никогда не заменит Настоящих Программистов".
Вместо написания простыней текста сделайте нормальный boilerplate и заложите нужные вам паттерны. Модель читает код, модель живёт кодом, модель продолжит реальные бест практис кодом гораздо точнее, чем попытается расшифровать литературные фантазии о ста листах.
Зачем писать эти километры спек? Чтобы оправдать занятость аналитиков и создать видимость "важного артефакта перед началом кодинга"? Чтобы "делать всё привычно, там же должна быть аналитика перед разработкой"?
Я ставлю ребром вопрос — должен ли AI SDLC быть "автоматизированным с помощью ИИ SDLC".
Есть ощущение — что не должен. Что AI SDLC должен строиться на других принципах.
Сделай веточку -> Запили инкрементальное изменение -> выкати на тестовый стенд -> РАЗБЕРИСЬ, ЧТО вышло. Подошло — забираем. Получилась дичь — отклонили и перегенерили с нуля.
Ключевой шаг — РАЗОБРАТЬСЯ. Сам принцип приёмки меняется фундаментально. Это выглядит не как "потыкать кнопочки в UI" и уж точно не "поверить агенту на слово, что он всё сделал". Нужен многосторонний инженерный аудит: архитектура, ключевые точки в коде типа миграций, безопасность, надежность, продуктовая наполненность, и много-много всего ещё.
И цель всех этих муторствований — не пройти по бизнес-процессу производства нейрослопного кода. Цель — находясь в постоянно меняющейся, непознанной среде (код меняется, процессы меняются, запросы клиентов меняются, бизнес адаптируется) проводить эксперименты, проверять гипотезы и накапливать экспертизу.
"Программирование на спеках" — это попытка в меняющейся среде с недетерменированными акторами построить конвеер по выпеканию одинаковых булочек.
1👍21💩9🔥2🎉1
Полистал тут шортсы и, кажется, докопался до корня всей этой священной войны против ИИ в разработке. И вот этих бесконечных криков о том, что без Spec-Driven Development и вычитывания каждой строчки спеки мы все умрём.
Корень проблемы — в профдеформации.
Разрабы часто вообще не смотрят на продукт. Им может быть плевать, как он работает у пользователя, решает ли боль и приносит ли деньги. Для них результат работы — это сам код. Текст. И этот текст обязан быть "красивеньким". Чтобы функции назывались строго так, как разработчик привык видеть в своих влажных мечтах о чистой архитектуре, а файлики лежали по фэншую.
Когда нейронка выдаёт рабочий результат за три минуты, у инженера ломается шаблон. Вместо радости за ускорение поставки ценности начинается микроменеджмент синтаксиса: "нет, ну вы посмотрите, она назвала переменную не camelCase, а архитектура не по Мартину!". Эго требует контроля над буквами, а не над результатом.
SDD и фанатичное ревью спек в таком контексте превращаются не в инструмент проектирования, а в попытку заставить ИИ думать и писать в точности как Вася из третьего отдела.
Чтобы не сходить с ума от происходящего и не тормозить команду, я держу в голове простые тезисы:
1. Код — это расходник, а не памятник архитектуры. Пользователю всё равно, насколько изящно вы отформатировали цикл, если фича не решает его задачу.
2. Оценивайте результат, а не стиль письма. Если сгенерированный модуль работает надежно, покрыт тестами и не создает проблем на проде — отпустите свои эстетические травмы.
3. Контролировать надо ключевые точки, а не табы и пробелы в коде. Основные заложенные алгоритмы, изменения структур данных, работу фич, работу с данными, как решение будет проходить через стадии SDLC (сборку, деплой на разные контуры и т.п.) и т.п. Контроль должен быть, но он должен быть умным и всеобъемлющим. И для него не обязательно читать код!
Пока одни тратят часы на вылизывание того, что завтра всё равно перепишут, другие просто выкатывают продукт и забирают рынок. Сдвигайте фокус с красоты текста на то, чтобы текст вообще начал приносить ценность!
Корень проблемы — в профдеформации.
Разрабы часто вообще не смотрят на продукт. Им может быть плевать, как он работает у пользователя, решает ли боль и приносит ли деньги. Для них результат работы — это сам код. Текст. И этот текст обязан быть "красивеньким". Чтобы функции назывались строго так, как разработчик привык видеть в своих влажных мечтах о чистой архитектуре, а файлики лежали по фэншую.
Когда нейронка выдаёт рабочий результат за три минуты, у инженера ломается шаблон. Вместо радости за ускорение поставки ценности начинается микроменеджмент синтаксиса: "нет, ну вы посмотрите, она назвала переменную не camelCase, а архитектура не по Мартину!". Эго требует контроля над буквами, а не над результатом.
SDD и фанатичное ревью спек в таком контексте превращаются не в инструмент проектирования, а в попытку заставить ИИ думать и писать в точности как Вася из третьего отдела.
Чтобы не сходить с ума от происходящего и не тормозить команду, я держу в голове простые тезисы:
1. Код — это расходник, а не памятник архитектуры. Пользователю всё равно, насколько изящно вы отформатировали цикл, если фича не решает его задачу.
2. Оценивайте результат, а не стиль письма. Если сгенерированный модуль работает надежно, покрыт тестами и не создает проблем на проде — отпустите свои эстетические травмы.
3. Контролировать надо ключевые точки, а не табы и пробелы в коде. Основные заложенные алгоритмы, изменения структур данных, работу фич, работу с данными, как решение будет проходить через стадии SDLC (сборку, деплой на разные контуры и т.п.) и т.п. Контроль должен быть, но он должен быть умным и всеобъемлющим. И для него не обязательно читать код!
Пока одни тратят часы на вылизывание того, что завтра всё равно перепишут, другие просто выкатывают продукт и забирают рынок. Сдвигайте фокус с красоты текста на то, чтобы текст вообще начал приносить ценность!
2👍24💩20🔥10
Вы переживаете, что ИИ делает вас тупым и заставляет забыть как кодить?
А кто вам сказал, что вы вообще умели кодить, по правде говоря?
• ты никогда не помнил шаблоны проектирования.
• ты постоянно гуглил ответы людей на stackoverflow. Людей, у которых точно такие же проблемы. И ты просто брал и копипастил написанное решение.
Ну серьёзно.
Ты хоть раз писал хотя бы один HTTP запрос вручную, самостоятельно? Без документации, без примеров, просто ты — и чистый код, проистекающий из твоих пальцев?
Сомнительно.
Ты копипастил сообщение об ошибке в гугл. А теперь твой ИИ копипастит сообщение об ошибке в гугл. Это прям реально такая большая разница?
Нет, конечно, существуют настоящие, великие программисты. Программисты, которые исследуют и улучшают компиляторы, программисты, которые наполняют stackoverflow правильными ответами.
Но будем честны — это не мы с вами.
ИИ не лишает вас навыков программирования. Было бы чего лишать.
А кто вам сказал, что вы вообще умели кодить, по правде говоря?
• ты никогда не помнил шаблоны проектирования.
• ты постоянно гуглил ответы людей на stackoverflow. Людей, у которых точно такие же проблемы. И ты просто брал и копипастил написанное решение.
Ну серьёзно.
Ты хоть раз писал хотя бы один HTTP запрос вручную, самостоятельно? Без документации, без примеров, просто ты — и чистый код, проистекающий из твоих пальцев?
Сомнительно.
Ты копипастил сообщение об ошибке в гугл. А теперь твой ИИ копипастит сообщение об ошибке в гугл. Это прям реально такая большая разница?
Нет, конечно, существуют настоящие, великие программисты. Программисты, которые исследуют и улучшают компиляторы, программисты, которые наполняют stackoverflow правильными ответами.
Но будем честны — это не мы с вами.
ИИ не лишает вас навыков программирования. Было бы чего лишать.
Управлять требованиями и генерить/ревьювить километровые спеки - не одно и то же.
Первое - не автоматизируемо и является ключевой работой инженера.
Второе - бесполезно.
Первое - не автоматизируемо и является ключевой работой инженера.
Второе - бесполезно.
👍11🤣7🤔3
Монтирую новый видосик о внутреннем устройстве агента и harness, о том, какие подводные камни вас ждут при создании своего агента и как глубока кроличья нора.
О том, почему ни в коем случае нельзя лезть в историю с созданием своего агента и что делать, если это всё-таки нужно сделать.
Понимая внутреннее устройство харнесса вы также будете лучше понимать, что имеет смысл от него ожидать, а что нет, и как с ним общаться эффективнее.
О том, почему ни в коем случае нельзя лезть в историю с созданием своего агента и что делать, если это всё-таки нужно сделать.
Понимая внутреннее устройство харнесса вы также будете лучше понимать, что имеет смысл от него ожидать, а что нет, и как с ним общаться эффективнее.
🔥12👍2
Как менеджер с многолетним опытом управления людьми, всё же прихожу к выводу, что хуйня этот ваш ИИ.
Все почему-то решили, что управление — это поставить задачу, получить результат и проверить качество. Но управление так не работает. Здесь важны личный контакт, авторитет руководителя и невербальная коммуникация.
Когда сотрудник начинает расслабляться, необязательно назначать отдельную встречу и тратить время на разговоры. Иногда достаточно положить ему руку на плечо и спокойно спросить, почему задача до сих пор не готова. Нормальный сотрудник в этот момент начинает нервничать, собирается, работает быстрее и допускает меньше ошибок — сразу видно, что управление подействовало.
Хороший менеджер вообще многое умеет донести одним взглядом. Сотрудник сразу понимает серьёзность ситуации, ответственность перед командой и возможные последствия. Это и называется опытом работы с людьми.
С ИИ такого не получится. Он не считывает авторитет. Не понимает интонацию. Не чувствует, что руководитель недоволен. Вместо того чтобы собраться и начать работать, просит уточнить требования и критерии готовности.
С мотивацией та же проблема. ИИ нельзя публично похвалить на общем собрании, выдать ему грамоту по итогам квартала или пообещать пересмотреть грейд, если он ещё немного постарается. На него не влияет перспектива лишиться премии. Он не переживает за своё будущее в компании.
А ведь управление — это искусство, оно требует опыта!
Ну вот как ты профессионально, по-менеджерски посмотришь ИИ в глаза? Придёшь в датацентр и будешь смотреть на серверы?
Это так не работает.
Потому что нет страха в глазах у серверов.
Все почему-то решили, что управление — это поставить задачу, получить результат и проверить качество. Но управление так не работает. Здесь важны личный контакт, авторитет руководителя и невербальная коммуникация.
Когда сотрудник начинает расслабляться, необязательно назначать отдельную встречу и тратить время на разговоры. Иногда достаточно положить ему руку на плечо и спокойно спросить, почему задача до сих пор не готова. Нормальный сотрудник в этот момент начинает нервничать, собирается, работает быстрее и допускает меньше ошибок — сразу видно, что управление подействовало.
Хороший менеджер вообще многое умеет донести одним взглядом. Сотрудник сразу понимает серьёзность ситуации, ответственность перед командой и возможные последствия. Это и называется опытом работы с людьми.
С ИИ такого не получится. Он не считывает авторитет. Не понимает интонацию. Не чувствует, что руководитель недоволен. Вместо того чтобы собраться и начать работать, просит уточнить требования и критерии готовности.
С мотивацией та же проблема. ИИ нельзя публично похвалить на общем собрании, выдать ему грамоту по итогам квартала или пообещать пересмотреть грейд, если он ещё немного постарается. На него не влияет перспектива лишиться премии. Он не переживает за своё будущее в компании.
А ведь управление — это искусство, оно требует опыта!
Ну вот как ты профессионально, по-менеджерски посмотришь ИИ в глаза? Придёшь в датацентр и будешь смотреть на серверы?
Это так не работает.
Потому что нет страха в глазах у серверов.
🤣28
Нанять product engineer легко. Гораздо сложнее перестать согласовывать с семью людьми каждое его движение.
Сейчас продвигается концепт product engineer — человека-оркестра, который с помощью ИИ самостоятельно проходит весь путь от пользовательской проблемы до работающей фичи. Поговорил с пользователями, придумал решение, написал код, протестировал, выкатил и посмотрел на метрики. То есть — всё то, для чего раньше требовались аналитик, продакт, разработчик, тестировщик и несколько свободных слотов в календаре.
Инженеры, конечно, возражают. Мол, один человек не может быть специалистом во всём, независимая проверка исчезнет, качество упадёт, а техдолг однажды обретёт сознание.
Менеджеры тоже переживают: ведь аналитик должен проверить требования, тестировщик — разработчика, архитектор — всех сразу, а менеджер проконтролировать, что участники процесса не забыли проконтролировать друг друга.
Только люди, которые уже внедряют такую модель, говорят, что заметной просадки на продуктовых метриках пока не видно. Не то чтобы в наше непростое время стоило верить джентльменам на слово, но всё же.
И тут возникает неприятный вопрос: а зачем нам действительно было нужно столько отдельных ролей?
Возможно, разделение труда существует не только ради экспертизы. Оно ещё помогает компании справляться с недоверием.
Аналитик пишет требования, потому что разработчику нельзя доверить понимание пользователя. Архитектор согласовывает решение, потому что разработчику нельзя доверить архитектуру. Тестировщик проверяет код, потому что разработчику нельзя доверить качество.
В результате процесс производит не только продукт. Он ещё производит доказательства, что никто конкретно не виноват.
С product engineer такой фокус провернуть сложнее. В одной голове находятся проблема, решение, реализация и результат. Сказать "моя часть работала" уже не получится — дальше тоже был ты.
Но для этого человеку придётся выдать не только четыре чужие обязанности, но и полномочия четырёх ролей. А вот с этим компании традиционно тяжело😁
Возможно, ИИ не создаёт новую профессию. Он просто удешевил производство настолько, что стоимость корпоративного недоверия впервые стала хорошо заметна. Когда код писался месяц, две недели согласований терялись внутри общего срока. Когда код пишется за день, внезапно выясняется, что самым медленным компонентом системы всё это время был не разработчик.
Сейчас продвигается концепт product engineer — человека-оркестра, который с помощью ИИ самостоятельно проходит весь путь от пользовательской проблемы до работающей фичи. Поговорил с пользователями, придумал решение, написал код, протестировал, выкатил и посмотрел на метрики. То есть — всё то, для чего раньше требовались аналитик, продакт, разработчик, тестировщик и несколько свободных слотов в календаре.
Инженеры, конечно, возражают. Мол, один человек не может быть специалистом во всём, независимая проверка исчезнет, качество упадёт, а техдолг однажды обретёт сознание.
Менеджеры тоже переживают: ведь аналитик должен проверить требования, тестировщик — разработчика, архитектор — всех сразу, а менеджер проконтролировать, что участники процесса не забыли проконтролировать друг друга.
Только люди, которые уже внедряют такую модель, говорят, что заметной просадки на продуктовых метриках пока не видно. Не то чтобы в наше непростое время стоило верить джентльменам на слово, но всё же.
И тут возникает неприятный вопрос: а зачем нам действительно было нужно столько отдельных ролей?
Возможно, разделение труда существует не только ради экспертизы. Оно ещё помогает компании справляться с недоверием.
Аналитик пишет требования, потому что разработчику нельзя доверить понимание пользователя. Архитектор согласовывает решение, потому что разработчику нельзя доверить архитектуру. Тестировщик проверяет код, потому что разработчику нельзя доверить качество.
В результате процесс производит не только продукт. Он ещё производит доказательства, что никто конкретно не виноват.
С product engineer такой фокус провернуть сложнее. В одной голове находятся проблема, решение, реализация и результат. Сказать "моя часть работала" уже не получится — дальше тоже был ты.
Но для этого человеку придётся выдать не только четыре чужие обязанности, но и полномочия четырёх ролей. А вот с этим компании традиционно тяжело
Возможно, ИИ не создаёт новую профессию. Он просто удешевил производство настолько, что стоимость корпоративного недоверия впервые стала хорошо заметна. Когда код писался месяц, две недели согласований терялись внутри общего срока. Когда код пишется за день, внезапно выясняется, что самым медленным компонентом системы всё это время был не разработчик.
Please open Telegram to view this post
VIEW IN TELEGRAM
Давайте быстро напишем своего AI-агента!
Это новый вариант фразы "давайте быстро сделаем свой Kubernetes". Звучит бодро и по сути бессмысленно.
Я сел писать. Написал много кода, который вообще не должен был писать. А затем превратил этот производственный травматизм в статью на Хабре: https://habr.com/ru/articles/1091582/
Если у вас в компании кто-то прямо сейчас предлагает "просто завернуть LLM в цикл и добавить tools" — перешлите ему статью. Желательно до оценки сроков.
Для тех, кто может умеет в английский, есть ещё доклад на YouTube.
Мне очень нужна ваша помощь с разгоном статьи и видоса. Поставьте лайк, добавьте в закладки, напишите комментарий, утащите ссылку в рабочий чат и перешлите тому самому архитектору.
Помогите докладу не умереть в первые сутки.
Спасём хотя бы одну команду от собственного agent loop.
Это новый вариант фразы "давайте быстро сделаем свой Kubernetes". Звучит бодро и по сути бессмысленно.
Я сел писать. Написал много кода, который вообще не должен был писать. А затем превратил этот производственный травматизм в статью на Хабре: https://habr.com/ru/articles/1091582/
Если у вас в компании кто-то прямо сейчас предлагает "просто завернуть LLM в цикл и добавить tools" — перешлите ему статью. Желательно до оценки сроков.
Для тех, кто может умеет в английский, есть ещё доклад на YouTube.
Мне очень нужна ваша помощь с разгоном статьи и видоса. Поставьте лайк, добавьте в закладки, напишите комментарий, утащите ссылку в рабочий чат и перешлите тому самому архитектору.
Помогите докладу не умереть в первые сутки.
Спасём хотя бы одну команду от собственного agent loop.
🔥16👍6
Записал вам пару шортсов о проблеме агентной памяти и заходах на решение
• https://www.youtube.com/shorts/MxlIhniPxHw про https://arxiv.org/abs/2609.24259
• https://www.youtube.com/shorts/roGmekkAszo про https://arxiv.org/abs/2609.32521
найс?
• https://www.youtube.com/shorts/MxlIhniPxHw про https://arxiv.org/abs/2609.24259
• https://www.youtube.com/shorts/roGmekkAszo про https://arxiv.org/abs/2609.32521
найс?
Как обновить кластера kubernetes?
Всего три простых шага, записывайте:
1. Уничтожаем старый ДЦ беспилотником
2. Разворачиваем новые кластера
3. Разворачиваем сервисы
Всего три простых шага, записывайте:
1. Уничтожаем старый ДЦ беспилотником
2. Разворачиваем новые кластера
3. Разворачиваем сервисы
🤣27
Тут, кстати, интересная статья вышла с критикой Spec Driven Development
https://habr.com/ru/articles/1092802/
И я поддерживаю автора, что
• LLM — не компилятор
• Ваши буквы в спеках для ИИ — не единственный источник истины, и не должны им быть. ИИ смотрит на конечный код и вместо развития инструментов написания спек надо развивать инструменты контроля конечного результата
• Спеки — это спекуляция инженеров из вселенной "дайте нам исчерпывающие требования, чтобы мы могли создать идеальную Систему", само желание описать всё буквами и проконтролировать эти буквы — это профдеформация
https://habr.com/ru/articles/1092802/
И я поддерживаю автора, что
• LLM — не компилятор
• Ваши буквы в спеках для ИИ — не единственный источник истины, и не должны им быть. ИИ смотрит на конечный код и вместо развития инструментов написания спек надо развивать инструменты контроля конечного результата
• Спеки — это спекуляция инженеров из вселенной "дайте нам исчерпывающие требования, чтобы мы могли создать идеальную Систему", само желание описать всё буквами и проконтролировать эти буквы — это профдеформация
Хабр
Поэзия агентной разработки или как теперь писать код
Я к вам пишу — чего же боле? Агент все может написать. Но за ошибки поневоле Придется вам же отвечать. (Письмо инженера Татьяны к вайбкодеру Евгению) Как писать код...
👍9🔥5🤔2
На youtube shorts показывает неплохое вовлечение
https://www.youtube.com/shorts/na8SC2SNtgo
Не ну а в самом деле, сделать фичу не проблема — вопрос КАКУЮ реально нужно сделать.
https://www.youtube.com/shorts/na8SC2SNtgo
Не ну а в самом деле, сделать фичу не проблема — вопрос КАКУЮ реально нужно сделать.
👍4
Появилась статья названием, будто завтра агент самостоятельно перепишет себя и уйдёт из компании: Harness²: Recursive Agent Harnessing for an Open World.
За громким recursive self-improvement скрывается вполне здравая автоматизация. Берём готовый Codex или OpenCode, запускаем на задаче, а потом другие агенты переписывают ему AGENTS.md, skills, scripts и hooks, повторяют запуск и сохраняют удачную "заточку" для следующих работ такого типа.
То есть модель и ядро агента конечно никто не переписывает. Мы просто автоматизировали работу инженера, который после третьего факапа дописывает в инструкцию:
"Перед сдачей, сука, открой созданный файл и проверь, что он вообще открывается".
Теперь один improvement step - это уже четыре исполнительских прогона плюс отдельные editor, composer и reflector sessions. А при k=5 — двадцать (!!!!!) прогонов задачи.
Радостно видеть, что в индустрии появляется всё больше научно обоснованных способов сжечь ещё больше токенов. Не уверен, как к этому относиться.
Сорцы для желающих автоматизировать автоматизацию
За громким recursive self-improvement скрывается вполне здравая автоматизация. Берём готовый Codex или OpenCode, запускаем на задаче, а потом другие агенты переписывают ему AGENTS.md, skills, scripts и hooks, повторяют запуск и сохраняют удачную "заточку" для следующих работ такого типа.
То есть модель и ядро агента конечно никто не переписывает. Мы просто автоматизировали работу инженера, который после третьего факапа дописывает в инструкцию:
"Перед сдачей, сука, открой созданный файл и проверь, что он вообще открывается".
Теперь один improvement step - это уже четыре исполнительских прогона плюс отдельные editor, composer и reflector sessions. А при k=5 — двадцать (!!!!!) прогонов задачи.
Радостно видеть, что в индустрии появляется всё больше научно обоснованных способов сжечь ещё больше токенов. Не уверен, как к этому относиться.
Сорцы для желающих автоматизировать автоматизацию
🔥9