Agentic Engineer

4️⃣ Как BA меняют SDLC

Background-агенты могут работать на всех этапах разработки:
🔘Planning ⏩ анализ задачи
🔘Coding ⏩ генерация кода
🔘Testing ⏩ написание и запуск тестов
🔘CI/CD ⏩ проверка сборки
🔘Pull Request ⏩ создание PR
🔘Iteration ⏩ исправление CI-ошибок

То есть агент может пройти почти весь цикл разработки.

Self-Driving Codebase 🧐

@data_engi

3️⃣ Чем BA отличаются от обычных AI-ассистентов

Статья подчеркивает ключевое отличие.

Обычные AI-ассистенты (например Copilot chat):
🔘работают интерактивно
🔘помогают писать код строка за строкой
🔘требуют постоянного участия человека

Background agents
🔵асинхронные
🔵работают долго и автономно
🔵могут запускаться массово

По сути это виртуальные разработчики, а не автокомплит.

Self-Driving Codebase 🧐

@data_engi

2️⃣Что такое Background Agents (BA)

Background agents - это AI-агенты, которые:

🔘получают задачу (issue, feature, bug)
🔘работают в фоне
🔘выполняют многошаговый workflow
🔘возвращают результат (например PR)

Примеры задач:
🟡исправить баг
🟡добавить feature
🟡написать тесты
🟡обновить зависимости
🟡сделать refactoring

Разработчик описывает задачу 🔜 агент сам проходит цикл разработки.

Self-Driving Codebase 🧐

@data_engi

1️⃣ Основная идея - "self-driving codebase"

Автор вводит концепцию самоуправляемой кодовой базы.

Традиционно разработка строилась вокруг ограничения:
⏩человек сидит за клавиатурой и вручную выполняет все задачи.

Теперь появляется новый слой - AI-агенты, которые:
▶️работают автономно
▶️выполняют задачи без постоянного участия человека
▶️могут запускаться параллельно и долго работать

Это меняет модель разработки. Вместо "developer writes code" появляется developer delegates work to agents.

Self-Driving Codebase 🧐

@data_engi

Статья The Self-Driving Codebase: Background Agents and the Next Era of Software Delivery объясняет идею background-агентов - AI-агентов, которые выполняют задачи разработки автономно и асинхронно (в фоне), постепенно превращая кодовую базу в "self-driving codebase" - систему, где большая часть рутинной разработки выполняется автоматически.

✏️ Главная мысль статьи:

Следующая эра разработки - это не AI-подсказки, а автономные агенты, которые выполняют разработку в фоне.

Чуть подробнее опишу в серии постов:

1️⃣ Основная идея - "self-driving codebase"

2️⃣ Что такое Background Agents (BA)

3️⃣ Чем BA отличаются от обычных AI-ассистентов

4️⃣ Как BA меняют SDLC

5️⃣ Новая модель разработки

6️⃣ Почему это становится возможным сейчас

7️⃣ Ограничения и риски

8️⃣ Как будет выглядеть будущее разработки

@data_engi

Вы хотите, чтобы AI-агент следовал вашей дизайн-системе? Не просите – заставьте.

Ryan Carson описал 5-слойную систему, которая превращает дизайн-систему из «рекомендации» в жёсткий контракт. Работает с любым coding-агентом.

Перевод: Как заставить AI-агента подчиняться дизайн-системе
Оригинал: Ryan Carson

#AI #DesignSystem #CodingAgent #VibeCoding #DX

Павленко про Dev & AI 💻

Перегрет не рынок AI, а ваша лента. 84% планеты даже не начинали.

Наткнулась на картинку, которая буквально остановила меня посреди скролла.
Каждая точка это 3,2 миллиона человек. 2500 точек = 8,1 миллиард жителей Земли.
Цвет: самое продвинутое взаимодействие с AI на февраль 2026.
⬜️ Серые: 6,8 млрд человек, которые никогда не открывали ChatGPT.
🟩 Зелёные: 1,3 млрд, кто попробовал бесплатный чатбот.
🟨 Жёлтые: 15-25 млн, кто платит $20/месяц.
🟥 Красные: 2-5 млн, кто строит с AI.
Ты, скорее всего, жёлтая или красная точка. Топ 0,3% планеты.
И вот что важно понять, если ты строишь продукт или бизнес.
Мы все сидим в этой крошечной эхо-камере и слышим одно и то же: "Claude убил мой стартап", "зачем делать, если OpenAI это выкатит через месяц", "рынок уже перегрет".
Но посмотри на цифры. Для сравнения за Netflix платят 300 миллионов человек, а за Spotify Premium 260 миллионов. Это люди, которые уже привыкли отдавать $10-20 в месяц за цифровой продукт. До AI они просто ещё не дошли. Их в 10-20 раз больше, чем нынешних платящих пользователей AI.
6,8 миллиарда серых точек — это не абстракция. Это врачи, учителя, владельцы малого бизнеса, фермеры, юристы. Люди с реальными проблемами, реальными деньгами и практически ничем, что было бы создано с ними в голове.
В 2005 году интернетом пользовались те же 16% населения Земли. Именно после этой отметки появились Instagram, Uber, Airbnb, Notion, Duolingo — всё, что сейчас кажется очевидным. Тогда тоже говорили "всё уже занято, Google и Microsoft сделают это сами".
Рынок не перегрет. Перегрета эхо-камера, в которой мы все варимся.
Настоящая аудитория для твоего продукта ещё даже не знает, что он ей нужен.

