Возвращаюсь к посту про CI/CD - AI ревью в ваши пайплайны легко внедрить уже сейчас в ваш Github/Gitlab и даже Jenkins. Считай любые AI IDE поддерживают запуск из консоли. Банально запустив opencode run "hi how are you" в консоли вы запутисте опенкод с вашими дефолтными auth настройками и моделью с консольным выводом в stdout. Для упрощения интеграции в пайплайны аи провайдеры написали gh actions/gl templates для интеграции.
Claude Code у себя в документации пишет примеры интеграции cli в пайплайны, для Github, для Gitlab
Так же и OpenCode - Github / Gitlab

В обоих случаях для гитхаба возможна установка полноценного приложения одной командой, после этого вы можете общаться с агентом прямо в pr коментах, issues и даже в коментариях прямо в коде "/opencode fix this", "/oc implement proper lifecycle in this resource" etc.
Для гитлаба же только пайплайны. Но это нам и надо 😎
Ставим джобу через include component

include:
  - component: $CI_SERVER_FQDN/nagyv/gitlab-opencode/opencode@2
    inputs:
      config_dir: ${CI_PROJECT_DIR}/opencode-config
      auth_json: $OPENCODE_AUTH_JSON # The variable name for your OpenCode authentication JSON
      command: optional-custom-command
      message: "Your prompt here"

кладем в секреты auth.json, создаем в репе opencode-config/ с нашей конфигурацией в opencode.jsonc где ставим нужную модель, mcp, lsp сервера. Туда же в директорию кладем нужные скилы и команды. Ставим тригеры для джобы и запуск команды через command:

Когда-то в статье с примерами команд я выкладывал code-review.md - работает отлично до сих пор, использую как локально, так и с интеграцией в гитлаб, чуть поменять в команде что нужно ревьювать код MR а не diff.


Ну и вот еще несколько вариантов, как в пайплайнах можно интегрировать LLM:

* Test coverage daily - проверяем все коммиты за день в поисках кода не покрытого тестами, чтобы уменьшить регрессию. Делаем нотификацию для девелоперов, или сразу просим в команде сделать pr с фиксами, разработчикам лишь понадобится ревьювнуть, поправить и смержить.

* Weekly summary of changes for repos - генерируем самари по важным изменениям за неделю, настраиваем отправку подробного репорта в слак. Key features, bug fixes, tech depth and refactors, tools and infra changes.

* Bug reports triage - придумываем интеграцию с вашей тикет системой или специальной системой для баг репортов, помогаем фиксить баги на автомате.


Делитесь в коменнтариях как еще можно применить LLM в пайплайнах! 👍

GLM-5 наконец-таки раскатывают для Lite юзеров! Пока что тем кто успел быстрее зарегаться в форме, пишите свой аккаунт айди, и любой емейл куда выслать нотификацию, для первого батча пользователей обещают подключить в течении суток. Спешите 😉 Модель хорошая, подойдет для серьезных кодинг задач, и если у вас Lite план - считай будет у вас бесплатно 👍

📢 GLM-5 is Rolling Out to Lite Users!
Hey everyone! Thank you all for your patience. We know you have been eagerly waiting for GLM-5, and we wanted to share this exciting news with you here first.
We are officially planning to roll out GLM-5 to all Lite users within this month, and we are pushing hard to make full access happen even sooner.
Since our current resources are still scaling up, we will be granting early access to a select group of Lite users before the full rollout. To keep things fair, this first batch will be strictly first come, first served:
📝 How to Apply:
Submit your Account ID through this form: https://docs.google.com/forms/d/e/1FAIpQLSc2nnPYosfyxjVh3ThQFN0SOCezxQbUS37SDwTUP7d4XK_vVw/viewform?usp=header
If you submit the correct Account ID and successfully complete the form, you have secured your spot.
We will activate your GLM-5 access within 1 business day of your submission.
⏳ Waiting List: Once we hit the maximum capacity for the first batch, the form will temporarily close. When it reopens, it will transition into a Waiting List. Users on the waitlist will get access based on our resource capacity and submission order. The latest you will get access is the end of March, matching the full rollout timeline.
Thank you again for your understanding and support. We are continuously expanding our compute resources to get GLM-5 to every Lite user as fast as possible.

А вы на каком уровне хайпа? 💅

Заметка от сотрудника Anthropic как и для чего лучше писать скилы.

Вкратце, пишем скилы для:

* Описание как пользоваться своими либами и не самыми распространенными cli
* Как протестировать свой продукт (напр. смотрим такие то поды, такие-то логи, ходим курлом на ингрессы, открываем гуи playwrite-ом и тыкаем кнопки)
* Анализ данных (например вот графана, вот такие датасорсы вот такие дашборды. если вот такая проблема - смотрим вот там)

Есть с чем и поспорить 😎
Team Automation, Code review - это больше подходит под commands, а не skills
CICD, Operations, Infrastructure - для всего этого есть девопсы и пайплайны 😁

