Недавно столкнулся с задачкой, когде мне понадобился git worktree и tmux для агента. Первый шаг к AI конвейеру.

tmux — программа для терминала, которая позволяет:
• Разделить один терминал на несколько окон — работай в нескольких местах одновременно
• Не терять работу при отключении — закрыл терминал или оборвалось SSH-соединение? Всё продолжает работать, можно вернуться позже
• Запускать долгие процессы на сервере — отключился, а программа работает

Простой пример
Подключился к серверу → запустил tmux → запустил долгую задачу → отключился от сервера → задача продолжает работать → подключился обратно → всё на месте

Коротко: это как вкладки в браузере, но для терминала, и они не закрываются, даже если ты вышел.

Git worktree — это возможность Git создать несколько рабочих копий одного репозитория с разными бранчами одновременно.
Зачем нужен:
Обычно в одной папке репозитория можно работать только с одним бранчем. Git worktree позволяет работать с несколькими бранчами параллельно без переключения.

Как работает:

```
# Основной репозиторий в ~/project (бранч main)
cd ~/project

# Создать worktree для другого бранча
git worktree add ../project-feature-1 feature-1
git worktree add ../project-feature-2 feature-2
```

Теперь у тебя:
• ⁠~/project — бранч main
• ⁠~/project-feature-1 — бранч feature-1
• ⁠~/project-feature-2 — бранч feature-2
Все три папки связаны с одним репозиторием (один ⁠.git), но работают с разными бранчами.

Преимущества:
• Не нужно переключать бранчи и коммитить незаконченную работу
• Можно открыть разные бранчи в разных редакторах (Claude Code в одном, Cursor в другом)
• Экономит время — не нужно клонировать репозиторий несколько раз

Коротко: один репозиторий, несколько папок, разные бранчи одновременно.

Так как я теперь работаю сразу в Claude Code и Cursor на своём Mac, я не могу работать в одном Git Branch. Точнее, я начал это делать, и потом у меня 2 задачи склеились в одну внутри одной ветки, причём частично. (На Windows машинах я использую VSCode + KiloCode, так как нет админского доступа)

Таким образом, сразу возникает потребность в разделении веток на одной машине. Git worktree решает эту проблему, а tmux помогает удобно управлять несколькими терминальными сессиями для работы с разными worktree одновременно.

Дальше нужно попробовать добавить OpenSpec, чтобы поставить задачу и разбить её на подзадачи, чтобы запустить несколько агентов параллельно.

Именно в AI у меня три направления:
1. Разработка с AI — это самое простое, просто нужно следить за обновлениями и примерами и пробовать на своих задачах.
2. Бизнес-кейсы для DE — тут в теории понятно, а вот техническая реализация требует времени. Сейчас очень популярно делать RAG, chat bot, Agent workflow или использовать GenAI для автоматизации. Часть кейсов хочу внедрить в Surfalytics, для этого мигрирую на Netlify + Supabase.
3. Личные агенты и ассистенты — на рынке много продуктов, которые могут делать простые задачи. Например, на базе моих календарей и задач в Notion, Jira, Asana сделать примерное расписание дня и забукать слоты в календаре. Или совсем простой кейс — каждый раз, когда делаю PR или работаю над задачей, заводить новый тикет через MCP и отслеживать все тикеты и обновлять статусы.

Все самое лучшее всегда должно быть простым и понятным. Это применимо ко всему.

Если взять пример внедрение аналитических решений, взаимодействия с другими командами, то я ничего лучше не видел, чем framework DACI.

Матрица DACI (да́си) — это таблица, в которой описывают роли членов команды на всех этапах проекта. Каждый участник может узнать, за что сейчас отвечает и что должен сделать.

Всего существуют четыре роли:
• Driver (организатор) — отвечает за процесс и результат.
• Approver (заказчик) — принимает и оценивает итоги работы.
• Contributor (исполнитель) — работает руками или консультирует.
• Informed (информированный) — находится в курсе процесса.

