feat: add interview
This commit is contained in:
parent
2ff21717a8
commit
9885bfc2aa
|
|
@ -31,7 +31,19 @@
|
||||||
**Вопрос:** Пробовал GitHub Spec Kit или писать spec перед кодом? Это будущее или overkill?
|
**Вопрос:** Пробовал GitHub Spec Kit или писать spec перед кодом? Это будущее или overkill?
|
||||||
|
|
||||||
**Ответ:**
|
**Ответ:**
|
||||||
[pending]
|
|
||||||
|
Не знал что есть прям такой фреймворк, но оказывается именно так и делаю большинство задач над продакшен проектами. Пишу подробную спецификацию о том что хочу сделать. Не для каждой задачи — когда нужно начать новый значительный домен функционала.
|
||||||
|
|
||||||
|
**Что могу подтвердить:**
|
||||||
|
- Время на spec иногда > времени на код. Да, чёрт возьми — это правда. Бывает полдня пишешь спеку, потом уходишь пить кофе, а Клод за это время успевает всё закодить. Несправедливо! :)
|
||||||
|
- Для мелких задач — действительно перебор
|
||||||
|
- Созданная спека сохраняется как CLAUDE.md для продолжения работы позже
|
||||||
|
|
||||||
|
**Важно:** так делаю для больших разделов. Одним запуском AI агента проблема не решается. Часто потом работа идёт недели или месяцы, и спека используется для быстрого старта новых сессий: "прочитай спеку, найди код".
|
||||||
|
|
||||||
|
**Проблема подхода:** изначальное решение меняется в ходе разработки. Находятся другие подходы, меняются пути и названия функций. Приходится держать спеку в актуальном состоянии — дополнительная когнитивная нагрузка на человека и AI. Хорошо держать документ в коде и коммитить изменения — тогда удобнее видеть что изменилось.
|
||||||
|
|
||||||
|
**Лайфхак:** Последнее время делаю стадию разработки спеки не в одиночку, а совместно с Claude Desktop — отличный инструмент для research, brainstorm и metaprompting. Прорабатываю решения, делаю глубокий research, нахожу архитектурное решение, прошу Claude Desktop собрать полноценную спецификацию. Сохраняю в проект и запускаю Claude Code работать по ней.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -40,7 +52,29 @@
|
||||||
**Вопрос:** Как используешь Claude Code? Даёшь автономию или контролируешь каждый шаг? Что доверяешь агенту, что нет?
|
**Вопрос:** Как используешь Claude Code? Даёшь автономию или контролируешь каждый шаг? Что доверяешь агенту, что нет?
|
||||||
|
|
||||||
**Ответ:**
|
**Ответ:**
|
||||||
[pending]
|
|
||||||
|
Вижу много восторженных отзывов о Ralph Loop и может быть хотел бы попробовать. Но честно говоря, этот подход меня смущает.
|
||||||
|
|
||||||
|
**Главный вопрос:** какие задачи можно ставить агенту, чтобы настолько долго оставлять его работать автономно?
|
||||||
|
|
||||||
|
Смотри мой ответ про Spec-Driven Development — написание спецификации занимает кратно больше времени чем её выполнение. Меня пугает: сколько времени нужно потратить на постановку задачи, чтобы её потом выполнять 14 часов?
|
||||||
|
|
||||||
|
Я хотел бы найти применение такому подходу, но пока скорее озадачен и не вижу прямых применений в своих проектах.
|
||||||
|
|
||||||
|
**Призыв к читателям:** может быть вы в комментариях поделитесь кейсами где Ralph Loop классно работает?
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Дополнение: Permissions в Claude Code
|
||||||
|
|
||||||
|
Пермишены — это боль. Понятно зачем они, но честно говоря они ломают всю концепцию. Сидеть и следить как Claude Code делает свою работу и на каждый чих спрашивает разрешение? Это вообще не тот опыт который хотелось бы получить от AI разработки. Они больше расфокусируют внимание.
|
||||||
|
|
||||||
|
**Мои практики:**
|
||||||
|
- Прошу Claude Code: "возьми все tools этого MCP и добавь разрешение в `.claude/settings.json`". Проактивное заполнение работает лучше чем кликать вручную
|
||||||
|
- Не встречал ничего такого, чего нельзя было бы вернуть с помощью `git reset`
|
||||||
|
- Иногда включаю `--dangerously-skip-permissions`, но поглядываю не пошёл ли Claude открывать банковский счёт на моё имя
|
||||||
|
|
||||||
|
**Вывод:** это вопрос который предстоит ещё переизобрести и найти какой-то компромисс.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -49,7 +83,16 @@
|
||||||
**Вопрос:** Copilot/Cursor — как pair programmer или просто autocomplete? Реально ли это "парное программирование"?
|
**Вопрос:** Copilot/Cursor — как pair programmer или просто autocomplete? Реально ли это "парное программирование"?
|
||||||
|
|
||||||
**Ответ:**
|
**Ответ:**
|
||||||
[pending]
|
|
||||||
|
Помню ранние времена, когда AI автокомплит появлялся. Честно? Пробовал в несколько заходов — и каждый раз полностью отключал.
|
||||||
|
|
||||||
|
**Почему не зашло:** предложения написать мою функцию по названию только мешали и сильно сбивали с мысли. Знаю что многим заходит, но мне почему-то нет. Стандартных подсказок IDE мне всегда хватало.
|
||||||
|
|
||||||
|
**Почему так:** когда пишу код, я уже мысленно представил что именно хочу получить. Предлагаемое агентом мне уже не нужно. Я делаю ресёрч ДО того как разобраться как это написать в коде.
|
||||||
|
|
||||||
|
**Где реальное pair programming:** Claude Desktop с хорошо настроенной системной инструкцией проекта + Filesystem MCP чтобы он мог читать реальные файлы из репозитория. Вот тогда — да, могу почувствовать что общаюсь с кем-то кто понимает мою проблему и реально помогает в её решении.
|
||||||
|
|
||||||
|
**Вывод:** Autocomplete ≠ pair programming. Настоящее pair programming — это диалог, когда AI имеет контекст твоего проекта.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -58,7 +101,16 @@
|
||||||
**Вопрос:** Как часто AI делает что-то без твоего одобрения? Где граница доверия?
|
**Вопрос:** Как часто AI делает что-то без твоего одобрения? Где граница доверия?
|
||||||
|
|
||||||
**Ответ:**
|
**Ответ:**
|
||||||
[pending]
|
|
||||||
|
Редко останавливаю Claude Code во время работы. Но иногда бывает — когда вижу что он пошёл не по тому пути. Признаюсь, часто это потому что я просто дал недостаточно деталей — я это сразу понимаю и дописываю.
|
||||||
|
|
||||||
|
**Permissions ≠ HITL.** Не согласен что permissions это реализация Human-in-the-Loop. Это слишком низкоуровневые запросы — по ним не всегда видно какую задачу сейчас решает агент.
|
||||||
|
|
||||||
|
**Настоящий HITL = Planning Mode.** Предпочитаю запускать режим планирования для всех кроме элементарных задач. Вот это реальный контроль на уровне задачи.
|
||||||
|
|
||||||
|
**Проблема современных агентов:** они не очень понимают где те моменты когда нужно остановиться и спросить. Редко встречал точное попадание. Думаю это то, что ещё предстоит реализовать в будущем. Так же как и чтобы агент отвечал "я не знаю". Видимо современные модели на это не способны в широком смысле.
|
||||||
|
|
||||||
|
**Базовое правило:** проверка кода в конце работы агента — это обязательное условие для профессиональной работы.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
@ -67,7 +119,26 @@
|
||||||
**Вопрос:** Пишешь тесты первыми при работе с AI? Работает ли классический TDD с генеративным AI?
|
**Вопрос:** Пишешь тесты первыми при работе с AI? Работает ли классический TDD с генеративным AI?
|
||||||
|
|
||||||
**Ответ:**
|
**Ответ:**
|
||||||
[pending]
|
|
||||||
|
Это сто процентов очень важный подход. Стараюсь практиковать его на ключевом функционале проекта.
|
||||||
|
|
||||||
|
**Tests as Specification:** Да, это важный момент. Покрываю тестами значимые участки и всегда инструктирую агента проверять тесты. Это часть спецификации.
|
||||||
|
|
||||||
|
**AI пишет тесты первым:** Обычно так не делаю. Только когда есть хорошая базовая спецификация — например, документация на API которую легко превратить в набор тестов. Но чаще: спецификация → базовая имплементация → покрытие тестами → дальнейшая работа.
|
||||||
|
|
||||||
|
**TDD как guardrails:** Думаю там это тем более важно. Но продолжу скепсис — а кто будет писать тесты? Если честно, написанная подробная спека и подробные тесты — это уже 80% работы.
|
||||||
|
|
||||||
|
**Опасность AI-тестов:** Тесты нужно проверять самостоятельно. Не раз был очевидцем когда агент писал тесты которые "проходили" потому что он использовал замоканные запросы. Иногда это funny, иногда может загубить дальнейшую работу. Правильные тесты — это надёжный фундамент дальнейшей работы.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
### Дополнение: Контекст агента
|
||||||
|
|
||||||
|
Тесты — это часть того, что я бы назвал **"контекстом агента"**. Это крайне важная составляющая агентского кодинга, значительно повышающая автономность агента и его способность доведения решения до конца.
|
||||||
|
|
||||||
|
Условно говоря: если вы дебажите проблему, делаете фичу — подумайте как дать возможность AI агенту самостоятельно проверять результат его работы. Это могут быть тесты, MCP инструменты с доступом к браузеру. Наличие таких способностей повышает эффективность агента в разы.
|
||||||
|
|
||||||
|
**Где должен быть человек:** в правильном месте — для оценки итогового результата или решения. Нужно стараться исключить его из низкоуровневых мелких итераций где агент лучше действует самостоятельно.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
|
|
|
||||||
|
|
@ -18,6 +18,7 @@ Based on research, selecting approaches for article coverage.
|
||||||
| **Vibe Coding** | Hook — Collins Word of Year 2025, everyone knows it | Wikipedia, Collins, Karpathy | ✅ verified |
|
| **Vibe Coding** | Hook — Collins Word of Year 2025, everyone knows it | Wikipedia, Collins, Karpathy | ✅ verified |
|
||||||
| **Spec-Driven Development** | Direct contrast to vibe coding, GitHub Spec Kit | GitHub, ThoughtWorks, Martin Fowler | ✅ verified |
|
| **Spec-Driven Development** | Direct contrast to vibe coding, GitHub Spec Kit | GitHub, ThoughtWorks, Martin Fowler | ✅ verified |
|
||||||
| **Agentic Coding** | Hot topic, Claude Code users care about this | arXiv surveys (Aug 2025, Dec 2025) | ✅ verified |
|
| **Agentic Coding** | Hot topic, Claude Code users care about this | arXiv surveys (Aug 2025, Dec 2025) | ✅ verified |
|
||||||
|
| **Ralph Loop** | HOT Jan 2026, max autonomy extreme | VentureBeat, Geoffrey Huntley, Anthropic plugin | ✅ verified |
|
||||||
|
|
||||||
### Tier 2: SHOULD Include (Good Authority, Practical)
|
### Tier 2: SHOULD Include (Good Authority, Practical)
|
||||||
|
|
||||||
|
|
@ -83,6 +84,15 @@ Based on research, selecting approaches for article coverage.
|
||||||
| arXiv 2512.07921 | arxiv.org/abs/2512.07921 | "DeepCode: Open Agentic Coding" (Dec 2025) |
|
| arXiv 2512.07921 | arxiv.org/abs/2512.07921 | "DeepCode: Open Agentic Coding" (Dec 2025) |
|
||||||
| arXiv 2512.14012 | arxiv.org/html/2512.14012 | "Professional Developers Don't Vibe, They Control" |
|
| arXiv 2512.14012 | arxiv.org/html/2512.14012 | "Professional Developers Don't Vibe, They Control" |
|
||||||
|
|
||||||
|
### Ralph Loop (Ralph Wiggum)
|
||||||
|
| Source | URL | Notes |
|
||||||
|
|--------|-----|-------|
|
||||||
|
| Geoffrey Huntley | ghuntley.com/ralph/ | Original author (May 2025) |
|
||||||
|
| VentureBeat | venturebeat.com | "How Ralph Wiggum went from Simpsons to AI" (Jan 2026) |
|
||||||
|
| GitHub (snarktank) | github.com/snarktank/ralph | Original repo |
|
||||||
|
| GitHub (Anthropic) | claude.ai | Official ralph-wiggum plugin by Boris Cherny |
|
||||||
|
| Dev.to | dev.to | "2026 - Year of Ralph Loop Agent" |
|
||||||
|
|
||||||
### AI Pair Programming
|
### AI Pair Programming
|
||||||
| Source | URL | Notes |
|
| Source | URL | Notes |
|
||||||
|--------|-----|-------|
|
|--------|-----|-------|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue