ELT-Bench: An End-to-End Benchmark for Evaluating AI Agents
on ELT Pipelines

Достаточно интересный whitepaper, оценивающий способность агентов собирать end-to-end пайплайны.

Несмотря на зрелость AI агентов, значительная часть работы по-прежнему выполняется вручную, чтобы гарантировать корректность и согласованность данных.

На этом фоне логично ожидать, что ИИ сможет упростить разработку. Модели уже показывают сильные результаты в задачах вроде text-to-SQL и в целом уверенно работают с данными. Но если посмотреть шире, оказывается, что почти все существующие бенчмарки оценивают лишь отдельные навыки: написать SQL-запрос, воспользоваться инструментом, преобразовать данные. Полноценный end-to-end сценарий от источников до готовой модели, практически не покрыт.

ELT-Bench как раз пытается закрыть этот пробел.
Это сквозной бенчмарк, в котором собраны 100 пайплайнов, 835 исходных таблиц и 203 модели данных из разных доменов. Внутри максимально приближённые к реальности задачи: интеграция разнородных источников, работа с популярными инструментами, необходимость писать код и SQL, а также управлять всем процессом целиком.

Результаты получились интересными.
Даже лучший агент OpenHands CodeActAgent на базе Claude-3.5-Sonnet , корректно генерирует лишь 11,3% моделей данных.
В среднем на один пайплайн уходит 72 шага и около $1.41. Это уже не уровень отдельных функций или запросов, здесь проявляется вся сложность оркестрации, управления состоянием и зависимости между этапами.

Такой разрыв между локальными навыками и полноценной сборкой пайплайнов хорошо показывает, где сейчас проходит граница возможностей ИИ в дата-инжиниринге.

@tldr_data

Fivetran donates its SQLMesh data transformation framework to the Linux Foundation

Fivetran передаёт SQLMesh (свой фреймворк трансформаций на базе SQL, полученный после приобретения Tobiko Data в сентябре прошлого года) в Linux Foundation, чтобы продвигать вендор-нейтральное управление слоем трансформаций. SQLMesh добавляет в SQL-пайплайны тестирование, версионирование и процессы планирования/применения, похожие на Terraform. Стратегическая цель - влиять на формирование стандарта открытой дата-инфраструктуры (наряду с dbt) и ускорять внедрение за счёт владения со стороны сообщества.

@tldr_data

Bruin: Project Competition

Bruin - это инструмент для построения data-пайплайнов, который объединяет загрузку данных, их трансформацию с использованием SQL, Python и R, а также контроль качества данных в едином фреймворке. Он работает со всеми основными платформами данных и может запускаться на локальной машине, на экземпляре EC2 или в GitHub Actions.

Сейчас Bruin проводят интересный конкурс.

Нужно сделать data engineering проект с использованием Bruin.
Потом будет голосование, за лучший проект.

Призы достаточно крутые:

- Mac Mini for an outstanding project
- 1 year Claude Pro for the top 3 projects
- 1 month Claude Pro for participants

Deadline: Monday, June 1st, 12:00 UTC

@tldr_data

Claude How-To

Вы установили Claude Code, попробовали пару промптов и застряли.
Документация объясняет функции по отдельности, но не показывает, как собрать их в реальный workflow: связать slash-команды с хуками, памятью и субагентами.
Понятного пути обучения нет, что изучать сначала, MCP или hooks, навыки или субагентов?

В итоге всё просматривается поверхностно, а до продакшен-уровня дело не доходит.
Базовые примеры тоже не помогают: hello world не превращается в полноценный pipeline для code review с автоматическими проверками и делегированием задач.

В результате используется лишь малая часть возможностей, остальное просто теряется.

Этот курс закрывает пробел: 10 модулей, покрывающих весь функционал от slash-команд до команд агентных систем, (CLAUDE.md, hooks, MCP, субагенты, плагины), диаграммы Mermaid с разбором внутренней логики, и чёткий путь обучения, который за 11–13 часов доводит до уровня уверенного пользователя.

Плюс встроенная самопроверка через /self-assessment и /lesson-quiz прямо внутри Claude Code, чтобы быстро находить слабые места и закрывать их.

@tldr_data

Open Data Platform

