В июле Amazon Web Services запустила Kiro, его ответ на Windsurf и Cursor, но с акцентом на написание спецификаций по подсказкам. Тем не менее, я обнаружил, что доступ к нему был ограничен после того, как прилив разработчиков пошел, чтобы проверить его. Я вышел из списка ожидания только несколько недель назад, так что пришло время погрузиться.
После входа через Google вы должны получить этот экран в приложении Kiro:
Так что введите свой код, и вы должны быть в.
По -видимому, существует как минимум шесть основных продуктов IDE на основе визуальных кодов; Я знаю о курсоре и Виндсурфе. А теперь Киро.
Киро находится на вашем пути, чтобы вы могли запустить его из оболочки. Он открывается, выглядящий (неудивительно), похожий на визуальный код:
Как видите, он настроен на Claude Sonnet 4. Я собираюсь игнорировать опцию «Vibe» и переключиться прямо на путь дизайна «спецификации».
Что такое разработка спецификации?
Рабочий процесс, управляемый спецификациями Киро, разбивает развитие на три отдельных этапа: Создание пользовательских историй с подробными критериями принятияСоздание технического дизайна, и разбить работу на последовательность отслеживаемые задачи реализацииПолем
Эти артефакты в идеале должны быть композиционными документами с функциональными вариантами использования бизнеса и являются первыми объектами в мире Киро. Очевидно, что это гораздо более формальный подход, чем просто играть в покерные кости с большой языковой моделью. Большинство команд, которые следуют за Agile, не должны иметь никаких проблем с этим предлагаемым процессом, даже если ваш фактический рабочий процесс варьируется.
Я проверю Kiro на том же проекте Rails, на котором я недавно проверил несколько других агентских кодирующих продуктов. Это мое простое приложение для разработки игры MVC, которое помогает мне разрабатывать разговоры.
Атмосфера для спецификации
После загрузки моей кодовой базы в папке я могу начать Киро, описывая проект, над которым я хочу, чтобы он работал. В этом случае мне нужна отдельная утилита, которая ссылается только на одну существующую модель в моей системе:
Для моего проекта я хочу, чтобы пользователь имел возможность выполнять операции CRUD (создавать, читать, обновить, удалять) на мысль в течение дня, который является лишь некоторым текстом и изображением, связанным с существующим голосом символов.
Призрак возвращается после просмотра проекта и изолированного одной связанной модели:
Давайте посмотрим на первый документ, требования.md:
Это хорошее введение в обычные операции CRUD. Он предполагал, что мысли вдохновляют, и это частично верно в контексте игры. Он также понимает, что он должен следовать конвенции, как и все приложения Rails.
Давайте прокручим вниз до первой истории пользователя:
Роль «администратор» не совсем прав, но соответствующее значение здесь — «может создать контент». Киро ловит критерии «голосовой ассоциации», что является жизненно важной связью с существующей моделью голоса MVC. Он также замечает, что требуется текстовая запись, а изображение — нет. Это правильно — писатель может не иметь доступа к изображению при создании текста.
Всего есть шесть наборов требований/принятия, охватывающих другие задачи и представления CRUD.
Последний сталкивается с роли разработчика, поэтому я знаю, что он будет правильно использовать рельсы:
Конечная точка JSON важна, так как именно так я буду перемещать в результате данные в основную игру. Короче говоря, это покрыло все базы — в основном без какого -либо вмешательства.
Фаза дизайна
Когда мы закончим, нас приглашают двигаться дальше.
Теперь Киро смотрит на контроллер и рассматривает код других моделей MVC, поэтому он знает, как продолжить. Поскольку мой проект является приложением Rails, конвенции уже сильны:
С гибкой точки зрения, это обычно было бы знание домена разработчика, но это написано в терминах, которые архитектор поймет. Таким образом, он находится между тем, что я бы назвал «пользовательской историей» и «задачей». Мне нравится тот факт, что он заметил стиль начальной загрузки в виде.
Есть около 170 линий дизайна, поэтому я покажу только еще один раздел. Он снова захватывает отношения между голосом в атрибутах и моими существующими моделями, наряду с автоматическими вещами, которые можно получить с Activerecord:
Включены тесты, но, поскольку это развивающий инструмент, я попрошу, чтобы тесты были удалены из дизайна, прежде чем мы добьемся задач:
Принимая вещи на задание
Теперь мы готовы перейти на реализацию:
Список задач записан как для LLM, так и для разработчика:
Тем не менее, все задачи выглядят правильно — как вы видите, они подключаются к требованиям. Особая проблема относится к задачам, которые влияют на существующие модели, как в третьем задаче; Но он просто хочет установить дополнительные отношения, которые должны быть лишь одной строкой в файле модели Voice.rb.
Есть мало кнопок «начала задачи», поэтому ясно, что они могут быть использованы командой, если они хотели бы выполнить сами задачи. Некоторые из испытательных задач чувствуют, как будто они немного больше для людей:
Это подчеркивает важный момент, однако. Ожидает ли Киро, которую человеческая команда будет работать над этими задачами, или ожидает, что пользователь будет опираться на LLM для производства кода?
На данный момент дизайн наклоняется к последнему, что является ожиданием рынка. Но это отмечает, как бы первое сработало.
Завершить
Я не совсем уверен, для чего этот этап действительно, но мне рекомендуется пойти и начать задачи последовательно.
Я не буду слишком глубоко выйти в результат выполнения задач, так как мы здесь, чтобы посмотреть на характеристики — мы знаем, что LLMS может легко обрабатывать модели Rails достаточно легко. Но давайте пройдемся через один. Первая задача начинается с файла миграции:
Поскольку это Rails, он имеет определенный способ создания файла миграции (описание мира базы данных модели), поэтому я могу посмотреть на команду, которая слишком длинная для предоставленной маленькой коробки:
Рельсы генерируют миграцию CreateThotsForTHEDAY Текст: Text Voice_ID: Integer Image_id: String
Технически, Voice_id должен быть ссылкой, даже если это целое число. Но я приму команду. Как и в наши дни, LLM рассматривает то, что он сделал, и улучшает это:
Полученная миграция все еще не совсем упоминает ссылку напрямую, но теперь мы вступаем в обычный мир аргументов реализации со своим компаньоном LLM. Это очень хорошее время, чтобы поклониться:
Класс CreateThotsForTheday & lt; Activerecord :: миграция[8.0]
def изменить create_table: mess_for_the_day do | t | T.Text: Text, Null: False T.Integer: Voice_id T.String: Image_id T.TimestAmps End add_index: mends_for_the_day ,: voice_id add_foreign_key: mends_for_the_day ,: voices end 123456789101121314 CreateTheTheTHESTHESTHERTHEDAY & lt; Activerecord :: миграция[8.0] def изменить create_table: mess_for_the_day do | t | t.text: text, null: false t.integer: voice_id t.string: image_id t.timestamps end add_index: mensid_for_the_day ,: ocoved_id add_foreign_key: mends_for_the_day,: voices endendend
Заключение
Kiro нацелен на команды разработчиков, которые могут использовать артефакты для утверждения или изменения дизайнов вне инструмента. Это другой подход, чем «кодирование Vibe», который остается запертым в окружающей среде.
Я думаю, что рабочий процесс может быть упрощен. На данный момент я могу изменить существующее требование, и все дерево будет обновлять. Я боюсь, что петли зависимости, вызванные крючками пользователей (которые я не покрывал), могут выйти из -под контроля. Или, точнее, это может быть хрупким под стрессом. Но это первые дни.
На данный момент не хватает пользовательского интерфейса «коренастости» — есть много текста, меньше иконографии и содержащая графику. Первоначально это правильно, потому что общие документы отметки являются произведенной «валютой».
Поскольку они посягают на рабочий процесс команды, обязательно будет гораздо больше работы пользователя, необходимой для того, чтобы увидеть, какие команды действительно нужно здесь, и что они примут на борт. Я чувствую, что обслуживание артефактов в команде нуждается в отдельном инструменте.
Но в целом, я думаю, что подход, показанный Киро, силен. AWS следует захвалить за поддержку этого амбициозного продукта для запуска. У этого определенно есть гораздо больше, чем призрак шанса.
Trending Stories youtube.com/thenewstack Tech движется быстро, не пропустите эпизод. Подпишитесь на наш канал YouTube, чтобы транслировать все наши подкасты, интервью, демонстрации и многое другое. Группа подпишитесь с эскизом. Дэвид был лондонским профессиональным разработчиком программного обеспечения в Oracle Corp. и British Telecom, а также консультантом, помогающим командам работать более гибким образом. Он написал книгу по дизайну пользовательского интерфейса и с тех пор пишет технические статьи …. Подробнее от Дэвида Истмана
