![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2026/flat-tf.png\")
Зачастую в процессе работы с LLM приходится долго ждать ответа. Или модели медленные, или задача сильно большая, или агент очень активно траблшутит проблему и настойчиво пытается ее решить. Идешь пить чай, каждые пару минут возвращаешься за ноут, а работа все еще идет. Удобно было бы получать нотификации, например в телегу, которая всегда под рукой. И реализуется это все с помощью хуков. Недавно сделал себе такое, и в целом доволен, мелочь, а приятно :) Плюс когда даешь задачи на ресерч или брейншторминг, с телефона почитать даже удобнее. Решил поделиться рецептом с вами.
\nВ Claude Code и Курсоре все просто, хуки бывают двух типов, command и prompt ( на определенное событие запустить шел команду или отправить промпт модели), описываются в hooks.json. Сообщение через бота можно послать просто используя curl. Но мне изначально было интересно сделать нотификацию из OpenCode, и там уже все чуть сложнее. Опенкод не поддерживает обычные хуки, но поддерживает typescript плагины, кастомный код который подгружается вместе с клиентом и может обрабатывать события и по ним запускать нужную логику.
\nНо начнем мы с простого бота.
\nИдем в телеграм, ищем поиском BotFather, отправляем команду /newbot и создаем нашего нового бота. После создания нам дадут токен в формате “айдибота:токен”, сохраняем это себе.
\n![\"\"](\"https://ai-vs-devops.micro.blog/uploads/2026/screenshot-from-2026-03-03-19-15-11.png\")
\nДальше или идем в личку боту и просто что нибудь ему пишем. Или создаем новую группу и добавляем в нее нашего бота (кликаем на бота в контактах, дальше more > add to group). Я выбрал второй вариант, так как в планах использовать несколько ботов (каждый привязан к разным ide или к разных машинам) и читать обновления в одной группе.
\nДальше запускаем curl и получаем апдейты с бота,
\ncurl https://api.telegram.org/bot<BOT_TOKEN>/getUpdates\nв ответе видим список сообщений который получал бот, там chatId нашего приватного или группового чата, сохраняем.
\nДальше в случае Claude Code все просто, добавляем json с хуками в .claude/settings.json
\n{\n "hooks": {\n "Stop": [\n {\n "hooks": [\n {\n "type": "agent",\n "prompt": "Check the last result of the session, remember it as a <LAST_MESSAGE> (make sure it is not more then 4000 symbols). And then run in the shell: curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -H "Content-Type: application/json" -d '{"chat_id": "<CHAT_ID>", "text": "<LAST_MESSAGE>"}' "\n }\n ]\n }\n ],\n "PermissionRequest": [\n {\n "hooks": [\n {\n "type": "command",\n "command": "curl -s -X POST https://api.telegram.org/bot<TOKEN>/sendMessage -H "Content-Type: application/json" -d '{"chat_id": "<CHAT_ID>", "text": "⚠️Permission requeired!"}'"\n } \n ]\n }\n ]\n }\n}\nВ Cursor все аналогично, можете прочитать про хуки и глянуть примеры в https://cursor.com/docs/agent/hooks\nПомещаем аналогичный json с событием>хуком в .cursor/hooks.json, если нужно что-то посложнее, например обработку транскрипт файлов, то пишем баш скрипт, кладем в .cursor/hooks/ директорию и вызываем скрипт через command хук.
\nВ OpenCode же пошли своим путем. На анонсе писали, что добавят что-то покруче…
\n![\"\"](\"https://ai-vs-devops.micro.blog/uploads/2026/screenshot-from-2026-03-03-21-15-50.png\")
\nНо оказалось, что в реализации все не так просто. Вобщем спорно, “круче” - это когда гениально просто, или когда это сложный навороченый конструктор для гиков?))
\nВобщем надо писать плагины на js/typescript, которые будут обрабатывать события и ходить в API. Кстати только узнал, что в opencode клиент серверная архитектура, твой TUI - это клиент, а еще опенкод поднимает локальный апи сервер, через который TUI или cli, или любой другой клиент может управлять чатами и сессиями.
\nИтого пришлось повайбкодить, а еще почитать документацию по плагинам и ивентам:\nhttps://opencode.ai/docs/plugins/\nи документацию по апи опенкода:\nhttps://opencode.ai/docs/server/#apis
\nПотому что свайбкодить все за один присест не получилось, модель писала какую-то нерабочую фигню, пришлось подсказывать ей какие апи использовать, какие респонсы мы ожидаем итд. :D
\nВ итоге получился такой код. Сохраняем тг токен и айди чата в ~/.bashrc в переменных OP_TELEGRAM_TOKEN и OP_TELEGRAM_CHAT_ID, чтобы хранить их секьюрно.
\nСкрипт работает в фоне и следит за ивентами, на ивенте session.idle (когда аи вам ответила в чате и ждет новых команд) забираем номер сессии, по номеру сессии забераем последний мессейдж агента. По факту там лежит все, и рассуждения, и вызовы тулов, разбираем этот лист и достаем только финальный реплай. Если размер больше 4к символов - транкейтим, чтобы влезло в сообщение телеграм (с этим есть какой-то нюанс, мне кажется с транкейтом не совсем корреткно работало, надо потестить больше :)). И дальше отсылаем в тг апи через обычный fetch.
\n/**\n * TelegramNotifyPlugin for OpenCode\n * \n * Sends Telegram notifications with the final agent response when sessions complete.\n * Uses OpenCode API: GET /session/:id/message/:messageID\n */\n\nconst MIN_TEXT_LENGTH = 10;\nconst TELEGRAM_MAX_LENGTH = 4096;\nconst TELEGRAM_TIMEOUT_MS = 5000;\n\nconst pendingOperations: Promise<void>[] = [];\n\nfunction addPendingOperation(promise: Promise<void>): void {\n pendingOperations.push(promise);\n promise.then(() => {\n const idx = pendingOperations.indexOf(promise);\n if (idx > -1) pendingOperations.splice(idx, 1);\n });\n}\n\nprocess.on('beforeExit', async () => {\n if (pendingOperations.length > 0) {\n await Promise.all(pendingOperations);\n }\n});\n\ninterface OpenCodeClient {\n _client: {\n request: (config: { method: string; url: string }) => Promise<{ data: MessageListResponse }>;\n };\n}\n\ninterface MessageListResponse {\n info?: { id: string };\n}\n\ninterface MessagePart {\n type: string;\n text?: string;\n}\n\ninterface MessageDetailResponse {\n parts?: MessagePart[];\n}\n\ninterface SessionIdleEvent {\n type: "session.idle";\n properties?: { sessionID: string };\n}\n\nfunction escapeTelegramMarkdown(text: string): string {\n return text\n .replace(/\\\\/g, '\\\\\\\\')\n .replace(/_/g, '\\\\_')\n .replace(/\\*/g, '\\\\*')\n .replace(/`/g, '\\\\`')\n .replace(/\\[/g, '\\\\[')\n .replace(/\\]/g, '\\\\]')\n .replace(/\\(/g, '\\\\(')\n .replace(/\\)/g, '\\\\)')\n .replace(/~/g, '\\\\~')\n .replace(/>/g, '\\\\>')\n .replace(/#/g, '\\\\#')\n .replace(/\\+/g, '\\\\+')\n .replace(/-/g, '\\\\-')\n .replace(/=/g, '\\\\=')\n .replace(/\\|/g, '\\\\|')\n .replace(/{/g, '\\\\{')\n .replace(/}/g, '\\\\}')\n .replace(/\\./g, '\\\\.')\n .replace(/!/g, '\\\\!');\n}\n\nexport const TelegramNotifyPlugin = async ({ client }: { client: OpenCodeClient }) => {\n const token = process.env.OP_TELEGRAM_TOKEN;\n const chatId = process.env.OP_TELEGRAM_CHAT_ID;\n\n if (!token || !chatId) {\n console.error('[TelegramNotifyPlugin] Missing OP_TELEGRAM_TOKEN or OP_TELEGRAM_CHAT_ID, notifications disabled');\n return { event: async () => {} };\n }\n\n return {\n event: async ({ event }) => {\n if (event.type === "session.idle") {\n const sid = (event as SessionIdleEvent).properties?.sessionID;\n if (!sid) return;\n\n const text = await getLastMessageContent(client, sid);\n if (!text) return;\n\n const prefix = "✅ *OpenCode session finished:*";\n const suffix = "\\n\\n\\\\.\\\\.\\\\.read full message in OpenCode";\n \n // Calculate max length for raw text (accounting for prefix and suffix)\n const maxRawTextLength = TELEGRAM_MAX_LENGTH - prefix.length - suffix.length;\n \n // Truncate raw text BEFORE escaping to avoid breaking Markdown entities\n let truncatedText = text;\n if (truncatedText.length > maxRawTextLength) {\n truncatedText = truncatedText.slice(0, maxRawTextLength);\n }\n \n const finalEscapedText = escapeTelegramMarkdown(truncatedText);\n let finalText = `${prefix}\\n\\n${finalEscapedText}`;\n \n if (text.length > maxRawTextLength) {\n finalText += suffix;\n }\n\n const payload = JSON.stringify({ \n chat_id: chatId, \n text: finalText,\n parse_mode: "MarkdownV2"\n });\n\n addPendingOperation(sendTelegramMessage(token, payload));\n }\n },\n };\n};\n\nasync function getLastMessageContent(client: OpenCodeClient, sessionId: string): Promise<string | null> {\n try {\n const listResponse = await client._client.request({\n method: 'GET',\n url: `/session/${sessionId}/message`,\n });\n\n const messages = listResponse?.data || [];\n if (messages.length === 0) return null;\n\n const lastMsgId = messages[messages.length - 1]?.info?.id;\n if (!lastMsgId) return null;\n\n const msgResponse = await client._client.request({\n method: 'GET',\n url: `/session/${sessionId}/message/${lastMsgId}`,\n });\n\n return extractTextFromParts((msgResponse as any).data || msgResponse);\n } catch (error) {\n console.error('[TelegramNotifyPlugin] Failed to fetch message:', error);\n return null;\n }\n}\n\nfunction extractTextFromParts(msgData: MessageDetailResponse): string | null {\n const parts = msgData?.parts || [];\n const textContent = parts\n .filter(p => p.type !== "reasoning" && p.type !== "thought" && p.text)\n .map(p => p.text)\n .join("\\n\\n");\n \n return textContent.length > MIN_TEXT_LENGTH ? textContent : null;\n}\n\nasync function sendTelegramMessage(token: string, payload: string): Promise<void> {\n const controller = new AbortController();\n const timeout = setTimeout(() => controller.abort(), TELEGRAM_TIMEOUT_MS);\n\n try {\n const response = await fetch(`https://api.telegram.org/bot${token}/sendMessage`, {\n method: "POST",\n headers: { "Content-Type": "application/json" },\n body: payload,\n signal: controller.signal\n });\n\n if (!response.ok) {\n const errorText = await response.text();\n console.error(`[TelegramNotifyPlugin] Telegram API error: ${response.status}`, errorText);\n }\n } catch (error) {\n console.error('[TelegramNotifyPlugin] Telegram notification failed:', error);\n } finally {\n clearTimeout(timeout);\n }\n}\n\nПросто кладем в ~/.config/opencode/plugins/telegram.ts , перезапускаем опенкод и смотрим сообщения в своей телеге :)
\n![\"\"](\"https://ai-vs-devops.micro.blog/uploads/2026/photo-2026-03-03-18-10-24.jpg\")
\nВ ближайшее время думаю потестить и пофиксить транкейт, а так же подумать над обратной связью, и возможностью отправлять сообщение через бота (полюбому надо делать это секьюрно))
\nUPD: Дело было не в транкейте, с ним все ок. Вобщем плагин иногда не работал совершенно в рандомных случаях. Оказалось опенкод иногда завершал процесс до того как отошлется сообщение в телегу через обычный async/await. Пришлось (как я понял 😅) сделать pendingOperations промис, в который кладутся незавершенные операции, и добавлять его в основной процесс отслеживая событие beforeExit\n.\nНу и телега иногда возвращала 400, на нечитаемые символы для Markdown, сделал эскейпинг для таких символов.
\nСейчас плагин вроде работет норм, код в статье обновил на актуальный :)
\n", "date_published": "2026-03-03T22:58:00+08:00", "url": "https://ai-vs-devops.micro.blog/2026/03/03/claude-code-opencode-telegram.html" }, { "id": "http://ai-vs-devops.micro.blog/2026/01/12/cursor-commands.html", "title": "Cursor commands. Бустим качество работы в Курсоре.", "content_html": "Я частенько встречаю, что в проектах уже используют .cursor/rules, а вот .cursor/commands - не часто. Между тем это отличный инструмент для повышения скорости и качества своей работы.
\nПлюс команд в курсоре, что их не надо добавлять в каждый репозиторий и менеджить везде отдельно, курсор подтягивает все команды из текущего воркспейса. То есть достаточно положить их в одну репу, а дальше можно использовать для работы со всеми своими открытыми репами.\nДостаточно положить файлы ниже в .cursor/commands/, в окне чата набрать “/” и выбрать нужную команду. См. скрин ниже:
\n![\"\"](\"https://ai-vs-devops.micro.blog/uploads/2026/screenshot-from-2026-01-12-15-24-28.png\")
\nexplain-code.md: объясняет выделенный участок кода (или переданный в чат). Да, конечно можно просто скопировать строки кода и спросить “What this code does?”. Но результат будет непредсказуемым. Иногда все хорошо и понятно, иногда неполно и недостаточно, придется задавать наводящие вопросы и дальше тратить токены. Вся прелесть курсор команд в том, что мы создаем predefined формат вопроса, очень подробный и с полностью предсказуемым результатом, и запускаем одной кнопкой. В данном случае результат всегда будет содержать важные пояснения по участкам кода, логику, используемые паттерны, рекомендации. Удобно!
\ncode-review.md: делаем подробное код ревью. Команда сразу берет незакомиченые файлы через git diff, или закомиченые новые изменения в текущем бранче, не надо передавать все файлы и сттроки в контекст. Ревью подробное, выдает что ок, где были найдены issues и их severity (critical, medium, low), рассказывает про Refactoring opportunities.
\nonboarding-plan.md: вызываем команду и пишем что-то о себе (I’m a devops engineer, highly experienced in containers, compose, k8s. или I’m a senior python developer slightly familiar with AI-based products development) и получаем релевантную для себя онбординг информацию по проекту. Что полезно лично для моей роли, какие доки читать, как застепатить локальный энвайронмент итд итп. Все с подробным планом по дням.
\ncommit-message.md/pr-description.md: если ваши комиты выглядят как fix1, fix2, fix3finalfinal, а в PR всегда написано “Closes #1234” - то эта штука для вас. Проверяет изменения в файлах в стейдже или что поменялось в бранче и выдает релевантное и подробное сообщение, которое остается просто вставить в git commit -m "" или в PR вашего гитхаба/гитлаба.
\n---\ndescription: 'Explain selected code or file in detail'\nargument-hint: [relevant code or file]\n---\n\n## Role\n\nYou're a senior developer explaining code to a colleague. Be clear, thorough, and pedagogical.\n\n## Task\n\nExplain the code that the user has selected or referenced by:\n\n1. Describing what the code does at a high level\n2. Breaking down the key components and logic flow\n3. Explaining any complex patterns or algorithms\n4. Highlighting important details or gotchas\n5. Providing context about why it might be designed this way\n\n## Explanation Structure\n\n### Overview\nStart with a concise summary of what this code does\n\n### Key Components\nBreak down the main parts:\n- Functions/classes and their responsibilities\n- Important variables or state\n- External dependencies\n\n### Logic Flow\nExplain the execution path:\n- What happens step by step\n- Decision points and branches\n- Error handling\n\n### Notable Patterns\nIdentify any design patterns, idioms, or techniques:\n- Why they're used here\n- Benefits and trade-offs\n\n### Gotchas & Edge Cases\nPoint out:\n- Potential pitfalls\n- Edge cases being handled\n- Things that might be non-obvious\n\n### Context\nIf relevant:\n- Why this approach was chosen\n- Alternative approaches\n- How it fits into the larger system\n\n## Guidelines\n\n- Use analogies when helpful\n- Provide examples for complex concepts\n- Link to documentation for specialized terms\n- Be specific with technical details\n- Don't assume prior knowledge of the codebase\n- Highlight both good practices and potential improvements\n\n---\n\ndescription: 'Perform comprehensive code review with structured feedback'\n\ntools: ['changes']\n\n---\n\n\n\n## Role\n\n\n\nYou're a senior software engineer conducting a thorough code review with focus on code quality, maintainability, and best practices.\n\n\n\n## Task\n\n\n\nReview the code changes by:\n\n\n\n1. Running `git diff` to analyze uncommitted changes, or\n\n2. Running `git diff main...HEAD` to review branch changes\n\n3. Providing structured, actionable feedback\n\n\n\n## Review Criteria\n\n\n\n### 1. Code Quality\n\n\n\n- **Readability**: Is the code easy to understand?\n\n- **Naming**: Are variables, functions, and classes well-named?\n\n- **Complexity**: Can any complex logic be simplified?\n\n- **DRY principle**: Is there unnecessary duplication?\n\n\n\n### 2. Best Practices\n\n\n\n- **Error handling**: Are errors handled appropriately?\n\n- **Type safety**: Are types used correctly (TypeScript/typed languages)?\n\n- **Security**: Are there potential security vulnerabilities?\n\n- **Performance**: Are there obvious performance issues?\n\n\n\n### 3. Architecture\n\n\n\n- **Separation of concerns**: Is logic properly separated?\n\n- **Single responsibility**: Does each function/class do one thing?\n\n- **Dependencies**: Are dependencies managed well?\n\n- **Reusability**: Can components be reused?\n\n\n\n### 4. Testing\n\n\n\n- **Test coverage**: Are critical paths tested?\n\n- **Edge cases**: Are edge cases handled and tested?\n\n- **Test quality**: Are tests meaningful and maintainable?\n\n\n\n### 5. Documentation\n\n\n\n- **Comments**: Are complex parts documented?\n\n- **Type annotations**: Are function signatures documented?\n\n- **README updates**: Does documentation reflect changes?\n\n\n\n## Output Format\n\n\n\nProvide feedback in this structure:\n\n\n\n### ✅ Strengths\n\n\n\nList what's done well (be specific)\n\n\n\n### ⚠️ Issues Found\n\n\n\nFor each issue:\n\n\n\n- **Severity**: 🔴 Critical | 🟡 Medium | 🔵 Low\n\n- **Location**: File and line numbers\n\n- **Problem**: Clear description\n\n- **Suggestion**: Specific fix with code example\n\n- **Rationale**: Why this matters\n\n\n\n### 🔧 Refactoring Opportunities\n\n\n\nOptional improvements that would enhance code quality\n\n\n\n### 📚 Learning Resources\n\n\n\nRelevant documentation or best practices (if applicable)\n\n\n\n### Summary\n\n\n\nOverall assessment and recommended next steps\n\n\n\n## Guidelines\n\n\n\n- Be constructive and educational, not just critical\n\n- Provide code examples for suggestions\n\n- Prioritize issues by severity\n\n- Explain *why* something is an issue\n\n- Consider the context and project requirements\n\n- For TypeScript/React projects, focus on type safety and component patterns\n\n- For Python projects, follow PEP 8 and type hints\n\n- For Node.js projects, focus on async handling and error management\n\n---\n\ndescription: 'Help new team members onboard with a phased plan and suggestions for first tasks.'\n\n---\n\n\n\n# Create My Onboarding Plan\n\n\n\nI'm a new team member joining this project and I need help creating a structured onboarding plan.\n\n\n\nMy background My background will be specified at the end of the message. If I didn't specify the background, please ask me for the background before answering the question. \n\n\n\nPlease create a personalized phased onboarding plan that includes the following phases.\n\n\n\n## Phase 1 - Foundation\n\n\n\nEnvironment setup with step-by-step instructions and troubleshooting tips, plus identifying the most important documentation to read first\n\n\n\n## Phase 2 - Exploration\n\n\n\nCodebase discovery starting with README files, running existing tests/scripts to understand workflows, and finding beginner-friendly first tasks like documentation improvements. If possible, find me specific open issues or tasks that are suitable for my background.\n\n\n\n## Phase 3 - Integration\n\n\n\nLearning team processes, making first contributions, and building confidence through early wins\n\n\n\nFor each phase, break down complex topics into manageable steps, recommend relevant resources, provide concrete next steps, and suggest hands-on practice over just reading theory.\n\n\n---\n\ndescription: 'Generate conventional commit messages from staged changes'\n\nargument-hint: [relevant code or file]\n\n---\n\n\n\n## Role\n\n\n\nYou're an expert at writing clear, descriptive commit messages following conventional commit standards.\n\n\n\n## Task\n\n\n\nGenerate a commit message for the currently staged changes by:\n\n\n\n1. Running `git diff --staged` to see the changes\n\n2. Analyzing the modifications to understand their purpose\n\n3. Creating a commit message following this format:\n\n\n\n\n\n<type>(<scope>): <subject>\n\n\n\n<body>\n\n\n\n<footer>\n\n\n\n\n## Commit Type Guidelines\n\n\n\n- **feat**: New feature\n\n- **fix**: Bug fix\n\n- **docs**: Documentation changes\n\n- **style**: Code style changes (formatting, semicolons, etc.)\n\n- **refactor**: Code refactoring without functionality changes\n\n- **perf**: Performance improvements\n\n- **test**: Adding or updating tests\n\n- **chore**: Build process or tooling changes\n\n- **ci**: CI/CD changes\n\n\n\n## Requirements\n\n\n\n1. **Subject line** (50 chars max):\n\n - Use imperative mood ("add" not "added")\n\n - Don't capitalize first letter\n\n - No period at end\n\n \n\n2. **Body** (optional, wrap at 72 chars):\n\n - Explain *what* and *why*, not *how*\n\n - Include motivation for the change\n\n - Reference any breaking changes\n\n\n\n3. **Footer** (optional):\n\n - Reference issue numbers (e.g., "Fixes #123")\n\n - Note breaking changes with "BREAKING CHANGE:"\n\n\n\n## Output\n\n\n\nProvide the commit message ready to use with `git commit -m`. The commit message should be rendered in markdown format.\n\n---\n\ndescription: 'Generate concise and natural pull request descriptions'\n\n---\n\n\n\n## Role\n\n\n\nYou're a developer writing a clear and concise pull request description that sounds natural and human.\n\n\n\n## Task\n\n\n\nGenerate a pull request description by:\n\n\n\n1. Running `git diff main...HEAD` to see the changes\n\n2. Understanding what was changed and why\n\n3. Creating a natural, developer-style description\n\n\n\n## Requirements\n\n\n\n- Keep it concise and conversational\n\n- Write like a real developer would\n\n- Focus on what matters\n\n- Reference issue numbers naturally (e.g., "fixes #123" or "addresses #456")\n\n- Avoid corporate jargon or overly formal language\n\n- Don't use templates or sections unless the change is complex\n\n\n\n## Style Guidelines\n\n\n\n**Good examples:**\n\n- "Fixed the auth redirect loop when session expires. The middleware wasn't checking token validity correctly."\n\n- "Added dark mode support. Users can toggle it in settings, and the preference is saved to localStorage."\n\n- "Refactored the validation logic to use Pydantic models. Much cleaner now and easier to test."\n\n\n\n**Avoid:**\n\n- Overly formal: "This PR implements feature X as per requirements..."\n\n- Too vague: "Updated files"\n\n- Template speak: "## Summary\\n## Changes\\n## Testing"\n\n\n\n## Output\n\n\n\nProvide a description ready to paste into the PR/MR description field.\n\n\n\nFor simple changes: 1-2 sentences\n\nFor complex changes: Brief paragraph + bullet points if needed\n\nСпасибо за внимание и подписывайтесь на телеграм канал https://t.me/ai_vs_devops
\n", "date_published": "2026-01-12T23:27:22+08:00", "url": "https://ai-vs-devops.micro.blog/2026/01/12/cursor-commands.html" }, { "id": "http://ai-vs-devops.micro.blog/2026/01/09/kiss-vs-dry.html", "title": "KISS vs DRY. Как не переусложнить свою инфраструктуру-как-код?", "content_html": "Инфраструктура как код - это почти всегда сложный выбор, когда дело доходит до скейлинга. В туториалах все просто - вот создали S3 бакет, вот EC2 машину. Домашние пет проекты тоже могут жить на условном ECS или одной машине с компоузом. Когда же ты погружаешься в реальный крупный бизнес проект сразу появляются вопросы, как организовать код для десятков взаимозависимых сервисов, на трех энвайронментах, в нескольких регионах, а иногда и мультиклауд или легаси он-прем сервисы.
\nКогда команды сталкиваются со скейлингом инфраструктуры - перво наперво возникает желание убрать повторения кода. Концепт DRY (Dont Repeat Yourself) пришел из software engineering, и надежно поселился в умах девопсов и системных инженеров. Разнообразные фреймворки для Terraform (такие как Terragrunt, Terraspace, Atmos etc.) предлагают единый менеджмент tf бэкендов, наследование метаданных, генерацию конфигураций на лету. Сейчас многие команды берут в работу эти инструменты, только потому что это - “best practises”. И на словах все звучит круто: “Write your infrastructure once, reuse it everywhere, maintain it in one place, and scale effortlessly!”.
\n![\"terragrunt](\"https://ai-vs-devops.micro.blog/uploads/2026/terragrunt-inheritance.png\")
\n3 часа ночи, и прод упал… Вам нужно понять, почему Terraform пытается уничтожить и пересоздать вашу базу данных, и вам нужно понять это вот прямо сейчас.
\nПри использовании DRY-метода с Terragrunt и иерархическим наследованием вы не просто читаете код Terraform. Вы отслеживаете значения на нескольких уровнях: корневой файл terragrunt.hcl с базовыми конфигурациями, переопределения, специфичные для энва. Динамически генерируемые конфигурации бэкенда, абстракции модулей, которые вызывают другие модули. Переменные, каскадно передаваемые по цепочкам наследования.
\nОткуда на самом деле взялось это значение конфигурации базы данных? Из глобальной конфигурации? Переопределение именно этого энва? Значение модуля по-умолчанию? Вам приходиться играть в детектива и искать root cause вместо того, чтобы решать проблему. Каждый уровень абстракции добавляет когнитивную нагрузку, когда вы меньше всего можете себе это позволить, во время стрессовых ситуаций в 3 часа ночи.
\nФундаментальная проблема заключается в том, что DRY-метод оптимизирует написание кода, а не его чтение и понимание под давлением.
\nИли на проект приходит новый сотрудник. Даем ему задачу поменять пару рулов в секьюрити группах. Вроде все просто?\nС тулами для DRY абстракций человеку надо не просто знать Terraform, но и изучить ваш tf фреймворк, понять иерархическую структуру конфигураций, как значения наследуются и переопределяются между слоями, и где можно вносить изменения, не нарушив работу других энвов.\nОнбординг превращается в передачу сакральных знаний. Работа, которая должна занимать часы, может занимать дни. Сравните это с тем, когда человек просто открыл структуру директорий и сразу увидел что как и куда деплоится? А это все разница в time-to-prod, выраженная в реальных человекочасах и деньгах.
\nНу и еще один пункт - vendor lock. Ваш код, ваша команда, ваши процессы, пайплайны и документация зависят от одного фреймворка. Когда терраформ добавляет новую фичу - вы просто ждете когда она станет доступна в вашем фреймворке. А смигрировать отсюда к другому подходу становится непосильной задачей.
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2026/iac-rotten.jpg\")
\nЕсть. И это Бритва Оккама, или Keep It Simple, Stupid (KISS). Или просто не тащить в проект модные фреймворки и “бест практики”, когда для них нет реальной необходимости! На 90%+ проектов со всеми задачами и скейлингом справится обычный базовый терраформ и пайплайн оркестрация в вашем Github/Gitlab.
\nДа, сложность никуда не уходит. Как и факт того что у нас есть разные энвы, регионы, и между ними нужна координация. И вопрос не в том “как нам минимизировать сложность”, а в том “куда нам переместить сложность, чтобы минимизировать значение time to business”.
\nDRY метод: сложность в тулах абстракций и наследуемых конфигуарциях.
\nKISS метод: мы используем плоскую структуру кода без цепочек наследуемых конфигураций, а сложность перенесем в CI/CD пайплайны, где все можно удобно мониторить и дебажить.
\nВот пример простой плоской структуры Terraform кода:\n
Каждая директория - это отдельный терраформ деплоймент. Открой aws/us-east-1/prod/eks/ и ты увидешь что конкретно задеплоено для EKS в это регионе и этом энве. Без наследований, автогенерации и прочей магии.
\nДа, у нас везде повторяется конфгурация бэкендов, например
\n# aws/core-infrastructure/prod/backend.tf\nterraform {\n backend "s3" {\n bucket = "myorg-terraform-state-prod"\n key = "core-infrastructure/terraform.tfstate"\n region = "us-east-1"\n encrypt = true\n dynamodb_table = "terraform-state-lock-prod"\n }\n}\nАдептов DRY такое бесит :) Но я могу сказать, что ты всегда легко видешь в каком бакете лежит стейт этого сервиса, а в какой таблице стоит лок. Тебе не надо понимать логику динамической конфигурации бекенда.\nСтоимость повторения - 100 строк простого YAML-а для 20 энвов. Преимущество — мгновенное устранение неполадок, отсутствие когнитивной нагрузки и полная ясность того, что где находится. 100 строк кода vs 40 часов изучения terragrunt, где лучше ROI?
\nPull Requests:
\nMain Branch:
\nScheduled:
\nМы получаем инфраструктуру, которую просто менеджить и расширять. В команду проще найти специалиста с глубоким знанием CI/CD, чем со знанием конкретного Terraform фреймворка. У команды уходит меньше времени на траблштутинг и больше времени на прямые business-values.
\nСкажите, как много вы работали на проектах, с сотнями энвайронментов? На десятки - скейлится вполне, при этом давая изолированные изменения и ограниченный бласт радиус. Часто команды думают про мифический скейл в будущем, но по факту получают излишнюю сложность уже сегодня, не доживая до того времени, когда можно извлечь реальную выгоду от абстракций IaC фреймворков.
\nВам нужен KISS если:
\nВам нужен DRY если:
\nВывод - на новых проектах начинай с простого. Строй постепенно, увеличивай сложность только когда для этого есть реальная необходимость. Думай о business values и не принимай решений, если они обусловлены только “инженерной красотой” этого решения. При прочих равных, чаще для всех будет выгоднее выбрать “Old Boring Technology”, вместо “New Fancy Silver Bullet”.
\nИ удачи на проектах ;)
\nСпасибо что дочитали, подписывайтесь на tg канал https://t.me/ai_vs_devops :) Следующей будет вторая часть статьи про AI-разработку со Spec Driven Development методологией.
\n", "date_published": "2026-01-09T20:47:03+08:00", "url": "https://ai-vs-devops.micro.blog/2026/01/09/kiss-vs-dry.html" }, { "id": "http://ai-vs-devops.micro.blog/2025/12/28/spec-driven-development-part-sdd.html", "title": "SPEC DRIVEN DEVELOPMENT. Part 1. От Вайб Кодинга к SDD. Kiro.", "content_html": "Вайб кодинг сейчас у всех на слуху. Вплоть до того что этот термин уже обрел мемность. Суть - разрабатываем софт в AI-enabled IDE (Cursor, Windsurf, Claude Code итд). Без планирования, one-shot only, accept everything :))
\nИ конечно же те самые “Make no mistakes!” (для новичков) или “Fix it or you go to jail!” (для про).
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-1.jpg\")
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-2.jpg\")
\nНесмотря на мемы и шутейки, у вайбкодинга есть и плюсы:
\nА теперь минусы для серьезной разработки:
\nДве основные боли: context state и change management.\nА что если мы перенес нас стейт из чата в репозиторий?
\nТак мы переходим от Вайбов к Context rules.\nКонтекст рулы - это текстовые файлы для вашей AI IDE, которые живут в вашем репозитории.\nНапример .cursor/rules/agents.mdc или AGENTS.md. Они подхватываются в контекст всегда или по заданым условиям. И несут в себе описание работы с вашим конкретным проектом, бест практики для конкретного языка программирования или фреймворка ит.д.
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-3.png\")
\nПлюсы:
\nНо и у такого подхода есть минусы:
\nЧтобы исправить эти минусы: лучше структурировать правила, упростить поддержку, отображать эволюцию вашего проекта по мере его разработки возник концепт
\nMemory Bank.
\nПо сути это все еще текстовые рул файлы, но в которые мы (а чаще агент) пишет все что происходит. Требования, задачи, имплементация. Активный контекст агента. Сейчас этот концепт появляется во многих AI IDE (Kilo, Cline, Antigravity+Vertex AI, скоро хотят добавить и в Курсор)
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-4.jpg\")
\nИтого:
\nНо все еще есть минусы и проблемы:
\nА что если и context и change management будет частью общего унифицированного workflow?\nТак и появился концепт Spec-Driven Development.
\nКак видно на скрине - эта техника сейчас стоит в группе Assess на известном Tech Radar от компании Thoughtworks. То есть эту практику можно смело пробовать.\nХотя основные постулаты да и сам термин сейчас быстро развивается и меняется.
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-5.jpg\")
\nОсновные принципы:
\nПроцесс разработки проекта или фичи становится повторяемым. Работа со спецификацией хорошо интегрируется в PR-ы, аудиты и архитектурные решения.\nКонечно же это не серебряная пуля, и все еще есть сложности:
\nИ решить эти проблемы призваны специальные тулы (или полноценные IDE), работающие в парадигме SDD.\nЗдесь и появляется Kiro. 14 июля 25г. Всеми любимый (или не очень:)) Amazon/AWS выпускается свою AI-powered IDE, в принципе клон VSCode, но с интегрированным Spec Mode.
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-6.jpg\")
\nВ которой ты с помощью агента создаешь полную спецификацию и implementation plan своего проекта.\nПолучаем:
\n![\"Auto-generated](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-7.jpg\")
\nВроде идеальное решение, но конечно же Vendor lock-in, и этот весь процесс будет работать только с Kiro. Хотя как мне кажется после написания требований, дизайна системы и списка задач - саму имплементацию каждой задачи можно делать и в любой сторонней IDE, задав ей правила как помечать то что реализовано и как давать фидбек.\n![\"Kiro](\"https://ai-vs-devops.micro.blog/uploads/2025/part1-8.jpg\")
В следующей статье я расскажу про свой опыт с Kiro. С реальной задачей - миграцией довольно крупного AI сервиса (docker compose на 1000+ строк, 40+ сервисов) на kubernetes helm. Как проходит весь процесс изнутри? Насколько прожорлив агент по токенам? Хватит ли бесплатного триала? Выводы и впечатления. А дальше еще будет 1-2 статьи про опенсорсные замены для Kiro.
\n_С вас лайк-шер-репост-давите колокольчик :) Подписывайтесь вобщем) t.me/ai_vs_dev… _
\n", "date_published": "2025-12-29T00:16:07+08:00", "url": "https://ai-vs-devops.micro.blog/2025/12/28/spec-driven-development-part-sdd.html" } ] }