Open Data Platform (ODP) - это набор инструментов с открытым исходным кодом, который позволяет дата-инженерам интегрировать проприетарные, лицензируемые и публичные источники данных в AI-копилоты и исследовательские дашборды через архитектуру:
подключи один раз, используй везде.

Платформа устанавливается через pip и работает в различных Python-окружениях, Excel, MCP-серверах для AI-агентов и REST API, а также интегрируется с корпоративным интерфейсом Workspace от OpenBB для визуализации и анализа данных.

@tldr_data

The Claude Code Source Leak: fake tools, frustration regexes, undercover mode, and more

У Anthropic утек исходный код Claude Code, именно CLI, потому что в npm-пакет уехал .map файл.

Код быстро удалили, но его уже успели разобрать по частям.

Пара вещей, которые бросаются в глаза.

Анти-дистилляция.
В запросы могут подмешиваться фейковые инструменты, чтобы ломать датасеты, если кто-то пишет прокси и логирует трафик. Есть ещё режим с суммаризацией вместо полного текста.
Оба механизма обходятся без особого напряжения. Выглядит скорее как не делайте так, чем как защита.

Undercover mode.
Модели прямо запрещают упоминать Claude Code, внутренние названия и вообще что-либо, что указывает на Anthropic. Выключить нельзя.
То есть AI-коммиты с их стороны в open source ничем не отличаются от обычных.

Детекция фрустрации:
regex со списком (wtf, this sucks и т.д.).
На фоне всего остального выглядит смешно, но получается, что это дешевле и быстрее любого LLM-вызова.

/\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|
piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|
fucking? (broken|useless|terrible|awful|horrible)|fuck you|
screw (this|you)|so frustrating|this sucks|damn it)\b/

Есть попытка привязать API к клиенту. В запросе placeholder, который на уровне Bun заменяется на хэш. Сервер проверяет, что это настоящий клиент. По сути DRM. Судя по коду — не особо жёсткий.

Из реального продакшена: были сессии с тысячами подряд ошибок, что сжигало ~250k API-вызовов в день. Фикс - лимит на количество неудач.

KAIROS - самый интересный кусок.
Зафлагованный режим автономного агента: фоновые процессы, cron каждые ~5 минут, GitHub вебхуки, ночная обработка памяти.
Похоже на always-on агента.

И важный момент: Anthropic недавно купили Bun, и Claude Code построен поверх него.
При этом в Bun есть баг, из-за которого source map может отдаваться в проде, хотя не должен. Если утечка произошла из-за этого - это буквально их же стек, который раскрыл их же код.

Upd: Буквально через пару часов, после того, как в сеть попал код Claude Code,
произошла параллельная supply-chain атака на пакет axios в npm.

Если вы устанавливали или обновляли Claude Code через npm 31 марта 2026 между 00:21 и 03:29 UTC, есть риск, что подтянулась вредоносная версия axios (1.14.1 или 0.30.4) с встроенным RAT. Стоит проверить lock-файлы (package-lock.json, yarn.lock, bun.lockb) на эти версии или зависимость plain-crypto-js. Если нашли, машину лучше считать скомпрометированной: перевыпустить все секреты и переустановить систему.

@tldr_data

Эволюция pgAdmin: от GUI к AI-ассистенту

pgAdmin впервые появился в 1998 году под названием pgManager - это более 28 лет разработки, вложенных в один GUI-инструмент для выполнения запросов и администрирования. (Он существует почти столько же, сколько и сам PostgreSQL)

Сейчас 2026 год, и pgAdmin получил очередное обновление.

В pgAdmin появилась новая функциональность на базе ИИ, и создатель проекта (Dave Page) разобрал все нововведения в серии из трёх блог-постов, чтобы вы получили полную картину. Можно из коробки работать с провайдерами LLM, такими как Anthropic, OpenAI, Ollama или Docker Model Runner, чтобы получать:

- AI-отчёты с анализом производительности, дизайна схемы и безопасности

- AI-инсайты по планам EXPLAIN / EXPLAIN ANALYZE

- AI-ассистента для преобразования запросов на естественном языке в SQL

Как он подытоживает в конце серии:

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

@tldr_data

MOTHERDUCK NOW SPEAKS POSTGRES