Источники: визуализация — Damian Player (LinkedIn), интерактивная версия global-ai-adoption.netlify.app / данные по подпискам — Netflix Q4 2025, Spotify Q4 2025 / аналогия с 2005 — Alvin Foo, X

Чтобы перевести компанию на рельсы AI, достаточно везде надписи Loading.. поменять на Thinking..

@data_engi

#dev #memes #ai #llm #agent

https://openai.com/index/introducing-gpt-5-4/

Выкатили 5.4

Для тех, кто не в курсе кто такой Кнут - поясняю.

Дональд Кнут - один из главных людей в истории компьютерных наук.
Автор легендарной серии The Art of Computer Programming - книги, которую многие считают "библией алгоритмов".

Он создал систему вёрстки TeX, придумал множество фундаментальных алгоритмов и десятилетиями формировал саму основу компьютерной науки.

Если очень коротко: Кнут - это один из архитекторов современного программирования.

@data_engi

#dev #algo #knuth

⚡️ Дональд Кнут начал новую научную работу словами: "Shock! Shock!"

Claude Opus 4.6 за ~1 час решил открытую задачу из The Art of Computer Programming, над которой Кнут работал несколько недель.

Кнут проверил результат, оформил доказательство и назвал статью "Claude’s Cycles".

В конце он написал:

Похоже, мне придётся пересмотреть своё мнение о генеративном ИИ.

Работа:
https://cs.stanford.edu/~knuth/papers/claude-cycles.pdf

@data_engi

#math #ai #future #agi #llm #science

Всё чаще замечаю, как кандидаты используют LLM прямо во время собеса и думают, что незаметно.

Задаёшь вопрос, человек говорит «мне нужно минуту подумать», отводит глаза, начинает стучать по клаве. На лице пляшет свет от второго экрана. Или другой вариант — LLM слушает стрим звонка и сама пишет ответы поверх экрана, но на генерацию нужно время, поэтому человек берёт паузу и ждёт, пока текст появится. Потом гладко и структурировано выдает «важно учитывать множество факторов» с симметричным списком из трёх пунктов.

Перебиваешь, просишь уточнить конкретный момент — теряются. Уточнений то в ответе ллмки не было.

Когда человек реально понимает тему — это чувствуется. Он ссылается на конкретику, применяет фреймворк к задаче, может поспорить с постановкой вопроса. Копни на уровень глубже — и он туда спокойно идёт. А когда за ответом ничего нет, копнёшь — и человек буксует. Просит ещё минуту «подумать». Снова стучит по клаве.

Я не запрещаю LLM, было бы странно в 2026. Но если единственный навык кандидата — копировать ответы из чата и озвучивать, ну зачем он нужен, если я и сам могу отправить промпт?

Рано, ждём дальше.

@data_engi

#agi #ai #openai #llm

Дождались.

AGI или рано? 🤖

@data_engi

#ai #llm #openai #agi #release

https://discuss.python.org/t/pep-814-add-frozendict-built-in-type/104854/121
frozendict (аналог frozenset но для словаря) принят, будет реализован в 3.15.

Аналитические базы выступают в роли общего хранилища, куда стекаются данные из различных подсистем. Это могут быть OLTP базы, а также внешние сервисы (данные из которых можно тянуть по API, например). Процесс насыщения данными обозначают аббревиатурой ETL - Extract Transform Load. Но существует и другая аббревиатура ELT - Extract Load Transform. В первом случае трансформация данных происходит до загрузки в главное хранилище, а во втором уже на стороне хранилища (хранение в “сыром” виде).

Также есть процесс reverse ETL, это обратный процесс, когда данные из аналитической базы попадают в транзакционное хранилище. Например, такое практикуется при построении моделей машинного обучения и деплоя их в продакшн.

HTAP

