С чего начать и как учиться

С чего начать работу с кодом с помощью AI?

Под капотом любой AI-ассистент для кода — это языковая модель в агентной петле: она читает файлы проекта, предлагает правки, запускает команды, читает вывод и повторяет цикл. Отличаются в основном форм-факторы, и выбирать стоит по тому, где вы уже работаете:

Автодополнение в редакторе — GitHub Copilot: подсказки серым текстом, принимаются по Tab. Самый низкий порог входа для тех, кто живёт в VS Code или JetBrains.
AI-native IDE — Cursor (форк VS Code): чат по всему проекту, индексирование кодовой базы и режим правок сразу по многим файлам.
Терминальный агент — Claude Code: задачу описываете словами, агент сам читает репозиторий, правит файлы, гоняет тесты и делает коммиты.
Git-native CLI — Aider: каждая правка оформляется отдельным коммитом, поэтому любую легко откатить через git revert.

Практический старт одинаков для всех: возьмите одну маленькую реальную задачу (не учебную), держите всё под контролем — ревью каждой правки, прогон тестов, работа через git — и наращивайте объём по мере доверия к инструменту. У Cursor, Claude Code и Aider есть официальные quickstart-руководства, с них и стоит начать.

Что пойдёт не так без трезвых ожиданий. Рандомизированный контролируемый эксперимент METR (2025) — важное отрезвление: 16 опытных разработчиков на своих же зрелых репозиториях (в среднем 5 лет опыта в проекте) с инструментами уровня Cursor Pro и Claude 3.5/3.7 Sonnet выполняли задачи на 19% дольше с ИИ, чем без него. При этом до начала они ждали ускорения на 24%, а после — были уверены, что ИИ ускорил их на 20%. Разрыв между ощущением и фактом — главный урок. Второй факт оттуда же: участники принимали без правок меньше 44% сгенерированного кода.

Вывод для старта: ИИ — не волшебная кнопка, и на большом знакомом коде он может замедлять. Максимальную пользу он даёт на другом: незнакомый фреймворк, прототип с нуля, рутинный бойлерплейт, разовые скрипты. Начинайте именно с таких задач, а на сложном легаси включайте скепсис и перепроверяйте каждый шаг.

Ссылки

Как научиться вайбкодингу, если ещё не умеешь программировать, а идей много?

Сначала разведём понятия. Термин вайбкодинг ввёл Андрей Карпаты в феврале 2025 года: вы отдаётесь потоку, описываете желаемое словами и почти не смотрите в сам код. Саймон Уиллисон уточняет важную границу (разбор): если вы прочитали, поняли и протестировали каждую строку — это уже не вайбкодинг, а использование модели как ассистента. Первое эмпирическое исследование практики (работа Sarkar и Drosos) описывает вайбкодинг как итеративные циклы достижения цели через диалог с моделью. То есть суть не в магии, а в сдвиге: от детерминированной инструкции, где код пишете вы, к вероятностному выводу, где модель угадывает намерение.

Как учиться — по шагам:

Возьмите одну идею и маленький безопасный проект. Идей много — это ресурс; выберите ту, где ошибка ничего не стоит (личный инструмент, прототип на выходные).
Учитесь формулировать намерение. Ценность даёт не размытое пожелание, а внятная спека словами: что на входе, что на выходе, какие ограничения. Плохая формулировка — плохой результат.
Работайте циклами. Описали — запустили — увидели ошибку — вернули её модели — повторили. Инструменты вроде Lovable, Bolt, Replit или Cursor берут на себя запуск, так что можно начать без настройки окружения.
Параллельно учите базу. Не обязательно становиться инженером, но минимум — как читать сообщение об ошибке, что такое переменная, функция, git-коммит — резко повышает шанс довести идею до рабочего состояния.

Что пойдёт не так — и это главное для того, кто не программирует. Вайбкод-приложения небезопасны по умолчанию. Бенчмарк SUSVIBES (2025) на 200 реальных задачах: связка SWE-Agent с Claude 4 Sonnet даёт около 61% функционально корректных решений, но безопасны из них лишь около 10%. Причём общие подсказки про безопасность в промпте проблему не закрывают. Отдельное исследование безопасности вайбкод-приложений подтверждает системность: модели оптимизируют работоспособность и скорость, а защитные меры пропускают. Добавьте supply-chain-риск: code-генерирующие модели выдумывают имена несуществующих пакетов (галлюцинации пакетов) — в среднем от 5.2% у коммерческих моделей до 21.7% у open-weight; злоумышленник регистрирует такой выдуманный пакет с вредоносом (атака slopsquatting), а доверчивый пользователь его ставит.