MotherDuck объявила о запуске нового Postgres-совместимого endpoint’а, который позволяет пользователям подключаться к своему хранилищу данных MotherDuck и выполнять запросы с помощью любого стандартного PostgreSQL-клиента, драйвера или BI-инструмента. Это дает командам возможность продолжать использовать PostgreSQL для транзакционных нагрузок, одновременно вынося быстрые аналитические запросы на серверлесс-вычисления MotherDuck.

@tldr_data

​📝 сделал демку с streaming lakehouse на опинсорсных технологиях (без confluent cloud и tableflow) и написал блог. Как раз к Iceberg Summit на след неделе.
Почитайте, покомментируйте

https://gamov.io/posts/streaming-lakehouse/

How to Structure an AI Project for Data Engineering

Небольше видео про то, как структурировать AI-проект в data engineering:

В центре файл CLAUDE.md, который используется как единая точка управления: через него задаются контекст, правила и ожидаемое поведение модели.
Это позволяет уйти от набора несвязанных промптов и выстроить более системную работу.

Также показывается, как такая структура соотносится с привычным prompt engineering, приводится пример организации AI-проекта и даются практические рекомендации по ускорению начальной настройки.

@tldr_data

SQL-first подход для PostgreSQL 🐘

pGenie — инструмент, строящий workflow вокруг SQL без лишних абстракций. Вы пишете SQL, система валидирует запросы, управляет индексами и генерирует type-safe SDK на основе миграций, исключая дублирование логики.

SQL становится источником правды для data-логики и контрактов между backend и БД. Это снижает ошибки, повышает прозрачность и упрощает поддержку в командах, работающих с SQL.

@tldr_data

Вы установили dbt_utils. Хорошее начало.

Вот список пакетов и инструментов, которые должны быть в каждом серьёзном dbt-проекте:

- dbt_utils — суррогатные ключи, date spine, pivot. Базовый минимум без компромиссов.

- dbt_expectations — более 50 типов тестов. Позволяет проверять то, что dbt не умеет из коробки.

- dbt_audit_helper — сравнение старых и новых результатов моделей перед релизом рефакторинга.

- dbt_codegen — генерация source YAML на основе вашей схемы.

- dbt_project_evaluator — автоматический аудит проекта на соответствие best practices.

- elementary — обнаружение аномалий, алерты по схеме, lineage.

- dbt_profiler — подсчёт null, уникальных значений, min/max — не выходя из dbt.

- dbt_external_tables — создание и управление внешними таблицами прямо в dbt.

- dbt-colibri — бесплатный column-level lineage для dbt-проектов.

Устанавливайте их по одному — и вы удивитесь, как раньше работали без них.

@tldr_data

AI Enablement Engineer: The Highest-Leverage Role in Tech

Интересная мысль от Maxime Beauchemin - человека, которого часто называют отцом data engineering.

Появляется новая роль внутри технологических компаний - её можно назвать AI Enablement Engineer.

Речь не про поверхностный AI enablement: обучающие сессии про промпты, подбор инструментов или внутренние гайды. Это почти не влияет на реальную скорость работы.

Речь про инженеров, которые строят инфраструктуру вокруг AI. Они делают контекстные слои, продумывают guardrails, собирают toolkits для агентов и встраивают это в реальные процессы. В результате не один человек разобрался с AI, а вся команда начинает быстрее решать задачи от аналитики до разработки.

Это даёт кратный рост скорости. И этот рост пока ничем не ограничен.

Такие инженеры работают не на уровне личной продуктивности. Их задача - разогнать всю команду. Не просто эффективно использовать AI самим, а сделать так, чтобы этим пользовались остальные и получали результат.

По сути, это один из самых сильных мультипликаторов эффективности, который сейчас формируется в индустрии. И приоритет у этого направления уже максимальный.

За последний год всё чаще видно, что путь к реальному импакту внутри компаний ведёт именно сюда. И это уже не просто тренд, а новая функция, которую начинают выделять отдельно.

@tldr_data

Claude Certified Architect

У Anthropic появилась сертификация.

Сертификация Claude Certified Architect - Foundations подтверждает, что специалист способен принимать обоснованные решения о компромиссах при внедрении реальных решений на базе Claude.
Экзамен проверяет базовые знания по Claude Code, Claude Agent SDK, Claude API и Model Context Protocol (MCP) - основным технологиям для создания production-приложений с Claude.