Для меня это простой инструмент экономии моего (и команды) времени. Нет смысла сидеть на встречах и слушать мнения некомпетентных коллег, особенно там, где у меня есть опыт.

Один из недавних примеров - организация хочет строить аналитическое решение в AWS. У них сейчас on-premise SQL Server, SSIS, SSRS, и они уже месяцев 8 двигаются в эту сторону. Даже создали кластер Redshift, за который платят по $1000 в месяц, но только ничего на нём не сделали. Оно и понятно, ведь организация почти государственного масштаба, даже есть профсоюз, поэтому они не боятся увольнения, и AI им тоже не к чему.

Что может быть проще, чем сделать хранилище на AWS и Redshift? Поэтому, чтобы ускорить процесс, мы создаём в Confluence Decision Log и список горячих вопросов. Для каждого вопроса у нас создаётся документ DACI, в моём случае список документов:

1. Количество AWS акаунтов - один общий для Dev/Prod или несколько, для каждой среды. Очевидно, чем больше акаунтов, тем дороже в линейной зависимости.

2. Каким образом мы накатываем изменения в AWS аккаунт? CloudFormation, Terraform, CDK - нужно выбрать один способ, и мне вообще всё равно, я больше сам код не пишу для инфраструктуры, хоть на Rust. Но важно, чтобы репозиторий был вне периметра IT, чтобы у нас были все козырные права.

3. Framework для трансформации данных - dbt, Glue, stored procedures. Они уже вовсю гоняют Glue Spark, чтобы данные внутри Redshift трансформировать. Про dbt не слышали. Хотя специально для таких консервативных пользователей лучше, чем dbt, нет.

4. Orchestration инструмент - AWS Batch, AWS Step Functions, on-premise Airflow (уже есть), Airflow on ECS, Managed Airflow. Так как я уже два раза внедрял Managed Airflow и остался очень доволен, то мой выбор очевиден. Но IT хотели бы свой Airflow on-premise.

5. Среда разработки - виртуальная рабочая станция (для работы с on-premise) или сам ноутбук. Даже без админского доступа я уже всё себе смог настроить через Python, VSCode. Но хотелось бы, чтобы они немного поменяли mindset и жили в современном мире.

Написать эти 5 документов у меня заняло где-то час. И то пришлось копировать руками из Markdown в Confluence, потому что я не смог поставить Confluence MCP, так как нет прав на установку npm. А через Python не получилось. Без AI я мог бы писать по одному документу в день. А если взять их pace time, то можно писать один документ в неделю.

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

Менеджера я тоже очень воодушевил, рассказал ему, что он Leader (с большой буквы) и его задача убирать road blockers для команды и всех делать счастливыми (типа иди договаривайся с IT, как все доступы получить).

У них ещё команда не обычная: главный ETL-разработчик уже не один десяток лет работает с ними, и, к сожалению, он практически ослеп на старость лет, но он всё ещё главный ETL-разработчик и делает мне демо, как у них там всё работает. А вы тут говорите, у вас времени нет учить AI и зарабатывать 😊

Я: 2 зума подряд — выгорел, productivity на нуле

Чувак с 5 remote jobs…

Life hack для менеджера и тимлида — Монополия на знание

• Ставите себе Claude Code / Cursor.
• Подключаете все возможные MCP (Confluence, Git, базы данных и т. д.).
• Настраиваете CLI для ваших сервисов (CI/CD, Infra, Monitoring и т. д.).
• Подключаетесь к Jira, чтобы всё мониторилось за вас.
• Записи всех встреч скармливаете в AI и получаете готовый backlog и Action Items.

Добавляете еще несколько полезных интеграций по вкусу.

Но самое главное: вы официально запрещаете использовать AI на работе под страхом увольнения. Ведь это «небезопасно» и «не комплаенс».

Таким образом, вы становитесь «Брюсом Тимлидом Всемогущим», реализуя исторические модели доминирования:

• «Вассал собирал оброк с крестьян»
• «Феодал взимал дань с зависимых крестьян»
• «Помещик собирал подати с крепостных»
• «Землевладелец получал ренту от крестьян»

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