Веб-розробка в епоху ШІДоповідь

Якщо ШІ вже пише код, навіщо потрібен розробник?

Від HTTP і баз даних до архітектури, продакшену та відповідальності за систему

Теза02 / 27

ШІ різко знижує вартість створення коду, але не знижує вартість правильного інженерного рішення.

Цінність розробника зміщується від здатності написати код до здатності зрозуміти проблему, спроєктувати систему, керувати її створенням і перевірити результат.

Що змінилося03 / 27

Рівні роботи з ШІ

Автодоповнення

Людина пише код, ШІ підказує наступні рядки

Асистент

«Напиши endpoint», «створи тест», «знайди помилку»

Агент

Агент сам бере задачу з трекера, читає код, змінює файли, запускає тести і відкриває pull request

Агентний процес

Людина керує процесом: вимоги, план, реалізація, тести, рев'ю, деплой

Що залишається людині, якщо ШІ може пройти майже весь цикл?

Що змінилося04 / 27

Розробник-виконавець втрачає цінність

Вже сьогодні

Задача в Jira→Агент→Код і тести→Pull request

Виконавець задач

Бере задачу з таск-менеджера
Реалізує рівно так, як написано
Не з'ясовує, навіщо ця задача
Відповідає за код, а не за результат

Інженер

З'ясовує, яку проблему вирішує задача
Уточнює вимоги, межі й допустимі компроміси
Бачить, як зміна вплине на всю систему
Перевіряє результат агента і відповідає за нього

Якщо ваша робота полягає в тому, щоб взяти задачу з Jira і перетворити її на код, цю роботу вже виконує агент: швидше і дешевше.

Що змінилося05 / 27

ШІ знає лише той контекст, до якого має доступ

Неявні бізнес-вимоги
Історію рішень команди
Реальні обмеження бюджету

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

Якість роботи ШІ обмежена якістю контексту, який ми йому надали.

Що змінилося06 / 27

Нова навичка інженера: керування контекстом

Проблема→Вимоги→Обмеження→Архітектура→Контекст→ШІ→Реалізація→Перевірка

Що людина має передати ШІ:

Що будуємо і навіщо
Які є обмеження
Яка архітектура і домовленості в коді
Що вже існує

Що змінювати не можна
Які компроміси допустимі, а які неприпустимі
Як перевірити, що задачу виконано правильно
Prompt engineering лише мала частина цієї роботи

Як створюють ПЗ07 / 27

Хто і як створює ПЗ: команда і процеси

Керування задачами

Jira, YouTrack, Linear, Trello, ClickUp, Asana

Документація і знання

Confluence, Notion, вікі в GitHub і GitLab

Комунікація

Slack, Microsoft Teams, Discord

Код і рев'ю

GitHub, GitLab, Bitbucket: pull requests, code review

Дизайн і прототипи

Figma, Miro: макети, схеми, спільні дошки

Методології

Scrum, Kanban: спринти, беклог, ретроспективи

Добре описану задачу з Jira агент уже виконує сам. Цінність переходить до того, хто вміє таку задачу сформулювати.

Як створюють ПЗ08 / 27

Парадокс: щоб писати менше коду самому, потрібно краще розуміти систему

Як працює веб

HTTP/HTTPS, DNS, TCP/IP, TLS-сертифікати

Frontend

HTML, CSS, JavaScript і TypeScript, React або Vue

Backend

Node.js, Python, PHP, Go або Java; REST і GraphQL API

Бази даних

PostgreSQL, MySQL, MongoDB; індекси, транзакції

Git

Гілки, merge, pull requests, командна робота

Linux і термінал

SSH, процеси, права, логи, базове адміністрування

Без цього неможливо перевірити, чи правильний код згенерував ШІ.

Як створюють ПЗ09 / 27

Тестування: як переконатися, що все працює

Чим вище, тим повільніші й дорожчі тести. Чим нижче, тим їх має бути більше.

Модульні	Jest, Vitest, PyTest, JUnit
Інтеграційні і API	Supertest, Postman, Testcontainers
End-to-end	Playwright, Cypress, Selenium
Навантажувальні	k6, JMeter, Locust
Безпека і якість коду	OWASP ZAP, SonarQube, ESLint
Керування тестуванням	TestRail, Zephyr для Jira, ручне QA

ШІ швидко пише тести, але що саме і як перевіряти, вирішує інженер.

Як створюють ПЗ10 / 27

Приклад: код правильний, архітектура ні

Згенеровано ШІ

// зберігаємо файл на диск сервера
app.post('/upload', upload.single('file'),
  (req, res) => {
    res.json({ path: req.file.path });
  });

// 3 сервери за балансувальником:
// файл є лише на одному з них.
// Перезапуск контейнера: файл зник.

Рішення інженера

