Нет повести печальнее на свете, чем попытка помирить апологетов вайбкодинга (программирование с помощью искусственного интеллекта) и настоящих разработчиков. Причем, на самом-то деле, дружить они очень даже хотят и всячески друг к другу стараются притираться.
Получается, впрочем, плохо, примерно как секс первокурсников: все пыхтят, смущаются, а вот уже и мама стучится в дверь. Ну или в нашем случае, начальник, который напоминает, что неплохо бы заняться реальными рабочими задачами, а не этим вашим непотребством – то есть вайбкодингом.
Однако что у первокурсников гормоны хлещут из ушей, что программисты и LLM-энтузиасты фонтанируют идеями, как состыковать эти вселенные. Так что варианты их примирения постоянно изобретаются.
Даже ваша покорная слуга на одном из вебинаров попыталась предложить «концепцию спирали»: когда мы сначала разрабатываем продукт целиком в минимальном виде с помощью вайбкодинга, а затем путем многочисленных итераций дорабатываем его «по спирали» (этакий ИИ-Agile).
А есть методология SPARC, которая мне очень понравилась, и мне захотелось поделиться ей с вами.
Методологию SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) создал Рувен Коэн (Reuven Cohen). Это что-то вроде распорядка действий в ходе разработки ПО, когда вы привлекаете ИИ-инструменты.
Вот ее этапы:
1️⃣ Specification (ТЗ): сначала думай, потом делай
Чётко описываем, что именно нужно. Все требования, кейсы, ошибки, сценарии. В этом случае я пока что НЕ СОВЕТУЮ прибегать к ИИ, сначала продумайте всё сами.
Вы не переживайте, мы туда еще сбегаем, но вот именно этот этап сначала должен уложиться в вашей голове, и вы должны САМИ ДЛЯ СЕБЯ сначала понять, как будет выглядеть приложение.
В противном случае, если вы сразу побежите в ИИ-шку, она покорно со всем согласится и начнет подтверждать все ваш галлюцинации, от которых вы сами бы избавились по трезвом размышлении спустя 1-2 часа.
2️⃣ Pseudocode (псевдокод): пишем план, как в школе
Не код, а простая логика: какие функции, что куда идёт, какие данные бегают по системе.
Вы удивитесь, насколько часто уже на этом этапе видно, что идея не взлетит — и пускай!
Тут мы все еще думаем сами. Да не волнуйтесь вы, придём мы к ИИ-шке, придём!
3️⃣ Architecture (архитектура): строим карту
Как сервисы общаются? Где база? Где кэш? Это как план ремонта: лучше согласовать до того, как уже всё заказано и стены покрашены.
Вот только на этом этапе уже можно прибегать к специализированным инструментам. Я рекомендую, например, Codeguide.
4️⃣ Refinement (доработка)
Тестируем ➡️ делаем минимальную реализацию (в том же Replit, Claude, Cursor и пр.) ➡️ улучшаем.
Маленькими шагами!
Не надо пытаться скормить в Cursor весь плод вашего воспаленного воображения! Пожалейте ИИ-агента, приносите ему задачи по чуть-чуть.
Помним, это наш персональный стажер. Он схватывает на лету, но знаний у него порой не так много, как хотелось бы, плюс он может забыть очевидные вещи.
5️⃣ Completion (завершение): доводим до ума
Интеграция, безопасность, нагрузочные тесты, чтобы сервис не просто работал, а был готов к настоящей жизни.
*️⃣*️⃣*️⃣
Автор стратегии уверяет, что с таким подходом ИИ-разработка гораздо стабильнее.
Так что, возможно, мир всё-таки увидит этот долгожданный брак по любви между вайбкодерами и разработчиками.
Нужно лишь немного дисциплины и капельку SPARC-методологии в бокал вина перед встречей.
@gruboprostiite
Получается, впрочем, плохо, примерно как секс первокурсников: все пыхтят, смущаются, а вот уже и мама стучится в дверь. Ну или в нашем случае, начальник, который напоминает, что неплохо бы заняться реальными рабочими задачами, а не этим вашим непотребством – то есть вайбкодингом.
Однако что у первокурсников гормоны хлещут из ушей, что программисты и LLM-энтузиасты фонтанируют идеями, как состыковать эти вселенные. Так что варианты их примирения постоянно изобретаются.
Даже ваша покорная слуга на одном из вебинаров попыталась предложить «концепцию спирали»: когда мы сначала разрабатываем продукт целиком в минимальном виде с помощью вайбкодинга, а затем путем многочисленных итераций дорабатываем его «по спирали» (этакий ИИ-Agile).
А есть методология SPARC, которая мне очень понравилась, и мне захотелось поделиться ей с вами.
Методологию SPARC (Specification, Pseudocode, Architecture, Refinement, Completion) создал Рувен Коэн (Reuven Cohen). Это что-то вроде распорядка действий в ходе разработки ПО, когда вы привлекаете ИИ-инструменты.
Вот ее этапы:
1️⃣ Specification (ТЗ): сначала думай, потом делай
Чётко описываем, что именно нужно. Все требования, кейсы, ошибки, сценарии. В этом случае я пока что НЕ СОВЕТУЮ прибегать к ИИ, сначала продумайте всё сами.
Вы не переживайте, мы туда еще сбегаем, но вот именно этот этап сначала должен уложиться в вашей голове, и вы должны САМИ ДЛЯ СЕБЯ сначала понять, как будет выглядеть приложение.
В противном случае, если вы сразу побежите в ИИ-шку, она покорно со всем согласится и начнет подтверждать все ваш галлюцинации, от которых вы сами бы избавились по трезвом размышлении спустя 1-2 часа.
2️⃣ Pseudocode (псевдокод): пишем план, как в школе
Не код, а простая логика: какие функции, что куда идёт, какие данные бегают по системе.
Вы удивитесь, насколько часто уже на этом этапе видно, что идея не взлетит — и пускай!
Тут мы все еще думаем сами. Да не волнуйтесь вы, придём мы к ИИ-шке, придём!
3️⃣ Architecture (архитектура): строим карту
Как сервисы общаются? Где база? Где кэш? Это как план ремонта: лучше согласовать до того, как уже всё заказано и стены покрашены.
Вот только на этом этапе уже можно прибегать к специализированным инструментам. Я рекомендую, например, Codeguide.
4️⃣ Refinement (доработка)
Тестируем ➡️ делаем минимальную реализацию (в том же Replit, Claude, Cursor и пр.) ➡️ улучшаем.
Маленькими шагами!
Не надо пытаться скормить в Cursor весь плод вашего воспаленного воображения! Пожалейте ИИ-агента, приносите ему задачи по чуть-чуть.
Помним, это наш персональный стажер. Он схватывает на лету, но знаний у него порой не так много, как хотелось бы, плюс он может забыть очевидные вещи.
5️⃣ Completion (завершение): доводим до ума
Интеграция, безопасность, нагрузочные тесты, чтобы сервис не просто работал, а был готов к настоящей жизни.
*️⃣*️⃣*️⃣
Автор стратегии уверяет, что с таким подходом ИИ-разработка гораздо стабильнее.
Так что, возможно, мир всё-таки увидит этот долгожданный брак по любви между вайбкодерами и разработчиками.
Нужно лишь немного дисциплины и капельку SPARC-методологии в бокал вина перед встречей.
@gruboprostiite
