Більшість AI coding tools зроблені як острови.

Ви обираєте один — Claude Code, OpenCode, Gemini CLI або Codex — і залишаєтеся в його workflow. Хочете другу думку? Треба скопіювати контекст, перейти в інший термінал, заново пояснити задачу, зачекати, порівняти відповіді й вручну перенести корисне назад.

Я зробив chorus, щоб прибрати цей крок.

Що це таке

chorus — open-source колекція плагінів, яка створює mesh делегування 4×3 між чотирма AI coding CLI:

Кожен агент може делегувати задачі трьом іншим, не виходячи зі свого інтерфейсу.

Інтеграція

Claude Code отримує slash commands:

/opencode:run refactor the auth module
/gemini:review check this diff for edge cases
/codex:run write tests for the new retry logic

OpenCode отримує MCP tools:

delegate_claude("review this migration for data loss risk")
delegate_gemini("analyze this for performance bottlenecks")
delegate_codex("add integration tests")

Gemini CLI і Codex отримують skills — встановіть раз, потім просто скажіть агенту делегувати природною мовою.

Workflow, який реально важливий

Паралельне code review. Даєте трьом різним агентам один diff незалежно, кожен із різним фокусом:

/gemini:review — correctness та edge cases
/codex:run    — test coverage
/opencode:run — архітектура та спрощення

У різних моделей різні слабкі місця. Один пропустить edge case, який інший спіймає. Один перебільшить архітектурні деталі, де інший помітить відсутній тест. Ви читаєте всі три відповіді й приймаєте рішення. Агенти надають матеріал, judgment залишається за вами.

Встановлення

# Claude Code
claude plugin install https://github.com/valpere/chorus

# OpenCode
opencode plugin @valpere/chorus-opencode

Повне встановлення для Gemini CLI та Codex — у README.

chorus не намагається стати новою IDE або orchestration platform. Це plumbing між інструментами, якими розробники вже користуються. Одна інсталяція, чотири агенти, жодних нових workflow.

https://github.com/valpere/chorus

Six months ago I started using Claude Code as a primary development tool on client work. Not as an autocomplete or a rubber duck, but as a structured part of a repeatable workflow. Here is what that actually looks like in practice — with the warts included.

The Workflow in Four Stages

Stage 1: Planning. Before any code is written I produce a spec. Not a vague description — a numbered task list with acceptance criteria per task. Claude Code can operate well on a clear task, and it operates poorly on a hazy one. This stage is still 100% human; the AI has no place here until you know what you want.

Stage 2: Worktrees. Each task gets its own Git worktree (git worktree add). This is the part most people skip, and skipping it is why AI-assisted projects turn into spaghetti. Worktrees give each subagent a clean checkout with no side effects from other in-flight tasks.

Stage 3: Subagent-driven development. I invoke Claude Code in each worktree with a tightly scoped prompt: one task, one context window, one outcome. The context isolation is not a limitation — it is the feature. A subagent that cannot see the rest of your codebase cannot make assumptions about it. That forces the prompt to be complete.

Stage 4: Two-stage review. Every task gets reviewed twice. First pass: does the implementation match the spec? Second pass: code quality — naming, complexity, whether anything was invented that was not asked for (YAGNI violations are common in AI output). I use GitHub Copilot’s PR review for the second pass and have Claude Code apply the fixes. The combination works well: Copilot flags issues, Claude Code fixes them without arguing.

A Real Example: valpere.github.io Phase 1

My own site rebuild had 11 defined tasks — layout system, SCSS override, polyglot integration, portfolio pages, project pages, and so on. Each task was one worktree, one subagent invocation, one PR. Total wall-clock time across 11 tasks was roughly three days of calendar time, with maybe four hours of active human attention.

Two tasks that looked simple turned out to need careful prompting:

• SCSS override for Minima. Minima injects its own assets/main.scss via the gem. If your project also has assets/main.scss, Jekyll uses yours — but only if it has the right @import statements. The gotcha: the generated _site/assets/main.scss was empty on first run because the subagent created the file without importing anything. The fix was trivial once diagnosed, but the subagent had no way to know Minima’s convention without being told.

• Polyglot language switcher. jekyll-polyglot rewrites root-relative hrefs on non-default language pages. A language switcher that links to /about/ will rewrite to /uk/about/ when rendering the Ukrainian version — including the link that is supposed to stay on the same page. The solution is static_href Liquid tags, which polyglot explicitly skips. But the subagent used standard <a href> because that is the obvious thing to do. The prompt needed to say “use static_href for the language switcher links” explicitly.