Существуют и гибридные базы данных HTAP - Hybrid Transactional/Analytical Processing. Они сочетают в себе сразу 2 типа системы: транзакционное и аналитическое хранилище. Мотив простой: объединить всё в одну систему и исключить промежуточные процессы по загрузке данных из других систем. Я накопал пример такой БД: TiDB от PingCap. Не думаю, что основная цель таких БД заменить главное аналитическое хранилище, скорее решить специфическую задачу, где критически важно быстро обрабатывать операционные и аналитические запросы сразу без промежуточных этапов.

Data Lakes

Хранилище неструктурированных данных. Если OLTP и OLAP предъявляют требования по организации и хранению данных, то Data Lakes это своего рода помойка, где данные могут лежать в любом формате и виде: текстовые файлы, бинарные данные, данные в форматах по типу Parquet или Avro.

Designing Data-Intensive Applications

Глава 1. Trade-Offs in Data Systems Architecture

Введение

Первая глава книги получилась объёмной как по количеству страниц так и по количеству информации. По сравнению с первым изданием появилось упоминание Single-Node Data Warehouse решений на примере DuckDB, SQLite, но без деталей. Детали будут раскрываться уже в более поздних главах.

Основная мысль первой главы дать читателю понимание, что нет “серебряной пули”, и в каждом решении существуют как свои плюсы так и минусы (trade offs). Посыл авторов благородный, помочь читателю разобраться в море различных технологических решений. Дать фундамент, который будет помогать принимать правильные решения при проектировании архитектуры будущих приложений.

Что изменилось по сравнению с первым изданием? Первое издание книги вышло в 2017 году, с тех пор прошло 9 лет. Мир не стоит на месте, технологии развиваются. По словам авторов, в новом издании они постарались уделить достаточно внимания технологиям вокруг ИИ инфраструктуры, cloud native решениям на базе хранилищ объектов по типу Amazon S3, полностью переписали главу про Batch Processing из-за неактуальности MapReduce в наше время (при проектировании новых архитектур).

Конспект

Приложение считается Data-Intensive, если управление данными это одна из его ключевых задач.

Основные вызовы у таких приложений

— эффективная обработка и хранение большого массива данных
— обеспечение доступности данных в условиях отказа частей системы
— обеспечение согласованности данных (data consistency)

Главные строительные блоки

— Базы данных для хранения информации (например, PostgreSQL, MySQL, Microsoft SQL Server и т.д.)
— Кэш-системы для обеспечения быстрого доступа к данным (например, Redis, memcached)
— Поисковые движки для обеспечения быстрого поиска в большом массиве данных (Elasticsearch, Sphinx)
— Системы для потоковой обработки данных (Apache Flink, Apache Storm)
— Системы для пакетной обработки данных (Apache Hadoop, Apache Spark)

Примеры конкретных инструментов это моё личное дополнение, их множество, здесь приведены лишь наиболее популярные и те, что у меня на слуху. От себя я бы ещё добавил, что рука об руку с обработкой данных идут и различные оркестраторы и workflow-менеджеры по типу Apache Airflow, Oozie, Luigi, NiFi, Prefect, Dagster и т.д.

Типы баз данных

— Транзакционные (OLTP), авторы в книге также называют их операционными
— Аналитические (OLAP)

Транзакционные базы используются там, где данные берут своё начало, а именно базы для бэкенда приложения с которым пользователи взаимодействуют через фронтенд (веб-приложения, мобильные приложения и т.д.). Транзакционным базам присущи точечные запросы на чтение, запись, обновление или удаление. Например, по user_id. Запросы преимущественно формируются на стороне приложение, пользователь напрямую не имеет доступа к базе и не пишет запрос. Примеры: PostgreSQL, MySQL, Oracle DB, Microsoft SQL Server.

Аналитические базы данных используются для работы с данными для принятия решений на стороне бизнеса. Такие базы хранят в себе данные, собранные в том числе из транзакционных баз. Пользователями таких баз в основном являются бизнес и дата аналитики, Data Science специалисты. Зачастую они напрямую посылают запросы к базе, используя SQL. Запросы чаще всего большие и подразумевают обработку огромного набора данных (большие выборки). Примеры: Amazon Redshift, ClickHouse, Apache Druid, Pinot.

Современный подход к организации данных подразумевает четкое разделение между OLTP и OLAP. Но до массового внедрения OLAP транзакционные базы данных использовались и в качестве хранилища аналитических данных. Были придуманы способы моделирования аналитических данных с учётом ограничений реляционной модели, например, Star Schema, Snowflake Schema. В условиях современных OLAP баз данных такие подходы устарели.

Связь между OLTP и OLAP

@data_engi

#dev #memes #daily #созвон

Фраза дня:

Python является многопарадигмальным языком

Или на языке оригинала:

Python is a multiparadigm language

ref

@data_engi

#dev #py #python #book