Claude code для этого теперь хватает auto mode и заклинания в промпте don't charge the code yet. А забить контекст в 1M токенов надо еще постараться. Он иногда сам переключает свой режим в planning и обратно. Я думаю, что фича полезная. Просто со стороны UX она видимо стала выглядеть как рудемент реализации, а не пользовательская ценность. О чём в общем-то и статья.
Классное замечание, я почему-то не думал об этом в таком ключе. Наверное потому, что в "Research & development" нет слова "планирование" и у меня оно ассоциировалось с первым.
В ходе ресерча агент предлагает гипотезы с различными допущениями. Например - использовать функцию из фреймворка. Крутой же план. Но понять, что это не галлюцинация и у такого решения нет каких-то подводных камней или конфликтов с текущей реализацией можно лишь выполнив код.
Результаты ресерча получаются чище, если во время написания спецификаций агент может создавать и запускать тестовые программы, вносить какие-то временные правки в код проекта, а потом откатывать назад. Создавать PR, чтобы пошарить промежуточные результаты с другими членами команды.
Получается, что разница между планированием и разработкой лежит где-то на уровне семантики - как мы ставим цели и оцениваем результаты. В плане механики отличий практически нет (разве что не деплоить в прод).
Режим read-only плохо вяжется с этапом планирования. Здесь тоже нужно писать спецификации, рисовать презентации, создавать PoC для проверки гипотез и т.п.
Как минимум у OpenJDK нет коммерческой поддержки и SLA в отношении фиксов. Это не является проблемой для нищих энтузиастов, но энтерпрайзы с их масштабами совсем другая история. Например, увеличение производительности на 2% может сэкономить им миллионы на ровном месте, а каждый день задержки со стороны вендора это прямые потери.
ИИ здорово избавляет от рутины. Нужно что-то поменять в интерфейсе, CI или еще какой-то типовой ерунде, сгенерировать тесты или раскопать причину ошибки - проще пнуть ИИ и дальше заниматься своей наукой. Хотя и здесь он помогает копаться в источниках и проверять гипотезы.
если топология является параметром алгоритма, то она должна оставаться доступной во время выполнения, а не исчезать внутри однажды скомпилированной схемы.
В традиционном SDLC используются задачи в таск менеджере (типа Jira). Это тоже позволяет менять топологию в процессе работы, без жесткой привязки к заранее выбранной топологии - вы просто по ситуации создаете подзадачу и назначаете ее на нужного специалиста. При необходимости ее можно связать с предыдущими задачами, расшарив контекст. Либо создать как отдельную, из которой впоследствии сформируется какой-то свой подграф.
Если смотреть на корневые задачи и их детей в ретроспективе, мы тоже получим лес топологий. Для чего вам rustworkx? :)
Основная проблема это поиск проблем, которые бы эффективно решались с помощью LLM - те, что решаются уже как правило оказываются решенными. Чем дальше, тем будет только сложнее.
Как я понял там что-то типа фреймворка, где можно в папках создавать референсы на типовые скрипты в разных комбинациях, собирая нужный функционал. То есть речь шла про использование. В версии на питоне как будто проглядели ключевые абстракции, поэтому она получилась ещё более запутаной. Но могу ошибаться, сильно не вчитывался.
Может стробоскопический эффект?
Claude code для этого теперь хватает auto mode и заклинания в промпте don't charge the code yet. А забить контекст в 1M токенов надо еще постараться. Он иногда сам переключает свой режим в planning и обратно. Я думаю, что фича полезная. Просто со стороны UX она видимо стала выглядеть как рудемент реализации, а не пользовательская ценность. О чём в общем-то и статья.
Классное замечание, я почему-то не думал об этом в таком ключе. Наверное потому, что в "Research & development" нет слова "планирование" и у меня оно ассоциировалось с первым.
В ходе ресерча агент предлагает гипотезы с различными допущениями. Например - использовать функцию из фреймворка. Крутой же план. Но понять, что это не галлюцинация и у такого решения нет каких-то подводных камней или конфликтов с текущей реализацией можно лишь выполнив код.
Результаты ресерча получаются чище, если во время написания спецификаций агент может создавать и запускать тестовые программы, вносить какие-то временные правки в код проекта, а потом откатывать назад. Создавать PR, чтобы пошарить промежуточные результаты с другими членами команды.
Получается, что разница между планированием и разработкой лежит где-то на уровне семантики - как мы ставим цели и оцениваем результаты. В плане механики отличий практически нет (разве что не деплоить в прод).
Вот мы сейчас с вами смотрим на одно и тоже сообщение или на разные?
Стрелочка вниз красное, вверх - зелёное. Вы чувствуете это и понимаете физический смысл их связи с материальным? А ведь ещё ни кто ни чего не нажал.
Режим read-only плохо вяжется с этапом планирования. Здесь тоже нужно писать спецификации, рисовать презентации, создавать PoC для проверки гипотез и т.п.
Она была убеждёна
Как минимум у OpenJDK нет коммерческой поддержки и SLA в отношении фиксов. Это не является проблемой для нищих энтузиастов, но энтерпрайзы с их масштабами совсем другая история. Например, увеличение производительности на 2% может сэкономить им миллионы на ровном месте, а каждый день задержки со стороны вендора это прямые потери.
Если воспринимать Mac Mini как машинку для офиса, то невелика беда. Подожду M7, там будет видно.
Проблема в том, как встроить в быт. Кто смог решить, тот счастлив.
Шикарные бесконечности, чего тут не понять.
Что если визуализировать не сами вектора, а их разность?
Мне показалось, что в статье речь идёт о милливатах * ч . Это примерно как одна батарейка ААА. ПЛ вряд-ли такое устроит.
ИИ здорово избавляет от рутины. Нужно что-то поменять в интерфейсе, CI или еще какой-то типовой ерунде, сгенерировать тесты или раскопать причину ошибки - проще пнуть ИИ и дальше заниматься своей наукой. Хотя и здесь он помогает копаться в источниках и проверять гипотезы.
В традиционном SDLC используются задачи в таск менеджере (типа Jira). Это тоже позволяет менять топологию в процессе работы, без жесткой привязки к заранее выбранной топологии - вы просто по ситуации создаете подзадачу и назначаете ее на нужного специалиста. При необходимости ее можно связать с предыдущими задачами, расшарив контекст. Либо создать как отдельную, из которой впоследствии сформируется какой-то свой подграф.
Если смотреть на корневые задачи и их детей в ретроспективе, мы тоже получим лес топологий. Для чего вам rustworkx? :)
GitNexus например или CodeGraph. Хотя в последнем вроде только BM25.
Основная проблема это поиск проблем, которые бы эффективно решались с помощью LLM - те, что решаются уже как правило оказываются решенными. Чем дальше, тем будет только сложнее.
С этого вопросы только начинаются
Как я понял там что-то типа фреймворка, где можно в папках создавать референсы на типовые скрипты в разных комбинациях, собирая нужный функционал. То есть речь шла про использование. В версии на питоне как будто проглядели ключевые абстракции, поэтому она получилась ещё более запутаной. Но могу ошибаться, сильно не вчитывался.