The Copilot + Claude Combination

GitHub Copilot’s PR review is good at catching style issues and potential bugs in isolation. Claude Code is good at applying fixes in context. Running both on every PR takes maybe ten extra minutes per task and has caught real problems — duplicate logic, missing error handling, and one case where the subagent added a configuration option nobody asked for.

The Real Gotchas

The most painful non-code issue: my global ~/.gitignore_global had an _* pattern to ignore scratch directories. Jekyll’s _layouts/, _includes/, _data/, and _posts/ all match that pattern. The worktrees looked clean but were missing critical directories. This took about an hour to diagnose because git status showed nothing wrong — the files were not untracked, they were invisible.

The Tradeoff

Subagents need precise prompts. That is both the cost and the discipline. Writing a precise prompt forces you to actually think through the task before coding it, which is not a bad habit regardless of tooling. The context isolation means no agent accumulates state or makes cross-task assumptions. You give up the convenience of “the AI remembers what we discussed” and gain reproducibility.

If a task requires subtle judgment about cross-cutting concerns — security, data modeling, novel algorithms — I write that code myself. AI is a force multiplier on execution, not a replacement for design.

Most scraping tools are either a thin wrapper around an HTTP client or a full browser automation harness. DataScrapexter sits between those extremes deliberately, and the architecture reflects that choice.

The Four-Tier Service Model

DataScrapexter is offered as a tiered service, and the tiers are not just pricing — they correspond to meaningfully different technical configurations:

• Basic: Static HTML sites. Colly handles fetch and parse; no browser involved.
• Standard: Sites with light JavaScript rendering. Colly fetches; a small post-processing step handles common SPA patterns like <script type="application/json"> data islands.
• Professional: Full JS rendering required. chromedp drives a headless Chromium instance; Colly is not involved in the fetch path.
• Enterprise: Anti-bot bypass, residential proxy rotation, CAPTCHA solving, custom extraction logic. The pipeline is the Professional tier plus a detection-bypass middleware layer.

This tiering is reflected in the codebase as a factory pattern: a FetcherFactory takes a config struct and returns a Fetcher interface. The caller never instantiates Colly or chromedp directly.

The Pipeline

Every request flows through five stages regardless of tier:

Fetcher → Detector Bypass → Extractor → Normalizer → Formatter

Fetcher handles the HTTP lifecycle — connection pooling, retry logic, rate limiting, and cookie jar management. For Colly-backed tiers, this wraps colly.Collector with additional middleware. For chromedp tiers, it wraps a chromedp.Context with page lifecycle hooks (wait for network idle, scroll to trigger lazy loads, etc.).

Detector Bypass is a no-op in Basic/Standard tiers. In Professional and Enterprise it injects realistic browser fingerprints: User-Agent rotation, Accept-Language, TLS fingerprint normalization, and timing jitter between requests. The middleware is a chain of func(req *Request) error steps, so individual bypass techniques can be swapped or composed without touching surrounding code.

Extractor takes the raw HTML (or DOM snapshot from chromedp) and applies CSS selectors or XPath expressions defined in a scraping config file (YAML or JSON). The config schema is the same across all tiers. An extractor produces a map[string]interface{} per scraped entity.

Normalizer applies type coercion, cleaning rules (trim whitespace, strip HTML tags, parse prices/dates), and field renaming. The normalization rules live in the same config file as the selectors, under a transforms key.

Formatter serializes to the requested output: JSON, CSV, or XLSX. Each format has its own Formatter implementation behind a format.Formatter interface. Adding a new output format is a single struct implementing two methods.

Concurrency Model

DataScrapexter uses a worker pool pattern with configurable parallelism:

pool := scraper.NewWorkerPool(cfg.Workers, fetcher, extractor)
pool.Submit(urls)
results := pool.Drain()

Workers defaults to 5 for Basic, 3 for Professional (chromedp instances are heavier), and is user-configurable up to tier limits. The pool manages a semaphore channel to cap goroutines and a results channel that the formatter drains. Errors are collected separately and reported after all URLs are processed.

Why Colly and chromedp Coexist

The obvious question is why not use chromedp for everything. Two reasons:

1. Performance. A Colly-based fetch completes in ~50ms per page. A chromedp fetch, including browser launch amortization, is closer to 500ms with a warm pool. For a job scraping 10,000 product pages, that difference is roughly 11 hours.

2. Detectability. Headless browsers have well-known fingerprints. Running chromedp against a site that does not need JS rendering increases detection risk without benefit.

The factory pattern means the calling code is identical regardless of which fetcher is active. Switching a site from Colly to chromedp is a one-line config change.

Config-Driven Design

The entire extraction logic is in YAML, not code. A client can change selectors, add fields, or adjust normalization rules without a deployment. This was a deliberate design decision: the framework is a runtime that interprets scraping specs, not a collection of site-specific scrapers baked into the binary.

site: example-shop
base_url: https://example.com/products
pagination:
  selector: "a.next-page"
  max_pages: 50
fields:
  - name: title
    selector: "h1.product-title"
  - name: price
    selector: "span.price"
    transform: parse_price
  - name: sku
    selector: "[data-sku]"
    attribute: data-sku
output:
  format: csv
  path: ./output/products.csv

This approach keeps the core framework stable while client-specific logic stays in version-controlled config files rather than forked code.

The client runs a small e-commerce operation — handmade goods, 50 to 80 orders on a busy day. Every morning started the same way: open Nova Poshta, check each tracking number, open KeepinCRM, move each deal to the matching stage. Forty-five minutes, every day, on a task a machine should own.

The Problem

Manual order tracking at that volume is not just tedious — it is error-prone. Missed status changes meant delayed follow-ups. Parcels returned to sender because nobody noticed the “storage expires in 2 days” status until day three. Fiscal receipts were generated manually after confirmation of delivery, which sometimes meant forgetting entirely.

The client had KeepinCRM configured with deal stages that mapped directly to parcel lifecycle states: Shipped, In Transit, Awaiting Pickup, Delivered, Return Initiated, Returned. The mapping was clear. The problem was that someone had to perform it manually, twice a day.

The Solution

A Go daemon running on a small VPS, polling Nova Poshta’s tracking API every 30 minutes and driving a pipeline of three downstream actions.

Stage 1: Nova Poshta Polling

Nova Poshta provides a JSON API for tracking. The daemon maintains a SQLite table of active tracking numbers with their last known status. On each poll cycle:

statuses, err := np.GetTrackingStatuses(ctx, activeTTNs)
for _, s := range statuses {
    if s.StatusCode != cache.Get(s.TTN) {
        events <- TrackingEvent{TTN: s.TTN, OldStatus: cache.Get(s.TTN), NewStatus: s.StatusCode}
        cache.Set(s.TTN, s.StatusCode)
    }
}

Nova Poshta’s status codes are numeric. The daemon maps them to KeepinCRM stage names via a config file — the client can adjust the mapping without a code change.

Stage 2: KeepinCRM Pipeline

KeepinCRM has a REST API for deal management. When a tracking event arrives, the daemon finds the deal associated with that tracking number (stored at deal creation time as a custom field) and moves it to the target stage:

dealID, err := crm.FindDealByTTN(ctx, event.TTN)
if err != nil { log.Error(...); continue }
err = crm.MoveDeal(ctx, dealID, stageMap[event.NewStatus])

If FindDealByTTN returns nothing — the deal was closed, archived, or the TTN was entered incorrectly — the event is logged and a Telegram message is sent to the client’s ops chat. No silent failures.

Stage 3: Fiscal Receipts via Checkbox

Ukraine requires fiscal receipts for retail sales. The client was using Checkbox, which has an API for programmatic receipt generation. When a deal moves to Delivered, the daemon fetches the deal’s line items from KeepinCRM and fires a receipt creation request to Checkbox:

if event.NewStatus == StatusDelivered {
    items, err := crm.GetDealLineItems(ctx, dealID)
    receiptID, err := checkbox.CreateReceipt(ctx, items, deal.CustomerPhone)
    crm.AddNote(ctx, dealID, "Fiscal receipt: "+receiptID)
}

The receipt ID is written back to KeepinCRM as a deal note. The client can pull it up immediately if a customer asks.

Stage 4: TurboSMS Notification

The final step sends an SMS to the customer when the parcel status changes to Awaiting Pickup — the most time-sensitive notification, since Nova Poshta storage is limited to five business days.