// файл іде в об'єктне сховище
await s3.send(new PutObjectCommand({
  Bucket: 'uploads',
  Key: fileId,
  Body: req.file.buffer,
}));

// віддаємо через CDN:
// cdn.example.com/uploads/{fileId}
// сервери без стану, масштабуються

Інфраструктура11 / 27

Що насправді означає запустити застосунок у реальному світі

Як запустити?	Docker, CI/CD, PaaS
Як масштабувати?	Балансувальники, Swarm, Kubernetes, CDN, кеш
Як зберігати?	Бази даних, об'єктні сховища, Redis, черги
Як зрозуміти, що зламалося?	Метрики, логи, трасування, дашборди
Як захистити?	TLS, секрети, OWASP

Спочатку проблема, потім технологія.

Інфраструктура12 / 27

Як запустити? Docker і Docker Compose

Docker: образи, контейнери, Dockerfile, томи, мережі
Однакове середовище на ноутбуці, тестовому і робочому сервері
Docker Compose: увесь застосунок описано в одному файлі
Одна команда запускає backend, базу, кеш і frontend

# docker-compose.yml
services:
  api:
    build: ./api
    ports: ["3000:3000"]
    depends_on: [db, redis]
  db:
    image: postgres:16
    volumes: [pgdata:/var/lib/postgresql/data]
  redis:
    image: redis:7
volumes:
  pgdata:

Інфраструктура13 / 27

Як доставляти зміни? CI/CD та інфраструктура як код

CI/CD

GitHub Actions, GitLab CI, Jenkins: автоматичний запуск тестів, збірка образів і деплой після кожного коміту

Інфраструктура як код

Terraform, Ansible: сервери, мережі й доступи описані в репозиторії

Хмари і хостинг

AWS, Google Cloud, Azure; простіше і дешевше: Hetzner, DigitalOcean

Інфраструктура14 / 27

Як запустити без ручного адміністрування? PaaS-платформи

Тип	Інструменти	Особливості
Хмарні PaaS	Vercel, Netlify, Heroku, Render, Railway, Fly.io	Зручно, без адміністрування, але дорожче при зростанні і прив'язка до провайдера
Self-hosted PaaS на власному VPS	Dokploy, Coolify, CapRover, Dokku, Easypanel	Дешево і повний контроль над даними, але сервер обслуговуєте ви
Керування контейнерами	Portainer	Візуальне керування Docker, Swarm і Kubernetes. Деплой стеків можливий, але збірку образів, домени, SSL і бекапи налаштовуєте самі

Під капотом Docker, Compose, Swarm і Traefik. Коли щось ламається, рятує розуміння саме цих технологій.

Інфраструктура15 / 27

Як масштабувати? Оркестрація контейнерів

	Docker Swarm	Kubernetes
Поріг входу	Низький, вбудований у Docker	Високий, багато нових понять
Основні поняття	Сервіси, стеки, репліки	Pods, Deployments, Services, Ingress
Масштабування	Ручне, за кількістю реплік	Автомасштабування за навантаженням
Коли обирати	Невеликі кластери, прості проєкти	Великі системи, багато команд і сервісів

Разом з цим: reverse proxy і балансувальники (Nginx, Traefik, Caddy), CDN, кеш. Керовані Kubernetes: EKS, GKE, AKS.

Інфраструктура16 / 27

Як зберігати дані і файли?

Бази даних

PostgreSQL, MySQL, MongoDB; Redis для кешу і сесій

Об'єктні сховища

Amazon S3, Cloudflare R2, MinIO: файли окремо від серверів, сервери без стану легко масштабуються

CDN

Cloudflare, CloudFront, Fastly: статика поруч із користувачем, захист від DDoS

Фонові задачі і обмін між сервісами: черги RabbitMQ, Kafka, Redis Queue

Інфраструктура17 / 27

Як зрозуміти, що зламалося? Системи моніторингу

Що відстежуємо	Інструменти	Навіщо
Метрики	Prometheus, Zabbix, VictoriaMetrics	CPU, пам'ять, диск, кількість і швидкість запитів
Логи	ELK-стек, Grafana Loki	Пошук причин помилок у записах усіх сервісів
Трасування	OpenTelemetry, Jaeger	Шлях одного запиту через усі мікросервіси
Помилки	Sentry	Винятки в коді з контекстом користувача
Доступність і алерти	Uptime Kuma, Alertmanager	Сповіщення в Telegram чи Slack, коли щось падає
Все в одному (SaaS)	Datadog, New Relic	Готове рішення без власної інфраструктури

Інфраструктура18 / 27

Як побачити стан системи? Візуалізація моніторингу

Grafana: дашборди з Prometheus, Loki, баз даних
Kibana: аналіз логів з Elasticsearch
Datadog, New Relic: вбудовані дашборди
Пороги, алерти і SLO прямо на графіках

Запити за секунду