Практический вывод: вайбкодинг отлично подходит для прототипов, личных инструментов и обучения, но всё, что касается денег, чужих данных или публичного доступа, обязано пройти ревью человека, тесты и проверку зависимостей. Если ревьюить некому — держите проект непубличным и без реальных данных.

Ссылки

AI-Driven Development и AI-First на живом примере

AI-First и AI-Driven Development — это не дописать строку, а перестроить сам процесс вокруг агента. Ключевая идея, противоположная вайбкодингу: не бросаться сразу в код, а сначала зафиксировать спецификацию, план и задачи и уже их отдавать агенту на исполнение. Самый наглядный готовый пример этого подхода — Spec-Driven Development и открытый инструмент GitHub Spec Kit. Процесс из четырёх фаз — Spec → Plan → Tasks → Implement — где каждая фаза рождает markdown-артефакт, который кормит следующую. Агент получает структурированный контекст, а не разовый промпт.

Как пощупать на практике за один вечер:

Установите Spec Kit и инициализируйте проект командой specify init под ваш агент (поддерживается более 30 интеграций — Copilot, Claude, Gemini, Cursor и другие).
Пройдите цикл на маленькой фиче: сначала опишите, что строите (spec), затем дайте агенту составить план и разбить его на задачи, и только потом — реализацию.
Сравните ощущения с чистым вайбкодингом на той же задаче: разница в предсказуемости результата видна сразу.

Альтернативный минимальный пример — quickstart Claude Code на реальном issue: описать задачу словами, дать агенту прочитать репозиторий, прогнать тесты и собрать коммит.

Что пойдёт не так. Без спеки агент склонен к перестраховке и отклонению от требований — на длинных задачах это выливается в лишние действия и сожжённые токены (подробный разбор — в категории про качество и надёжность). Spec-Driven снижает это, задавая явные рамки. Но помните про METR: даже структурированный подход на большом знакомом легаси может не ускорять, поэтому обкатывайте AI-First сначала на новых модулях, а не на критичном ядре.

Ссылки

Подключить AI к чему угодно: 1С, телефон, телевизор, холодильник

Вопросы участников:

Да вобоще понять, узнать новое, подключить к 1С, к телефону, к телевизору, к холодильнику.

Ключ к тому, чтобы подключить ИИ к чему угодно, — не отдельный интегратор под каждую железку, а один протокол. Anthropic в ноябре 2024 открыла Model Context Protocol (MCP) — стандарт, который в документации сравнивают с разъёмом USB-C для ИИ-приложений: вместо десятка кастомных интеграций один способ соединить модель с внешними системами. Архитектура — host (приложение с моделью) ↔ client ↔ server поверх JSON-RPC 2.0; сервер отдаёт модели инструменты (tools), данные (resources) и готовые промпты. Написали MCP-сервер для системы один раз — и к ней может ходить любой MCP-совместимый клиент.

Теперь по вашему списку устройств:

Телевизор, холодильник, лампы, розетки — через умный дом. Home Assistant с функцией Assist подключает разговорный агент (OpenAI, Google Gemini или локальный через Ollama) и даёт ему управлять теми устройствами, которые вы явно экспонировали. Всё можно держать локально на своём железе ради приватности. Бытовая техника заходит в Home Assistant через свои интеграции, а модель уже управляет ей голосом или текстом.
1С — через готовые коннекторы и MCP-серверы. Есть проекты, поднимающие MCP-сервер прямо в 1С:Предприятие (расширение конфигурации плюс Python-прокси), после чего к базе ходят Claude, Cursor и другие клиенты. Для более простых задач — чат-бот, анализ текста — существуют LLM-коннекторы с единым OpenAI-совместимым API.
Телефон — через MCP-клиентов и автоматизацию. На телефоне вы обычно выступаете клиентом MCP, а сервер крутится на вашей инфраструктуре (тот же Home Assistant или 1С).

Что пойдёт не так:

Безопасность интеграции. Авторы 1С-MCP прямо предупреждают: не публикуйте HTTP-сервис 1С без аутентификации ради удобства — иначе к базе получит доступ кто угодно. Используйте прокси с OAuth2, а не вшитые в открытую реквизиты.
Маленькие локальные модели ошибаются. Документация Home Assistant рекомендует экспонировать локальной модели меньше 25 сущностей и помнить, что небольшие модели путаются чаще крупных. Начинайте с узкого набора и расширяйте по мере уверенности.
MCP расширяет поверхность атаки. Как только модель получает инструменты, к ней применимы инъекции промпта через данные: недоверенный текст в базе или на устройстве может подтолкнуть агента к нежелательному действию. Давайте инструментам минимум прав и подтверждайте опасные операции вручную.