TurboSMS has a straightforward HTTP API. The message template is configurable:

Your order #{order_id} is waiting at {branch_address}. 
Storage until {expiry_date}. Track: https://novaposhta.ua/tracking/#{ttn}

The branch address and storage expiry date come from the Nova Poshta tracking response.

Results

After two weeks of running in parallel with manual tracking (to validate correctness), the client switched to fully automated operation:

• Zero manual deal moves since go-live. The daemon processes 150–200 tracking events per day.
• Fiscal receipts generated automatically for every delivered order. Previously, about 15% were missed or delayed.
• Approximately 2 hours per day recovered — the morning tracking session and an afternoon check-in that were both eliminated.
• Two return-to-sender events caught early in the first month that would have been missed under the manual process.

The daemon has been running for four months. The only operational intervention was a Nova Poshta API schema change that broke status code parsing for three hours — caught via Telegram alert, fixed with a config update, no data loss.

Vibe coding — the practice of describing what you want and letting an AI generate the implementation — is real and productive. It is also a reliable way to accumulate technical debt at AI speed if you treat the AI as a replacement for engineering discipline rather than an accelerant.

The issue is not the AI. The issue is that the habits that make hand-written code maintainable do not enforce themselves just because you switched to prompted code.

YAGNI Still Applies

AI models are trained to be helpful. When you ask for a user authentication system, a helpful model will often give you authentication plus password reset, plus session management, plus an admin flag on the user model, plus email verification — because those things often go together and the model is pattern-matching on codebases where they do.

This is YAGNI violation at generation speed. You did not ask for those things, you do not need them yet, and now they are in your codebase requiring maintenance, testing, and decision-making.

The fix is specificity in prompts. “Implement JWT authentication — just the middleware that validates a token and sets a context value, nothing else” produces a dramatically different result than “implement authentication.”

Specs Before Code

The most productive use of AI in development is not asking it to figure out what to build. It is asking it to build a thing you have already figured out. This means writing a spec first.

A spec does not need to be elaborate. For a single task it might be four bullet points:

- Accept a POST /webhooks/stripe body
- Validate the Stripe-Signature header using STRIPE_WEBHOOK_SECRET from env
- On payment_intent.succeeded, call OrderService.MarkPaid(paymentIntentID)
- Return 200 on success, 400 on invalid signature, 500 on internal error

That spec constrains the AI to what you actually want. Without it, the model will make choices — about error handling, about what to log, about whether to add a retry queue — and some of those choices will be wrong for your context.

Review Still Matters

AI output requires the same code review scrutiny as output from a junior developer. The AI does not know your conventions, your security model, or what you decided last sprint. It knows common patterns, which is not the same thing.

Things to specifically look for in AI-generated code:

• Invented abstractions. A function that was supposed to fetch a user instead returns a result type with three fields, two of which you did not ask for and one of which shadows a name in an outer scope.
• Inconsistent error handling. The happy path is fine; the AI often gets bored with error handling and uses a different pattern for the third error case.
• Missing input validation. AI will validate inputs that appear in its training data for similar functions. It will skip validation for inputs that seem “internal” to the application.
• Silent failure modes. Goroutines that panic without recovery, channels that can deadlock, contexts that are not propagated.

The Subagent Pattern

One long conversation with an AI is a trap. The model’s context window fills with earlier decisions, and later outputs are implicitly constrained by them — including bad decisions made early that were never corrected.

The subagent pattern: one task, one fresh context, one review. Isolate each task into a focused prompt that includes everything the AI needs and nothing it does not. This produces more predictable output and makes it easier to review because the scope is bounded.

In practice this means using git worktrees per task and invoking a new Claude Code session per worktree. The overhead is low; the predictability gain is significant.

When Not to Use AI

There are categories of code where AI assistance is actively harmful:

Security-sensitive code. Authentication flows, cryptographic operations, access control checks. These require getting the exact right thing right the first time. AI will produce plausible-looking code that has subtle flaws — timing attacks, missing validation in edge cases, incorrect use of a crypto primitive. Read the spec, implement it yourself, have a second human review it.

Novel algorithms. If the algorithm you need does not exist in common form in AI training data, the AI will approximate it with something that looks similar but is not correct. This is the worst failure mode: code that looks right, passes obvious tests, and fails in production on edge cases.