1 240

Час відповіді, p95

184 мс

Навантаження CPU

api-162%

api-258%

worker87%

Помилки 5xx

0,3%

Інфраструктура19 / 27

Як захистити?

HTTPS всюди, автоматичні сертифікати Let's Encrypt
Firewall, закриті зайві порти, принцип мінімальних прав
Типові вразливості: XSS, SQL-ін'єкції, CSRF (OWASP Top 10)
Секрети поза кодом: змінні оточення, HashiCorp Vault, Kubernetes Secrets
Код від ШІ обов'язково проходить рев'ю на безпеку

Система в цілому20 / 27

Архітектура сучасного вебзастосунку

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

Система в цілому21 / 27

Обсяг знань в одній картині

Продуктове мислення

Цінність для користувача, метрики, гіпотези, MVP, пріоритети

Аналіз вимог

User stories, критерії приймання, нефункціональні вимоги

UX дизайн

Дослідження користувачів, сценарії, прототипи, юзабіліті-тести

UI дизайн

Figma, дизайн-системи, типографіка, доступність (a11y)

Архітектура

Системний дизайн, патерни, C4, OpenAPI, ADR

Команда і процеси

Jira, Confluence, Scrum, Kanban, Slack

Frontend

HTML, CSS, JavaScript, TypeScript, React, Vue

Backend і API

Node.js, Python, Go, Java, PHP, REST, GraphQL

Дані

PostgreSQL, MySQL, MongoDB, Redis, S3, MinIO

Тестування

Jest, PyTest, Playwright, Cypress, k6, SonarQube

Контейнери

Docker, Compose, Swarm, Kubernetes

Мережа і доставка

DNS, HTTPS, Nginx, Traefik, CDN, балансувальники, черги

Хмари і хостинг

Linux, VPS, AWS, Google Cloud, Azure, PaaS

Автоматизація

Git, GitHub Actions, GitLab CI, Terraform, Ansible

Моніторинг

Prometheus, Loki, Sentry, Grafana, Kibana, Datadog

Робота з ШІ

Агенти, контекст, специфікації, перевірка результату

Продукт і проєктуванняІнженерія та інфраструктураРобота з ШІ

Роль людини22 / 27

ШІ не замінює знання, а масштабує їх

Слабке розуміння×ШІ=швидше створення проблем

Сильне розуміння×ШІ=швидше створення рішень

Одна й та сама модель дає різну цінність залежно від того, чи здатна людина оцінити результат.

Роль людини23 / 27

ШІ виконує роботу, людина відповідає за рішення

ШІ може

аналізувати→планувати→писати→тестувати→шукати помилки→рефакторити→документувати→працювати з інструментами

Людина

Постановка проблеми

Яку проблему взагалі треба вирішувати?

Вимоги

Що насправді потрібно користувачу і бізнесу?

Архітектура

Як має виглядати система?

Компроміси

Які компроміси допустимі, а які неприпустимі. Агент не знає ціни помилки для бізнесу

Перевірка

Чи правильний результат видав ШІ?

Відповідальність

Хто відповідає, якщо система втратить дані, гроші або відкриє вразливість?

ШІ може сказати «це рішення правильне», але не може відповідати за його наслідки.

Роль людини24 / 27

Компроміси: чим можна пожертвувати, а чим ні

Допустимі компроміси

Моноліт замість мікросервісів на старті
Docker Compose або Swarm замість Kubernetes
Дані в кеші оновлюються із затримкою до 5 хвилин
Простий інтерфейс внутрішньої адмінки
Технічний борг із записаним планом виправлення

Неприпустимі компроміси

Втрата або дублювання платежів
Витік персональних даних, секрети в репозиторії
Міграція, що видаляє дані без резервної копії
Порушення вимог законодавства про захист даних
Зміна публічного API без погодження з клієнтами

Агент не знає ціни помилки для бізнесу, регуляторних вимог, домовленостей із клієнтами та історії інцидентів. Тому межі треба записати явно: у специфікації, AGENTS.md і критеріях приймання.

Агент оптимізує те, що бачить. Людина визначає, чим можна пожертвувати, а що недоторканне.

Висновок25 / 27

Код більше не є вузьким місцем

Раніше головним обмеженням була швидкість написання коду, і роль «взяв задачу, написав код» мала цінність. Тепер цю ланку закриває агент, а обмеженням стає здатність сформулювати, спроєктувати і перевірити систему.

Було

Задача з трекера→Розробник-виконавець→Код

Стає

Проблема→Інженер→Контекст і архітектура→ШІ-агенти→Код, тести, інфраструктура→Інженер→Перевірка→Продакшен

ШІ став між наміром людини та реалізацією. Але відповідальність нікуди не зникла.

Висновок26 / 27

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

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

Висновок27 / 27

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

Дякую за увагу! Запитання?