Ну и полный набор tips&tricks как эти скилы писать. Полезно 👍

Читаем здесь

Похоже с этим хайпом, что Composer 2 - это Kimi, саму Kimi K2.5 сейчас люди стали гонять в хвост и гриву 😂 Дико тормозит сегодня и на opencode go и даже на openrouter. Похоже пока стоит временно поюзать другие модели, рекомендую GLM-5 👍

Впервые столкнулся, когда модель слишком ведется на хайп слова и не вникает в суть, при эвалюейшене результатов тех собеса. 😵

Собесил человечка. Он не плох по софтам, что-то есть по cicd и security, но точно не синьор и точно не на эту позицию. Как обычно скидываю сиви, джоб дескрипшен, топики для собеса которые мы прошли и полный транскрипт беседы. Отправляю это в GLM-5 - и она мне пишет - "ОФИГЕТЬ ПОЛНЫЙ МЭТЧ, БЕРЕМ!" Я чуть офигел 🙈, удалил чат, загрузил все по новой в Gemini 3.1 Pro (все таки лучшая модель для бизнесовых задач) и она мне тоже выдает: "кандидат подходит". Вот например с такими заметками:

1. Core Competencies (JD Requirements) - Strong
* CI/CD & Jenkins: He has 5 years of direct Jenkins experience before moving to Bitbucket Pipelines. He deeply understands CI/CD optimization (reducing build times from 20m to 3m by changing image bases, optimizing tests, and removing unnecessary steps). He understands pipeline templates and branch-environment routing.
* Terraform & AWS: He demonstrated mature Infrastructure-as-Code practices. He segregates environments using Terraform workspaces and S3 buckets, injects AWS Secrets Manager variables at runtime (avoids hardcoding), and strictly advocates for running terraform plan/apply via CI/CD pipelines rather than local machines.
* DevSecOps & Release Governance: This is his strongest area. He acts as a "guardian of the process" and has great experience integrating SAST/SCA (SonarQube, Snyk). His anecdote about debugging a developer's false positive (passing a bloated object instead of a required string) shows excellent practical troubleshooting and collaboration skills.

Я уже думаю что может я что-то прослушал 😟, скинул в Гемини уже свои заметки. Спрашиваю "а вот это вот, вот это вот что тогда??"😂 Вобщем вот такой re-evaluation у него произошел сразу:

You are absolutely right, and I appreciate the pushback. I completely overlooked the lack of depth in his answers by focusing too much on his confidence and the buzzwords he used (like "reduced from 20m to 3m").
When looking closer at the transcript based on your feedback:
1. CI/CD Optimization: His "optimization" was literally just using a lighter base Docker image, cleaning up some commands, and fixing unit tests. There was no mention of layer caching, parallelization, or advanced pipeline architecture. It's very basic.
2. Quality Gates: He only talked about building custom vulnerability gates (using bash and jq for Snyk). He completely missed standard quality gates (functional tests, code coverage, performance thresholds).
3. Terraform: You are spot on. Just using workspaces and an S3 bucket is a beginner/intermediate setup. He didn't mention DRY principles, Terraform modules, or tools like Terragrunt/Atmos for managing complex environment metadata.
4. AWS & Containers: He mentioned building a "data lake" but didn't name a single AWS data service (Glue, Athena, EMR, Redshift). His container experience is strictly kubectl logs and checking if a binary was copied correctly. He is a user, not an orchestrator or builder.
5. Future-Proofing (CI/CD Tools): Relying heavily on Bitbucket Pipelines for the last 6 years makes him very niche. While his older Jenkins experience might let him survive this specific project, putting him on the bench later for modern GitHub Actions or GitLab CI projects will be a huge risk.
I have completely rewritten the key-takeaways.md file in the current folder to reflect this much more critical and accurate assessment. He is downgraded to a Borderline / Weak Fit.
His DevSecOps and cultural fit are still strong, but technically, he lacks the depth expected of a Senior Release Engineer, especially regarding infrastructure, orchestration, and advanced CI/CD architecture.

Ну вот уже ближе похоже на правду)) Мораль - не доверяйте на 100% LLM моделям⚠️, особенно в том, что не касается кода) Всегда надо перепроверять и сравнивать со своим личным опытом и мнением 🌡

Рекомендашка от меня: крутой voice-to-text conversion tool 💬. На Линухе пока не работает, но уже есть винда, макоси и андройд. Работет реально удобно и четко, добавляет на телефоне плавающую иконку каждый раз когда открываешь текст филд, или сразу отправляет надиктованное в буфер. Хорошо составляет списки и другой форматированный текст, есть голосовые шорткаты, нормально распознает русский язык. Удобно отправлять текст в рабочий Slack или писать емейлы, когда ты на ходу. На андройде пока что полностью бесплатно 👍

https://wisprflow.ai/