Regulatory compliance logic. Tax calculations, GDPR right-to-erasure implementation, financial rounding rules. The consequences of getting these wrong are not a debugging session; they are legal or financial exposure. Understand the spec yourself.

AI is a genuine productivity multiplier for the large majority of implementation work that is routine. The discipline is knowing which parts are not routine.

GitHub Pages Will Not Run Polyglot

GitHub Pages maintains a whitelist of allowed Jekyll plugins. jekyll-polyglot is not on it. If you add it to your _plugins/ directory or Gemfile and push, GitHub Pages will silently build without it — no error, just a site with no language support and some broken links.

The fix is to take the build out of GitHub Pages entirely and use GitHub Actions to build and deploy:

# .github/workflows/deploy.yml
name: Deploy Jekyll site
on:
  push:
    branches: [main]
jobs:
  build-deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: ruby/setup-ruby@v1
        with:
          ruby-version: '3.3'
          bundler-cache: true
      - run: bundle exec jekyll build
      - uses: peaceiris/actions-gh-pages@v3
        with:
          github_token: $
          publish_dir: ./_site

The peaceiris/actions-gh-pages action pushes _site/ contents to the gh-pages branch, which GitHub Pages serves as a static host. You lose the simplicity of push-to-deploy, but you gain full plugin support.

The URL Rewriting Surprise

Polyglot’s core feature is rewriting URLs on non-default-language pages so that /about/ becomes /uk/about/ when building the Ukrainian version. This happens automatically for all root-relative hrefs in your HTML output.

The surprise: this includes your language switcher.

If your language switcher has a link like <a href="/uk/about/">English</a>, polyglot will rewrite it to /uk/about/ on the Ukrainian page — which means clicking “English” keeps you in Ukrainian. A self-link, invisibly.

The fix is static_href:

{% static_href %}href="/uk/about/"{% endstatic_href %}

Polyglot sees this tag and leaves the URL alone regardless of which language page is being built. It is not pretty Liquid, but it is the correct tool for links that must not be localized.

data-no-localization Does Not Work for Relative URLs