Так же на GitHub есть русскоязычный гайд для подготовки.
Выглядит как не плохой вариант разобраться с Claude Code.
Ну и сертификат не будет лишним.

@tldr_data

Apache Airflow 3.2 вышел.

Ниже представлены ключевые нововведения:

• Партиционирование ассетов (Asset Partitioning)
Запуск DAG’ов при обновлении конкретных партиций данных.

• Поддержка нескольких команд (Multi-team support)
Изолированные секреты и ресурсы для разных команд в рамках одного инстанса Airflow.

• Уведомления о дедлайнах (Deadline Alerts)
Уведомления в случае, если выполнение DAG занимает больше времени, чем ожидалось; альтернатива SLA.

• Поддержка асинхронных функций в PythonOperator
Нативный запуск async-функций (особенно актуально для AI-задач), без необходимости создавать кастомные операторы.

• Сравнение изменений кода (Diff) в Code View
Возможность отслеживать различия между версиями DAG непосредственно в интерфейсе.

• Кнопка копирования логов
Упрощает работу с логами за счёт быстрого копирования.

• Новый механизм плагинов на React
Расширенные возможности кастомизации пользовательского интерфейса Airflow.

• История согласований Human-in-the-loop
Отслеживание действий пользователей при одобрении или отклонении результатов AI.

• Индикатор версий DAG
Явное отображение различий между версиями DAG в Grid View.

P.S. Вебинар по Airflow 3.2 проходит сегодня.

@tldr_data

Semantic Layer vs. Text-to-SQL: 2026 Benchmark Update

Семантический слой не исчез, но его роль меняется.

В последнее время вокруг этой темы много разговоров:
одни списывают Semantic Layer, другие считают Text-to-SQL угрозой качеству данных. На практике оба подхода уже используются параллельно и решают разные задачи.

Text-to-SQL заметно прибавил в качестве.
Он хорошо работает для ad-hoc запросов: быстрые срезы, проверки гипотез, разовые вопросы. Можно получить черновой ответ без участия аналитика.

Но когда речь про метрики, то ситуация немного другая.
Semantic Layer по-прежнему даёт более точные результаты в прямом сравнении и фиксирует единую логику расчётов. Это критично для финансовых показателей, продуктовых KPI и любой отчётности, где одна и та же метрика должна считаться одинаково везде.

Причина простая: Semantic Layer задаёт единое определение метрик и делает его источником истины для всех инструментов.

При этом качество данных остаётся ключевым фактором. Улучшения в модели (структура, связи, naming) повышают точность и у Text-to-SQL, и у Semantic Layer - это подтверждается и практикой, и бенчмарками.

Как это использовать на практике:

Сначала исследование.
Аналитик или продукт задаёт вопрос и быстро получает ответ через Text-to-SQL.
Это этап, где важна скорость и допускаются неточности.

Если метрика начинает использоваться регулярно её фиксируют в Semantic Layer.
Там задаётся единая логика расчёта, и дальше все дашборды и отчёты используют уже её.

Например: сначала кто-то посчитал retention на лету, потом эта формула закрепляется, и вся команда начинает работать с одной версией метрики.

Полный разбор тут

@tldr_data

BI умрёт к концу года

Это мнение Pete Hunt - CEO Dagster и человека из data-инфраструктуры, а не BI-вендора.

Я думаю, что к концу этого года BI умрёт.

Все BI-вендоры оказываются зажаты с двух сторон.

Снизу, вертикальная интеграция со стороны data-компаний, плюс Claude уже довольно хорошо справляется с анализом данных. Сверху, компании из мира vibe coding, такие как Lovable и Replit, пытаются зайти в enterprise. Один из их сценариев - генерация презентаций и аналитики.
По сути, это те же данные, только зафиксированные в конкретный момент времени, без постоянных дашбордов.

BI-вендоры отвечают ожидаемо, добавляют AI-функции и повышают цены, чтобы сохранить маржу.
Но здесь классическая дилемма инноватора. AI быстро становится commodity: похожие возможности появляются у всех, а цена неизбежно давится вниз.

Поэтому ставка делается в другую сторону.

