Это называется вайб-кодинг или AI driven development. Можно не читать, можно читать.
И чем больше автономности у агента, тем эффективнее процесс. Скажем программистам людям же тоже дают задачи, и бывает им доверяют настолько, что не проводят контроль каждой строки.
Я для гарантии качества вчитываюсь в Pull Request который мне делает AI, но в целом это не обязательно - можно задать ему вопросы или отправить другой ИИ не ревью и т.п. При этом что значит вчитываться, я вчитываюсь не очень глубоко, выборочно, я проверю структуру файлов и важные мне моменты, не вчитываюсь во все детали, потому что с 80% вероятностью там всё ок. То есть на ревью у меня уходит 5-10 минут если Pull Request простой и 20-30 минут, если он про какую-то сложную фичу или затрагивает архитектурные правки.
И так как я больше не пишу код вручную, мой фокус теперь на архитектуре, согласованности требований, сборе обратной связи от пользователей и т.п. У меня теперь больше времени просто даже customer development делать в одиночку.
В общем кодинг это не цель, это средство. Я всегда хотел достигать целей которые кодинг помогает реализовать, я никогда не был занят кодингом ради самого кодинга.
Это не исключает при этом, что у меня могут быть очень строгие стандарты к качеству кода и я потихонькую полирую его до совершенства, но теперь не своими руками, а задавая требования, в том числе требования по качеству кода AI агентам.
Новое всегда страшно, но я привык бросаться в неизвестность и испытывать это на себе, поэтому пока кому-то это страшно, я осваиваю новый навык.
Нет, не считаю. Безопасность можно и нужно тестировать. Это видимо была неудачная штука на тему "вражеского" ИИ.
Из того что ИИ пишет код, а не человек априори не следуют проблемы с безопасностью. Если стоит задача обеспечить безопасность, всегда можно сделать тестовый стенд, песочницу, где сам же ИИ направить на то, чтобы провести целый ряд атак против безопасности. Есть так же много статический чекеров на типичные уязвимости. Всегда есть способы обеспечить безопасность, если именно в этом потребность или требование. Методы мало чем будут отличаться с ИИ или без. Методики все те же самые, и исполнителем может быть не только человек, но конечно человек желателен для гарантии безопасности в критических решениях.
Никто не отменяет награды за найденные уязвимости, сертификацию и т.п., чтобы делать финальные гарантии по безопасности.
Если же речь о сохранности данных, то никогда не нужно отправлять ИИ править БД на проде, без строгого контроля, так как ИИ может не чувствовать ответственности. При этом если речь о сохранности локальных данных или системы - то желательно использовать локальную или удалённую виртуальную машину (песочницу) без доступа к интернету. А если есть доступ к интернету начинать тестировать с тестовых стендов, а не с боевого API.
Удобный интерфейс, это в виде бота на GitHub? С запуском через упоминание/assign/прикрпление тэга к задаче?
Помимо /solve команды у нас есть /hive команда в ней частично реализованы функции мониторинга, но мне пока не нравится эффективность такого подхода. Пока что на этапе тестирования текущего варианта, я считаю, достаточно, а дальше посмотрим как пойдёт. Для начала мне бы понять что для реальных пользователей является наиболее удобным форматом взаимодействия. Плюс есть ещё над чем работать чтобы улучшать стабильность и качество текущего решения.
Результат определяет не знание языка программирование, а упорство и труд. То есть если хватит терпения давать подробную обратную связь AI агенту, то может получиться, что совсем не обязательно читать код который он пишет. Ведь по началу будет большее значение иметь работает ли ПО как ожидается или нет.
Ну и задавая вопросы агенту про код можно фактически начать изучать программирование и при желании изучить его полностью. То есть это может снижать порог входа в программировании.
Однако моя изначальная цель - автоматизация автоматизации - то есть возможность программировать на любом языке, в том числе человеческом. И я считаю последние 6 месяцев я программирую только используя английский язык, ну просто потому, что сейчас мне нравится изучать этот язык. ИИ конечно понимает и русский тоже.
Пока что можно ставить в докере локально или у себя на сервере и использовать свою подписку на Claude MAX $200. Так как проект в общественном достоянии и полностью с открытым исходным кодом.
Либо можно прислать ссылку на issue на GitHub мне в личку тут или в Telegram (указано в профиле), в таком случае если issue мне понравится я запущу выполнение в моей поднятой инфраструктуре. Также можно пройти отбор и попасть в наш чат, где вы сможете запускать свои задачи самостоятельно через нашего Telegram бота.
На текущий момент проект в состоянии закрытого тестирования, поэтому пока как есть. Если я вдруг запишу видео, я об этом сообщу.
Я надеюсь с вашей помощью в тестировании мы сможем и локальные модели поддержать на том же уровне, что и Claude в ближайшем будущем, но пока Claude Opus + Sonnet это лучшее предложение по соотношению цена/качество.
Анализ нужен не всегда, и анализ может быть отдельной задачей и даже частью её как один из шагов. В целом на картинке анализ есть, и без анализа AI агент не может даже приступить к задаче, ведь ему нужно оглядеться, посмотреть что происходит и понять что ему делать, составить свой план и т.п.
Я также могу просто попросить провести анализ в issue, и как только он проведён в этом или отдельном Pull Request я могу попросить комментарием реализовать один из вариантов решений и т.п.
На текущий момент конечно же это Proof of Concept, и цель прежде всего дать возможность встроить похожую на программиста сущность в процесс разработки. Но универсальный алгоритм решения задач и проблем реализован на текущий момент не полностью. Если интересно можете посмотреть открытые issues (там можно обнаружить примерный roadmap разработки) или если хотите испытать эту систему в действии можете написать мне в личку.
Если говорить о том как я работаю то обычно это выглядит так: я ставлю задачу, и если считаю что она требует глубокого анализа то изначально задача ставится буквально так - провести анализ, а как только анализ проведён я могу либо в этом же Pull Request, либо уже в отдельном сделать само решение. Иногда бывает я ставлю задачу составить план реализации и по этому плану ставлю задачу создать все задачи с учётом зависимостей, чтобы у меня был полный план разработки с максимальным параллелизмом между задачами. Ведь одно из удобств системы в том, что можно запускать множество задач для решения одновременно.
То есть я ставлю задачи, если Pull Request нужно доработать я даю комментарии и отправляю агента дорабатывать. Для меня основное преимущество в том, что пока агент работает самостоятельно, а это обычно 15-35 минут рабочая сессия, он никак не отвлекает на себя моё внимание и я могу заниматься чем-то ещё. То есть у него достаточно времени чтобы провести свой анализ ситуации, провести эксперименты, и набросать черновик решения, иногда бывает что он справляется задачей с первого раза, иногда с 4-5 итераций обратной связи, в среднем за 2-3.
То есть я как инженер прихожу в Pull Request чтобы проверить а соответствуют ли предложенные правки требованиям заданным в задаче, соответствует ли код нужному мне уровню качества и т.п. Да, бывает я совершаю ошибки в постановке задачи, за это действительно приходится платить дополнительными комментариями к Pull Request, но так или иначе этот флоу позволяет завершить задачу до конца.
И как я уже говорил, это намного быстрее чем если ждать результата от программиста - часами или днями или что хуже студент может быть настолько занят учёбой что сделает задачу через несколько месяцев. А его ещё и обучать нужно было и даже мотивировать деньгами.
В целом я предпочитаю не оценивать, поэтому словами я обычно не поминаю. Меня интересуют только факты, и результат, и способы его достижения.
Так или иначе конечно чем меньше задача - тем больше шансов что с ней AI агент справится. Но сам анализ в моём понимании это тоже задача, планирование задач это тоже задача и т.п.
И лично я субъективно не вижу уязвимостей для промышленного решения, так как именно с промышленной разработкой Claude Code CLI + Claude Opus 4.5 на моём опыте и под моим управлением справлялся. А сам Hive Mind, буквально интегрируется с GitHub таким образом, чтобы в промышленный процесс разработки ПО встраиваться. И в сочетании с CI/CD настроенной для поддержки команды разработки из ИИ и людей - это работает буквально как часы или хорошо выстроенный промышленный процесс.
Если мы переживаем о безопасности - можно запустить в виртуальной машине. И проверять конечно же запуском, а как иначе проверять? :) И если ручной тест показывает что юнит тесты проверяют не то - значит нужно юнит тесты поправить и со всем этим Opus справляется, ему нужно только дать эту самую обратную связь о требованиях - как должно быть и как быть не должно. Тоже самое как с обычным программированием - написал код-черновик-гипотезу - запустил - проверил - понял что не то, понял почему и как не то - исправил - перезапустил.
Пока что я вижу что более 80% pull requests завершаются мержем, а не закрытием :) Как получилось, что для тебя наш бот-программист не сработал для меня пока загадка.
Вероятно с этим смогут справиться будущие модели, которые добавят на вход и на выход аудио модальность. Так или иначе для таких конкретных моментов можно использовать подход human in a loop, то есть настроить с машиной взаимодействие так, что единственное на что она будет отвлекать внимание человека, это на обратную связь по аудио файлам. С другой стороны в некоторых случаях, вероятно уже есть модели с аудио модальностью и можно это решить сочетая несколько нейросетей вместе, что само по себе тоже задача, которую вероятно AI агент мог бы решить, если бы у него возникли бы сложности подсказки от человека помогли бы.
Иногда читать может быть нужно, а иногда достаточно хорошо настроенного CI/CD, линтеров, тестов, чекеров безопасности и других инструментов. Чем больше автоматизации для проверки кода, тем меньше потребность его читать. А задачи от пользователей могут быть почти сразу быть направлены в разработку используя AI агентов.
Совсем не обязательно, у меня AI агент на нечётки и противоречивых требованиях вопросы задаёт. Но конечно если человек сам разбирается со своими противоречиями и определяет какое соотношение между крайностями дихотомий для него допустимо, то разработка идёт на порядки эффективнее.
Для ИИ нужен так же как и для людей хороший CI/CD который гарантирует что код читается и нужного качества. И самое критичное скажем для Claude Code CLI агента, это то, что если CI/CD требует чтобы каждый файл с кодом или документацией будет меньше 1500 строк, то у Claude Code CLI будет намного больше шансов прочитать его целиком, а следовательно полностью осознанно сделать правки. Плюс такое ограничение вынуждает агента разделять код на файлы. В общем все те лучшие практики программирования которые накапливали люди за это время на текущий момент применимы так же, и иногда даже критичнее для AI чем для людей.
Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию. Даже сегодня любой ИИ агент запросто способен разбить любое ТЗ на задачи, причём так, чтобы максимизировать параллелизм в разработке, то есть планировать задачи таким образом, чтобы множество других агентов или людей могли работать над задачами параллельно, не пересекаясь по функционалу, что минимизирует конфликты.
Таким образом благодаря этому алгоритму можно добиться того, что любое ограничение контекста больше не является проблемой. А учитывая с какой скоростью ИИ агенты закрывают задачи, сколько бы потом не было багов - это можно компенсировать добавлением тестов после каждого бага, чтобы он никогда не повторялся и в итоге система будет стремиться к полному покрытию тестами и легко может разрабатываться используя в том числе исключительно AI агентов.
Это называется вайб-кодинг или AI driven development. Можно не читать, можно читать.
И чем больше автономности у агента, тем эффективнее процесс. Скажем программистам людям же тоже дают задачи, и бывает им доверяют настолько, что не проводят контроль каждой строки.
Я для гарантии качества вчитываюсь в Pull Request который мне делает AI, но в целом это не обязательно - можно задать ему вопросы или отправить другой ИИ не ревью и т.п. При этом что значит вчитываться, я вчитываюсь не очень глубоко, выборочно, я проверю структуру файлов и важные мне моменты, не вчитываюсь во все детали, потому что с 80% вероятностью там всё ок. То есть на ревью у меня уходит 5-10 минут если Pull Request простой и 20-30 минут, если он про какую-то сложную фичу или затрагивает архитектурные правки.
И так как я больше не пишу код вручную, мой фокус теперь на архитектуре, согласованности требований, сборе обратной связи от пользователей и т.п. У меня теперь больше времени просто даже customer development делать в одиночку.
В общем кодинг это не цель, это средство. Я всегда хотел достигать целей которые кодинг помогает реализовать, я никогда не был занят кодингом ради самого кодинга.
Это не исключает при этом, что у меня могут быть очень строгие стандарты к качеству кода и я потихонькую полирую его до совершенства, но теперь не своими руками, а задавая требования, в том числе требования по качеству кода AI агентам.
Новое всегда страшно, но я привык бросаться в неизвестность и испытывать это на себе, поэтому пока кому-то это страшно, я осваиваю новый навык.
Там много нюансов, плюс кто-то это должен мониторить, то есть нужна модерация. Это точно не делается за 5 минут, даже с AI.
Нет, не считаю. Безопасность можно и нужно тестировать. Это видимо была неудачная штука на тему "вражеского" ИИ.
Из того что ИИ пишет код, а не человек априори не следуют проблемы с безопасностью. Если стоит задача обеспечить безопасность, всегда можно сделать тестовый стенд, песочницу, где сам же ИИ направить на то, чтобы провести целый ряд атак против безопасности. Есть так же много статический чекеров на типичные уязвимости. Всегда есть способы обеспечить безопасность, если именно в этом потребность или требование. Методы мало чем будут отличаться с ИИ или без. Методики все те же самые, и исполнителем может быть не только человек, но конечно человек желателен для гарантии безопасности в критических решениях.
Никто не отменяет награды за найденные уязвимости, сертификацию и т.п., чтобы делать финальные гарантии по безопасности.
Если же речь о сохранности данных, то никогда не нужно отправлять ИИ править БД на проде, без строгого контроля, так как ИИ может не чувствовать ответственности. При этом если речь о сохранности локальных данных или системы - то желательно использовать локальную или удалённую виртуальную машину (песочницу) без доступа к интернету. А если есть доступ к интернету начинать тестировать с тестовых стендов, а не с боевого API.
Удобный интерфейс, это в виде бота на GitHub? С запуском через упоминание/assign/прикрпление тэга к задаче?
Помимо /solve команды у нас есть /hive команда в ней частично реализованы функции мониторинга, но мне пока не нравится эффективность такого подхода. Пока что на этапе тестирования текущего варианта, я считаю, достаточно, а дальше посмотрим как пойдёт. Для начала мне бы понять что для реальных пользователей является наиболее удобным форматом взаимодействия. Плюс есть ещё над чем работать чтобы улучшать стабильность и качество текущего решения.
Результат определяет не знание языка программирование, а упорство и труд. То есть если хватит терпения давать подробную обратную связь AI агенту, то может получиться, что совсем не обязательно читать код который он пишет. Ведь по началу будет большее значение иметь работает ли ПО как ожидается или нет.
Ну и задавая вопросы агенту про код можно фактически начать изучать программирование и при желании изучить его полностью. То есть это может снижать порог входа в программировании.
Однако моя изначальная цель - автоматизация автоматизации - то есть возможность программировать на любом языке, в том числе человеческом. И я считаю последние 6 месяцев я программирую только используя английский язык, ну просто потому, что сейчас мне нравится изучать этот язык. ИИ конечно понимает и русский тоже.
Используйте тогда отечественный искусственный интеллект. НейроМакс лучшая нейросеть?
Пока что можно ставить в докере локально или у себя на сервере и использовать свою подписку на Claude MAX $200. Так как проект в общественном достоянии и полностью с открытым исходным кодом.
Инструкция по установке доступна тут: https://github.com/link-assistant/hive-mind
Либо можно прислать ссылку на issue на GitHub мне в личку тут или в Telegram (указано в профиле), в таком случае если issue мне понравится я запущу выполнение в моей поднятой инфраструктуре. Также можно пройти отбор и попасть в наш чат, где вы сможете запускать свои задачи самостоятельно через нашего Telegram бота.
На текущий момент проект в состоянии закрытого тестирования, поэтому пока как есть. Если я вдруг запишу видео, я об этом сообщу.
Я надеюсь с вашей помощью в тестировании мы сможем и локальные модели поддержать на том же уровне, что и Claude в ближайшем будущем, но пока Claude Opus + Sonnet это лучшее предложение по соотношению цена/качество.
Нет, в этом случае мы перейдём на бесплатные опенсорсные модели.
Анализ нужен не всегда, и анализ может быть отдельной задачей и даже частью её как один из шагов. В целом на картинке анализ есть, и без анализа AI агент не может даже приступить к задаче, ведь ему нужно оглядеться, посмотреть что происходит и понять что ему делать, составить свой план и т.п.
Я также могу просто попросить провести анализ в issue, и как только он проведён в этом или отдельном Pull Request я могу попросить комментарием реализовать один из вариантов решений и т.п.
На текущий момент конечно же это Proof of Concept, и цель прежде всего дать возможность встроить похожую на программиста сущность в процесс разработки. Но универсальный алгоритм решения задач и проблем реализован на текущий момент не полностью. Если интересно можете посмотреть открытые issues (там можно обнаружить примерный roadmap разработки) или если хотите испытать эту систему в действии можете написать мне в личку.
Если говорить о том как я работаю то обычно это выглядит так: я ставлю задачу, и если считаю что она требует глубокого анализа то изначально задача ставится буквально так - провести анализ, а как только анализ проведён я могу либо в этом же Pull Request, либо уже в отдельном сделать само решение. Иногда бывает я ставлю задачу составить план реализации и по этому плану ставлю задачу создать все задачи с учётом зависимостей, чтобы у меня был полный план разработки с максимальным параллелизмом между задачами. Ведь одно из удобств системы в том, что можно запускать множество задач для решения одновременно.
То есть я ставлю задачи, если Pull Request нужно доработать я даю комментарии и отправляю агента дорабатывать. Для меня основное преимущество в том, что пока агент работает самостоятельно, а это обычно 15-35 минут рабочая сессия, он никак не отвлекает на себя моё внимание и я могу заниматься чем-то ещё. То есть у него достаточно времени чтобы провести свой анализ ситуации, провести эксперименты, и набросать черновик решения, иногда бывает что он справляется задачей с первого раза, иногда с 4-5 итераций обратной связи, в среднем за 2-3.
То есть я как инженер прихожу в Pull Request чтобы проверить а соответствуют ли предложенные правки требованиям заданным в задаче, соответствует ли код нужному мне уровню качества и т.п. Да, бывает я совершаю ошибки в постановке задачи, за это действительно приходится платить дополнительными комментариями к Pull Request, но так или иначе этот флоу позволяет завершить задачу до конца.
И как я уже говорил, это намного быстрее чем если ждать результата от программиста - часами или днями или что хуже студент может быть настолько занят учёбой что сделает задачу через несколько месяцев. А его ещё и обучать нужно было и даже мотивировать деньгами.
В целом я предпочитаю не оценивать, поэтому словами я обычно не поминаю. Меня интересуют только факты, и результат, и способы его достижения.
Так или иначе конечно чем меньше задача - тем больше шансов что с ней AI агент справится. Но сам анализ в моём понимании это тоже задача, планирование задач это тоже задача и т.п.
И лично я субъективно не вижу уязвимостей для промышленного решения, так как именно с промышленной разработкой Claude Code CLI + Claude Opus 4.5 на моём опыте и под моим управлением справлялся. А сам Hive Mind, буквально интегрируется с GitHub таким образом, чтобы в промышленный процесс разработки ПО встраиваться. И в сочетании с CI/CD настроенной для поддержки команды разработки из ИИ и людей - это работает буквально как часы или хорошо выстроенный промышленный процесс.
Может, если ему помочь и направить :)
И комментарий о том, вот почему я не читаю комментарии
Если мы переживаем о безопасности - можно запустить в виртуальной машине. И проверять конечно же запуском, а как иначе проверять? :) И если ручной тест показывает что юнит тесты проверяют не то - значит нужно юнит тесты поправить и со всем этим Opus справляется, ему нужно только дать эту самую обратную связь о требованиях - как должно быть и как быть не должно. Тоже самое как с обычным программированием - написал код-черновик-гипотезу - запустил - проверил - понял что не то, понял почему и как не то - исправил - перезапустил.
Показывал в комментарии выше https://habr.com/ru/articles/984026/comments/#comment_29367614. Рассказать могу - могу ответить на вопросы.
А вообще бот-программист, которого я делаю с его же собственной помощью вот тут: https://github.com/link-assistant/hive-mind
Смотря у кого :)
Пока что я вижу что более 80% pull requests завершаются мержем, а не закрытием :) Как получилось, что для тебя наш бот-программист не сработал для меня пока загадка.
Показываю:
github.com/linksplatform
github.com/link-foundation
github.com/link-assistant
github.com/deep-foundation
github.com/deep-assistant
github.com/konard
Вероятно с этим смогут справиться будущие модели, которые добавят на вход и на выход аудио модальность. Так или иначе для таких конкретных моментов можно использовать подход human in a loop, то есть настроить с машиной взаимодействие так, что единственное на что она будет отвлекать внимание человека, это на обратную связь по аудио файлам. С другой стороны в некоторых случаях, вероятно уже есть модели с аудио модальностью и можно это решить сочетая несколько нейросетей вместе, что само по себе тоже задача, которую вероятно AI агент мог бы решить, если бы у него возникли бы сложности подсказки от человека помогли бы.
Иногда читать может быть нужно, а иногда достаточно хорошо настроенного CI/CD, линтеров, тестов, чекеров безопасности и других инструментов. Чем больше автоматизации для проверки кода, тем меньше потребность его читать. А задачи от пользователей могут быть почти сразу быть направлены в разработку используя AI агентов.
Совсем не обязательно, у меня AI агент на нечётки и противоречивых требованиях вопросы задаёт. Но конечно если человек сам разбирается со своими противоречиями и определяет какое соотношение между крайностями дихотомий для него допустимо, то разработка идёт на порядки эффективнее.
Для ИИ нужен так же как и для людей хороший CI/CD который гарантирует что код читается и нужного качества. И самое критичное скажем для Claude Code CLI агента, это то, что если CI/CD требует чтобы каждый файл с кодом или документацией будет меньше 1500 строк, то у Claude Code CLI будет намного больше шансов прочитать его целиком, а следовательно полностью осознанно сделать правки. Плюс такое ограничение вынуждает агента разделять код на файлы. В общем все те лучшие практики программирования которые накапливали люди за это время на текущий момент применимы так же, и иногда даже критичнее для AI чем для людей.
Есть универсальный алгоритм решения задач и проблем, любую задачу можно декомпозировать, это можно повторять рекурсивно, затем для каждой задачи можно написать её точное определение в виде тестов, когда для каждой микро задачи будет готово решение можно провести обратно - композицию. Даже сегодня любой ИИ агент запросто способен разбить любое ТЗ на задачи, причём так, чтобы максимизировать параллелизм в разработке, то есть планировать задачи таким образом, чтобы множество других агентов или людей могли работать над задачами параллельно, не пересекаясь по функционалу, что минимизирует конфликты.
Таким образом благодаря этому алгоритму можно добиться того, что любое ограничение контекста больше не является проблемой. А учитывая с какой скоростью ИИ агенты закрывают задачи, сколько бы потом не было багов - это можно компенсировать добавлением тестов после каждого бага, чтобы он никогда не повторялся и в итоге система будет стремиться к полному покрытию тестами и легко может разрабатываться используя в том числе исключительно AI агентов.