The polyglot docs mention a data-no-localization attribute that is supposed to prevent URL rewriting on specific elements. In practice, this works for absolute URLs (https://...) but not for root-relative URLs (/path/to/page). The rewriting logic does not check for this attribute on relative href values.

This is not a bug in your configuration. Use static_href tags for language switcher links. Do not spend an afternoon tweaking data-no-localization attributes.

Gemfile and Git

Many Jekyll project templates list Gemfile.lock in .gitignore but do not track Gemfile at all — the assumption being that the Gemfile is “obvious” local configuration. This breaks badly when you add GitHub Actions to your build, because the Actions runner starts fresh with no Gemfile.

Make sure both Gemfile and Gemfile.lock are committed:

git add Gemfile Gemfile.lock
git commit -m "Track Gemfile and lock for CI"

The Gemfile.lock pin ensures the Actions runner uses exactly the same gem versions you tested locally, which prevents the “works on my machine, fails in CI” failure mode.

The Global Gitignore Trap

This one took an embarrassingly long time to diagnose. My global ~/.gitignore_global included the pattern _*, which I had added years ago to ignore scratch directories prefixed with underscores.

Jekyll’s content directories are all prefixed with underscores: _layouts/, _includes/, _data/, _posts/, _sass/. All of them matched the global ignore pattern. Git would not track them.

git status showed a clean working tree. git add _layouts/ silently did nothing. The site built locally because the files existed on disk; it failed in CI because they were never committed.

The fix is explicit negation in the project’s .gitignore:

# Undo global _* ignore for Jekyll directories
!_layouts/
!_includes/
!_data/
!_posts/
!_sass/
!_config.yml

Alternatively, remove the _* pattern from your global gitignore if you do not actually need it. I kept the project-level negation because other machines might have the same global pattern.

One More: Exclude Directories from Localization

By default, polyglot will try to localize everything, including your assets/ directory. This produces duplicate copies of your CSS and images under /uk/assets/, which is wasteful and can cause caching issues.

Add explicit exclusions in _config.yml:

exclude_from_localization:
  - assets
  - robots.txt
  - sitemap.xml

Polyglot will leave these paths alone when building non-default language versions.

Once all these pieces are in place, the polyglot setup is genuinely clean: one source file per piece of content, lang: in the front matter, and the plugin handles the rest. Getting to that point just requires knowing where the traps are.

«…більшість питань і суперечок, що бентежать людство, залежать від сумнівного і невизначеного вживання слів або (що те саме) невизначених понять…» – Джон Локк, Дослід про людське розуміння, Послання до читача (1690)

💡 Про що мова?

В цьому році з’явилося багато термінів, які описують новий інструмент розробки – ШІ.

Одразу, як завжди, почалися дискусії про смак різноколірних олівців, бо одні вважають що від цього можна отримувати задоволення, а інші, що можна тільки для розмноження та й то лише після благословіння церкви.

В принципі можна взяти будь які правила або найкращі практики розробки чи інженерії та замінити там назву будь якого інструменнту на “ШІ” і можеш лупашити ними опонентів прямо в тім’ячко.

Поки бажаючі знавці обмацують цього слона і сперечаються про те, що вони намацали чи відчули, спробуємо визначитися з термінологією.

Треба щось просте і зрозуміле, щоб одразу тицьнути туди на мапі де ми зараз є.

Я теж вмію в розумні слова і тому спробуємо парадигмальний підхід.

Далі – без іронії. Спробуємо зафіксувати робочі визначення.

Мета цього документу – не оцінювати ШІ як “добре / погано”, а дати спільну мову для обговорення: що саме ми зараз робимо, який рівень ризику приймаємо, і які практики доречні у вибраному підході.

🧩 Парадигми: короткі описи

🔍 Vibe Coding

Vibe Coding – це підхід, при якому розробник описує бажану функціональність мовою, зрозумілою для людини, і генерує код за допомогою ШІ без детального перегляду або редагування результату. Акцент робиться на експериментуванні, швидкому прототипуванні та довірі до ШІ, а не на ручному написанні або перевірці кожного рядка коду.

Намір → ШІ → Код

• ШІ пише код на основі наміру високого рівня
• Мінімальний перегляд, мінімальна структура
• Максимальна швидкість, максимальний ризик

Використовувати, коли

• Прототипи
• Демо-версії
• Спайки
• Одноразовий код

Ніколи не використовувати для

• Продакшен систем
• Основної логіки
• Шляхи, чутливі до безпеки

🔍 AI-assisted development

AI-assisted development (AIAD) – це використання інструментів штучного інтелекту для підтримки розробника на різних етапах розробки: від написання коду, тестування та налагодження до оптимізації та автоматизації повторюваних завдань. Розробник залишається активним учасником процесу, а ШІ виступає як помічник, що пропонує ідеї, автоматизує рутину та покращує якість коду.

Розробка під керівництвом людини з використанням ШІ як інструменту

• Людина володіє архітектурою та рішеннями
• ШІ прискорює реалізацію
• Застосовуються стандартні перевірки та тестування

Використовувати, коли

• Написання виробничих функцій
• Підтримка тривалих кодових баз

🔍 AI-Powered Pair Programming

ШІ-помічники працюють разом із розробником у реальному часі, пропонуючи альтернативи, виявляючи помилки, оптимізуючи код та навіть генеруючи нові функції на основі контексту. Такий підхід зменшує час на зневадження та покращує архітектуру проєктів.

Людина ⇄ ШІ в режимі реального часу

• Постійний діалог
• ШІ пропонує, людина вирішує
• Порівнянно з поєднанням програмування з сильним молодшим/середнім розробником

Використовуйте, коли

• Повсякденна розробка
• Вивчення незнайомих кодових баз або мов

🔍 Generative AI for Specification and Design

ШІ використовується для автоматичної генерації архітектурних рішень, діаграм, документації та навіть тестових сценаріїв на основі вимог. Це дозволяє швидко отримати прототип системи та перевірити її на відповідність бізнес-вимогам.

Вимоги → ШІ → Специфікації / Діаграми

• ШІ допомагає до кодування
• Генерує чернетки специфікацій, архітектурних діаграм, планів тестування
• Людина перевіряє та вдосконалює

Використовуйте, коли

• Проектування системи
• Дослідження архітектури
• Ранні етапи планування

🔍 AI-Augmented Spec-Driven Development

AI-Augmented Spec-Driven Development – це парадигма, в якій структуровані специфікації (вимоги, архітектурні обмеження, критерії прийняття тощо) є основним джерелом для генерації коду за допомогою ШІ. Ці специфікації стають єдиним джерелом істини, яке ШІ перетворює на реалізацію, тести та документацію. Такий підхід забезпечує високу узгодженість між вимогами та реалізацією, скорочує ризики помилок і підвищує швидкість розробки.

Специфікація → ШІ → Код + Тести

• Специфікація є джерелом істини
• ШІ генерує код і тести на основі специфікацій
• Найвища передбачуваність і зручність обслуговування

Використовується в таких випадках

• Основна бізнес-логіка
• Фінансові, безпекові або регульовані системи
• Великі кодові бази з тривалим терміном експлуатації

🔍 AI-Driven Development (AIDD)

Це парадигма, де ШІ глибоко інтегрований у всі етапи розробки – від проєктування та написання коду до тестування, оптимізації та навіть розгортання. Розробник і ШІ працюють як партнер, що значно підвищує продуктивність і якість коду.

Людина + ШІ спільно керують процесом

• ШІ бере участь у проектуванні, кодуванні, тестуванні та оптимізації
• Людина залишається відповідальною за стратегію та обмеження

Використовувати, коли

• Команди навмисно впроваджують ШІ в SDLC
• Існують чіткі обмеження та процеси оцінки

🔍 Autonomous Refactoring та Adaptive Coding

ШІ автоматично аналізує та рефакторить код, виявляючи потенційні проблеми, пропонуючи оптимізації та адаптується до змін у проєкті. Такі системи можуть навчатися на великій кількості коду, щоб краще розуміти контекст та вимоги проєкту.

Існуючий код → ШІ → Вдосконалений код

• ШІ рефакторує, оптимізує та зменшує технічний борг
• Працює за суворими правилами та підлягає оцінці

Використовується, коли

• Контрольований рефакторинг
• Оптимізація продуктивності
• Вдосконалення стилю та узгодженості

🔍 Pipeline Synthesis та Security Scanning Orchestration

ШІ може автоматично генерувати конфігурації CI/CD, аналізувати безпеку коду, виявляти технічний борг та пропонувати шляхи його усунення. Це зменшує ризики та прискорює процес розгортання.

Політика → ШІ → CI/CD та автоматизація безпеки

• ШІ генерує та підтримує конвеєри
• Автоматизує сканування безпеки та забезпечення дотримання політик

Використовувати, коли

• Автоматизація DevSecOps
• Зниження операційного ризику

🔍 AI-Agent Driven Development

ШІ-агенти можуть самостійно виконувати певні завдання – від генерації коду за специфікаціями до автоматичного створення тестів, моніторингу та навіть виправлення помилок у продакшені. Це дозволяє створювати самоохоронні системи, які мінімізують втручання людини.

Мета → ШІ-агенти → Виконання

• Автономні агенти розкладають та виконують завдання
• Мінімальне втручання людини

Використовувати з особливою обережністю

• Внутрішні інструменти
• Чітко обмежені завдання автоматизації

🔍 Self-Healing Systems

ШІ-агенти моніторять систему у продакшені, виявляють проблеми, генерують латки та автоматично їх застосовують, забезпечуючи високу надійність та мінімізуючи простої.

Сигнали під час виконання → ШІ → Виправлення → Розгортання

• ШІ контролює продакшен та автоматично застосовує виправлення
• Найвища автономність, найвищий ризик

Не рекомендується за замовчуванням

• Тільки з суворими запобіжними заходами
• Тільки для некритичних систем

📊 Порівняльна таблиця

🌳 Парадигми розробки за допомогою ШІ – Дерево рішень

Дерево рішень про те, про що в будь-який конкретний момент йдеться. Це дерево визначає режим розробки, а не конкретний інструмент.

🏢 Політики

🟢 Дозволено за замовчуванням

• Розробка за допомогою ШІ
• Парне програмування за допомогою ШІ
• Рефакторинг з рев’ю

🟡 Дозволено за умови явного схвалення

• Розробка на основі специфікацій за допомогою ШІ
• Код, згенерований ШІ, у базовій логіці
• Будь-який ШІ у регульованих доменах

🔵 Тільки для операційної діяльності

• Генерація CI/CD
• Сканування безпеки
• Забезпечення дотримання залежностей та політики

🔴 Явно заборонено

• Розробка на основі ШІ-агентів у продакшені
• Системи самовідновлення
• Автономні зміни у продакшені без схвалення людини

В цілому

ШІ не змінює інженерію. Він лише робить її помилки швидшими – або керованішими.