Цель - сделать AI дешёвым и доступным интерфейсом, а основную ценность сместить ниже: в оркестрацию и data-платформу.
Именно там остаются требования к надёжности, поддержке и восстановлению - вещи, за которые компании реально платят.

BI вряд ли исчезнет.
Скорее, он перестанет быть отдельным продуктом и станет частью других систем.

@tldr_data

LAKEHOUSE LANDSCAPE 2026

Почти год назад обсуждение Lakehouse всё ещё было сосредоточено вокруг открытых табличных форматов и предположения, что Parquet с метаданными достаточно для большинства корпоративных задач. Но управление данными быстро развивается, и ландшафт 2026 года показывает более зрелую, модульную и амбициозную экосистему.

Что изменилось?

✅ Файловый слой снова становится зоной инноваций.
Новые форматы, такие как Lance и Vortex, привлекают внимание, потому что ориентированы на сценарии, для которых классические Parquet-ориентированные подходы не предназначались: мультимодальный ИИ, векторный поиск, произвольный доступ, встроенные индексы и выборочные чтения. В то же время File Format API в Apache Iceberg - это серьёзный шаг вперёд: он позволяет подключать новые форматы файлов без нарушения open lakehouse-контракта.

✅ Каталоги становятся стабильнее и более стандартизированными.
Ключевой сдвиг- не в появлении множества новых каталогов, а в росте значимости Iceberg REST Catalog как общего слоя интероперабельности. Именно он сохраняет экосистему открытой, позволяя движкам, инструментам и managed-сервисам взаимодействовать через единый протокол, а не через хрупкие интеграции.

✅ Открытая интероперабельность явно побеждает.
Провайдеры и платформы всё больше сходятся вокруг совместимых с Iceberg паттернов доступа, REST-подключения к каталогам и подходов с выдачей учётных данных (credential vending). Центр тяжести смещается от изолированных метаданных к единой control plane, которая может последовательно обслуживать разные движки.

✅ Появляются лёгкие инструменты, упрощающие работу с Lakehouse.
DuckDB становится одним из самых практичных движков доступа к современным lakehouse, с растущей поддержкой Iceberg, Lance и каталогов. DataFusion также набирает популярность как переиспользуемый execution-слой на базе Apache Arrow, делая доступ к lakehouse более программируемым и удобным для встраивания в современные системы.

✅ Streaming-first подход становится частью архитектуры lakehouse.
Apache Paimon заслуживает большего внимания, поскольку предлагает модель, ориентированную на стриминг, для обработки высокочастотных обновлений и CDC-нагрузок. Это важно, потому что корректность в реальном времени и непрерывное обслуживание таблиц становятся базовыми требованиями, а не опциональными возможностями.

Главный вывод:
lakehouse больше не сводится к связке Parquet + table format. Архитектура становится многослойной. Файловый слой, каталоги, execution и streaming развиваются независимо. За счёт этого систему можно менять частями — без миграций на годы вперёд.

@tldr_data

Список гостей в The Pragmatic Engineer Podcast — это уже не просто подкаст, а почти зал славы индустрии.

Из ближайших выпусков:

• Thuan Pham — первый и самый долго работающий CTO Uber
• Martin Kleppmann — автор одной из ключевых книг по data engineering
• David Heinemeier Hansson — создатель Ruby on Rails, известный своими резкими позициями
• Anders Hejlsberg — человек за TypeScript и C#
• Kelsey Hightower — одна из ключевых фигур вокруг Kubernetes

Из последних выпусков:

• Mitchell Hashimoto — автор Ghostty
• Andrey Breslav — создатель Kotlin
• Mai-Lan Tomsen Bukovec — человек, который отвечает за Amazon S3

Лично мне очень зашел выпуск с Mitchell Hashimoto (He is the co-founder of HashiCorp and creator of Ghostty).
Ghostty сейчас, на мой взгляд, один из лучших терминалов, недавно полностью переехал на него с WezTerm.

Больше всего жду выпуски с Martin Kleppmann и David Heinemeier Hansson(Создатель Ruby on Rails).
Клепман — понятно, про распределённые системы.
DHH, скорее всего, опять пройдётся по микросервисам и расскажет, почему всем нужен монолит.

И отдельно — у Gergely Orosz есть книга The Software Engineer’s Guidebook — советую всем.
Сам прочитал пока примерно треть, но уже забрал несколько практичных идей.

Например: фиксировать свою работу, что делал, какие задачи закрывал, кому помогал.
Такие заметки сильно упрощают жизнь на performance review, не нужно вспоминать полгода задним числом.

@tldr_data

Vector Database Performance Compared: pgvector vs Pinecone vs Qdrant vs Weaviate

Каждая команда, которая делает поиск или RAG, в какой-то момент доходит до выбора векторной базы. На это часто уходит непропорционально много времени.

За последний год автор статьи использовал pgvector в продакшене и параллельно прогнал через тесты несколько альтернатив. Разница между ними есть, но она редко становится решающей на практике.

Pinecone закрывает вопрос инфраструктуры: поднял и работаешь. Это удобно на старте и в прототипах, но за это платишь меньшим контролем над тем, как именно считается recall.

Qdrant заметно выделяется на сценариях с фильтрацией. Если в запросах много условий поверх векторного поиска или нужен self-host, он даёт очень предсказуемую и быструю производительность.

Milvus имеет смысл, когда речь идёт о сотнях миллионов или миллиардах векторов. Там уже важны шардинг и партиционирование, и у него это реализовано зрелее, чем у остальных.

Weaviate упрощает жизнь, если нужен гибридный поиск, когда в одном запросе сочетаются keyword и vector. Плюс у него аккуратно сделан managed-вариант.

pgvector хорошо ложится в существующий стек с Postgres. До примерно 10 миллионов векторов он закрывает задачи без отдельной инфраструктуры. Дальше уже приходится думать про масштабирование, например через pgvectorscale.

Но в реальных системах узкое место другое.

Задержка 5 мс против 15 мс на векторном запросе не влияет на восприятие продукта. Пользователь этого не увидит. Зато разница между сильной и слабой моделью эмбеддингов сразу видна в результатах поиска. В одном случае ответы попадают в контекст, в другом нет.

Та же история с релевантностью и UX. Переранжирование, нормальная работа с контекстом, понятные ответы, всё это даёт кратно больший эффект, чем выбор между двумя быстрыми базами.

@tldr_data

Краткий обзор на интервью DHH

Удивительно, в это раз про микросервисы не вспомнили и даже переобулись с темой AI.

Вот вообщем короткая выжимка из интервью.

Всего шесть месяцев назад David Heinemeier Hansson (создатель Ruby on Rails и Omarchy) в подкасте Lex Fridman говорил, что не использует AI-инструменты для написания кода — они были недостаточно хороши. Сейчас он работает иначе: agent-first.

Автор подкаста расспросил за ситуацию про то, как изменился его процесс разработки и что он думает о профессии. В этом плане он последователен: тот же фокус на коде как ремесле, на аккуратности и внимании к деталям.

Первое, что бросается в глаза — его отношение к AI почти не поменялось. Поменялись сами инструменты. Полгода назад автодополнение уровня tab completion только мешало: оно сбивает темп и даёт слишком слабые подсказки. Переход к агентным моделям изменил ситуацию. В связке с более сильными моделями, вроде Opus 4.5, результат стал другим: агент генерирует код, который можно принимать без существенных правок. Это уже не подсказки, а полноценные изменения в кодовой базе.

Второй момент — его взгляд на красоту кода.
Для него это не эстетика ради эстетики.
Он формулирует это жёстко: если что-то выглядит правильно, скорее всего, оно и работает правильно. Здесь он ссылается на Steve Jobs — идея о том, что даже внутренняя часть системы должна быть аккуратно сделана.

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

И, наконец, его текущий workflow. Он работает в tmux с несколькими сплитами. В одном — быстрая модель (обычно Gemini 2.5), которая даёт быстрые итерации. В другом — более медленная, но сильная (Opus), куда уходят сложные задачи. По центру — Neovim, где он просматривает изменения через Lazygit.

Это не выглядит как AI пишет код вместо разработчика. Скорее как система из инструментов с разной латентностью и качеством, между которыми он маршрутизирует задачи.

В итоге меняется не столько роль разработчика, сколько форма работы. Меньше ручного набора, больше проверки, сборки и принятия решений.

Про настройку и кастомизацию терминала будет следующий пост.

@tldr_data