Amp Code: Next generation AI Coding (Рубрика #AI)
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
🚀 Что это значит для разработки?
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Посмотрел интересный доклад Beyang Liu, CTO Sourcegraph, о новом редакторе Amp Code, в котором автор говорит о том, что это не просто "еще один Copilot", а попытка фундаментально изменить то, как мы взаимодействуем с AI в разработке. Если коротко: по мнению автора мы переходим от фазы "AI пишет текст" к фазе "AI замыкает цикл разработки". Сам Beyang Liu закончил Стэнфорд, а также успел поработать в Palantir и Google. Известен как создатель Sourcegraph (движок поиска по коду) и Cody (один из первых AI-ассистентов с контекстом кодовой базы). Он верит, что главное в AI-кодинге - это не генерация токенов, а доступ к графу знаний кода и runtime-окружению.
Основные тезисы доклада следующие
1️⃣ Смерть "Copilot-парадигмы"
Традиционные AI-ассистенты (GitHub Copilot, ранний Cody) работают как "умный автокомплит". Они предсказывают следующий токен, но не знают, работает ли этот код. Beyang называет это "Fire and Forget": AI выдал код, а разгребать ошибки компиляции - тебе.
2️⃣ Agentic Loop
Amp Code строит работу вокруг цикла OODA (Observe-Orient-Decide-Act)
- AI пишет код
- Сам запускает линтер/компилятор/тесты
- Видит ошибку (например,
TypeError)- Исправляет её без участия человека.
- Повторяет, пока не заработает.
3️⃣ Контекст - это не только текст
Просто засунуть 100 файлов в контекстное окно (даже на 1M токенов) - недостаточно. Amp использует LSP (Language Server Protocol) и реальные данные из runtime, чтобы понимать структуру проекта так же, как её понимает IDE, а не просто как набор символов.
4️⃣ Режим "Review Agent"
В Amp встроен отдельный агент-ревьюер. Перед тем как применить изменения, он проводит Code Review: ищет баги, проверяет стиль и безопасность, имитируя процесс PR-ревью в команде.
- Сдвиг скиллсета: От "быстрого набора кода" мы переходим к управлению агентами. Ваша задача - четко сформулировать намерение (Intent) и архитектуру, а реализацию (Implementation) и отладку берет на себя тул.
- Меньше Context Switching: Вам не нужно переключаться между редактором и терминалом, чтобы проверить, работает ли код, который выдал AI. Агент делает это фоном.
- Unix-way: Beyang подчеркивает, что Amp доступен и как VS Code extension, и как CLI-инструмент. Это возвращение к корням: мощные инструменты, которые можно скриптовать и встраивать в пайплайны.
В докладе и документации Amp, Beyang опирается на следующие концепции и материалы:
1. Agentic Workflows & Scaling Laws
Автор ссылается на то, что качество кода растет не линейно от размера модели, а скачкообразно при использовании agentic loops. Это подтверждается результатами бенчмарка SWE-bench, где агенты, умеющие запускать код, радикально обходят простые LLM. Подробнее про концепцию можно почитать у Andrew Ng
2. Sourcegraph’s "Big Code" Intelligence
База Amp - это технологии анализа графа кода (SCIP), которые Sourcegraph разрабатывает годами.
3. LSP как источник истины
Тезис о том, что LLM нужны структурированные данные от компилятора, а не просто текст. Это отсылка к Language Server Protocol, был разработан компанией Microsoft для своего редактора кода VS Code, но стал открытым стандартом и теперь активно развивается совместно с Red Hat и Codenvy, а сам проект размещен на GitHub, что позволяет использовать его в разных редакторах и для множества языков программировани
#AI #Software #Engineering #Architecture #Agents #ML #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
YouTube
Amp Code: Next Generation AI Coding – Beyang Liu, Amp Code
Introduction to Amp Code and its approach to AI-powered software development.
Speaker: Beyang Liu | Co-founder & CTO, Amp Code
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction & The…
Speaker: Beyang Liu | Co-founder & CTO, Amp Code
https://x.com/beyang
https://www.linkedin.com/in/beyang-liu/
https://github.com/beyang
Timestamps:
00:00 Introduction & The…
1❤9🔥5⚡3😁1
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos (Рубрика #Architecture)
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
Интересный доклад про восстановление архитектурного контекста при помощи AI агентов от Roy Osherove, Chief AI Architect в Verbit AI (компания с ~90 разработчиками, 12 командами и 400+ репозиториями). Интересно, что Roy написал три книги: The Art of Unit Testing, Elastic Leadership, Pipeline Driven (пока в разработке, но про его доклад с таким названием я уже рассказывал). У Роя есть и интересный блог robotpaper.ai, где он документирует AI-паттерны для разработчиков. Из интересного - его книги попали в обучающие датасеты LLM, поэтому промпт "review my tests in Roy Osherove style" работает из коробки в Cursor:)
Если же говорить про основные тезисы доклада изложены ниже
Документация в enterprise - проигрышная битва
В компаниях с 400+ репозиториями реальность такова
- 90% README-файлов устаревшие или неполные
- Архитектурные диаграммы существуют как кот Шредингера (пока не посмотришь не знаешь они еще живы или уже нет)
- Критические вопросы требуют недель ручного анализа: "что за инструменты мониторинга используются", "где хранятся определенные данные", "кто пользуется устаревшими API "
Не только люди страдают от такого качества документации - AI-агенты страдают тоже, так как им нужен контекст для правильных решений (какой UI-компонент использовать, как вызывать внутренний сервис).
Автор доклада в качестве решения создал RepoSwarm, живой архитектурный репозиторий, который доступен в виде open source. Он работает примерно следующим образом
1. Ежедневно сканирует GitHub-репозитории (приватные/публичные) с коммитами за последние 12 месяцев (это настраивается)
2. Генерирует markdown-документацию (один repo.md на репозиторий) через Claude Code SDK
3. Сохраняет в централизованный Architecture Hub — Git-репозиторий с полной историей изменений
4. Никогда не устаревает: при новом прогоне файлы полностью перезатираются (нет никакой backward compatibility)
Ключевое отличие от статической документации в том, что документы сделаны AI-readable (markdown) и у нас есть git-история
Если говорить про то, что автор решил добавить в repo.md, то это такой список инфомрации
- Базовая информация - High-level overview, Dependencies (package.json/requirements.txt), Security checks (top 10 OWASP), Monitoring tools
- Данные и API - Database schemas, API versioning, Events/messaging (pub/sub), Data mapping (GDPR/HIPAA flows)
- Инфраструктура - CI/CD deployment, Authentication/Authorization, Feature flags, ML/LLM usage (Gemini/Claude endpoints)
- Специализированные - Prompt security (injection checks), Mobile UI patterns (для repo_type: mobile), IaC analysis (для Terraform/K8s)
В каких реальных кейсах этот инструмент использовался автором
1. Cross-repo анализ - ответы на вопрос вида "какие monitoring tools используются?"
2. Large-scale migrations - обновление Python, консолидация API gateways (переход на Kong), deprecation внутреннего сервиса (поиск всех зависимостей)
3. Архитектурная история - генерация ретроспективно ADR с ответом на вопросы вида "why we moved to serverless in Q2 2024"
4. AI-агентам как контекст - использование Architecture Hub в Cursor → автоконтекст для features/bugs
Что использование значит для разработки
1. Смещение роли архитектора - от ручной работы к построению и использованию таких инструментов
2. Новый workflow для compliance - проще выстроить соответствие внешним требованиям
3. Эволюция AI-агентов - улучшениие AI-assisted разработки за счет интеграции архитектурной информации в контекст агентов
4. Следование философии "живой документации" - генерация ее из кода и гарантированный freshness
#DevOps #AI #Architecture #Culture #Engineering #ML #Future #Software #SystemDesign
YouTube
RepoSwarm - Giving AI Agents Architecture Context Across All Your Repos - Roy Osherove
more info at https://robotpaper.ai by Roy Osherove.
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
This talk explores RepoSwarm, an AI-first developer tool for giving LLM-powered coding agents deep, accurate context across large multi-repository codebases. Instead of relying on stale READMEs or static…
🔥8❤6👍4☃1🎄1
Developer Experience in the Age of AI Coding Agents (Рубрика #Agents)
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотрел интересное выступление Max Kanat-Alexander, Executive Distinguished Engineer в Capital One, где он рассказывал про DevEx в эпоху AI-агентов или как не утонуть в уже существующем legacy и новосозданном legacy, генерящегося агентами в ускоренном режиме:) Макс ранее работал Tech Lead в Google (над Code Health) и Principal Staff Engineer в LinkedIn (над Developer Productivity). Также он написал книги "Code Simplicity" и "Understanding Software", которые я пока не прочел:)
Основные тезисы доклада такие
1️⃣ Не сражайтесь с Training Set
Используйте стандартные инструменты. Если вы написали свой пакетный менеджер или используете редкий язык — агент будет тупить. Он обучен на open source стандартах. Чем "скучнее" и стандартнее ваш стек, тем умнее на нём работает AI.
2️⃣ CLI > GUI
Агентам нужны API и CLI, а не браузер. Заставлять агента "кликать" через GUI — дорого и ненадежно. Если у инструмента есть текстовый интерфейс, агент справится с ним быстрее и точнее.
3️⃣ Тесты должны быть детерминированными
Агенту ничего не говорит ошибка `500 Internal Error`. Ему нужны четкие сообщения валидаторов. Инвестиция в качественные сообщения об ошибках в тестах и линтерах — это инвестиция в автономность агента. Критично что тесты должны бежать быстро (30 секунд, а не 20 минут). Агент запускает их в цикле. Медленный CI убьёт продуктивность агента.
4️⃣ Документируйте "Зачем", а не "Что"
Агент видит код и понимает, что он делает. Но он не был на ваших митингах и не умеет читать мысли.
В документации теперь нужно писать контекст: бизнес-цели, внешние ограничения, форму данных на входе. То, чего нет в коде.
5️⃣ Проблема Code Review (Порочный цикл)
Написание кода превращается в чтение. Количество PR-ов растет экспоненциально.
Но, если у вас слабый процесс ревью, вы начнете "штамповать" (LGTM) плохой код от агентов. Кодовая база деградирует, агенту становится сложнее в ней работать, он пишет еще больше чуши → получается порочный круг. Решение в том, чтобы распределять нагрузку по ревью (не слать всё в общий канал "кто-нибудь гляньте") и жестко держать планку качества.
🚀 Что это значит для разработки?
- Рефакторинг легаси обязателен. Если человек не может понять структуру проекта без "тайных знаний", агент там просто галлюцинирует. Хорошая структура кода теперь — экономическая необходимость.
- Сдвиг парадигмы. Мы переходим от написания кода к верификации. Навык быстро читать и валидировать чужой код становится важнее навыка быстро печатать.
- Золотое правило. Всё, что хорошо для AI-агента (быстрые тесты, внятные ошибки, стандартные инструменты), хорошо и для человека. Даже если AI завтра исчезнет, эти инвестиции окупятся для людей. Забавно, что это очень похоже на "золотое правило морали", универсальный этический принцип, который гласит: «Поступай с другими так, как хочешь, чтобы поступали с тобой»,
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Developer Experience in the Age of AI Coding Agents – Max Kanat-Alexander, Capital One
It feels like every two weeks, the world of software engineering is being turned on its head. Are there any principles we can rely on that will continue to hold true, and that can help us prepare for the future, no matter what happens? Max uses research,…
👍15❤6🔥3
Dispatch from the Future: building an AI-native Company (Рубрика #AI)
Посмотерл претенциозный доклад Dan Shipper, сооснователя и CEO Every. Он запустил Every в 2020 году вместе с Nathan Baschez, а сегодня Every — это команда из 15 человек, которая управляет 6 бизнес-юнитами и 4 продуктами, публикует ежедневную рассылку об AI и консалтит.
Как по мне масштаб компании небольшой, но тезисы амбициозные и интересные, поэтому я привел их здесь
1️⃣ Квантовый скачок при 100% adoption
Разница между организацией, где 90% инженеров используют AI, и организацией со 100% adoption — это не 10%, а 10x. Если хотя бы 10% команды использует традиционные методы разработки, вся организация откатывается к старым процессам. Физика разработки меняется только при полном переходе.
2️⃣ 2. Один разработчик = продакшн-приложение
В Every каждый из четырех продуктов построен одним инженером. Это не игрушки: Cora (AI email assistant) обрабатывает тысячи почтовых ящиков, Monologue (speech-to-text) используют для написания миллионов слов в неделю, Spiral (AI writing partner) генерирует контент с миллионами показов. 99% кода написано AI-агентами — никто не пишет код руками.
3️⃣ От code editor к делегированию агентнам
Ключевое изменение — переход от редактора кода к terminal-based workflow с Claude Code, который убирает традиционный code editor и позволяет делегировать задачи агентам. Это открывает возможность параллельного выполнения: разработчики запускают 4 окна с агентами одновременно, работая над разными фичами.
4️⃣ Demo culture vs Memo culture
Когда код становится дешевым, компании переходят от "memo culture" (писать документы и убеждать коллег) к "demo culture" — можно за пару часов сделать прототип и показать. Это позволяет делать более странные и интересные вещи, которые сложно описать словами, но легко почувствовать.
5️⃣ Compounding Engineering
Every разработала методологию Compounding Engineering: каждая фича делает следующую фичу проще, а не сложнее. Цикл состоит из 4 этапов:
- Plan (40%): агенты изучают кодовую базу и создают детальные планы
- Work (20%): агенты пишут код и тесты
- Review (20%): оценка качества через тесты, код-ревью, субагентов
- Compound (20%): кодификация всех learnings в промпты, субагентов, slash-команды
6️⃣ Вторичные эффекты
Полный AI-adoption разблокирует неочевидные преимущества:
- Tacit code sharing: агенты могут читать репо соседних проектов и переносить паттерны в другой стек без явных библиотек
- Новички продуктивны с первого дня: вся организационная база знаний закодирована в claude.md файлах
- Cross-app commits: разработчики фиксят баги в чужих продуктах, потому что это просто
- Polyglot stack: каждый продукт может использовать свой язык и фреймворк — AI справляется с трансляцией
- Менеджеры коммитят код: даже CEO может коммитить production code между встречами
7️⃣ Fractured Attention Programming
AI позволяет работать с "раздробленным вниманием", когда раньше нужен был 3-4 часовой фокус-блок. Теперь: вышел из встречи → дал задачу агенту → пошел на другую встречу → вернулся к готовому результату → сделал PR.
Это влечет за собой следующие изменения для разработки
1) Изменения экономики разработки
- Параллелизм вместо последовательности: с агентами разработчик работает с 3-4 задачами одновременно в разных worktrees, а не с одной, как было раньше
- Снижение стоимости старта: prototype-first подход становится доминирующим
- Инверсия роли разработчика: код пишут агенты, разработчики становятся "оркестраторами"
2) Трансформация процессов
- Новые примитивы: появляются agents.md файлы с контекстом проекта, кастомные субагенты для специфичных задач и т.д (это способ кодификации знаний организации)
- Сдвиг от документации к артефактам: агенты читают код и другие примитивы напрямую
- Изменение hiring: больше не нужны недели на онбординг и не так важно знание конкретного стека
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
Посмотерл претенциозный доклад Dan Shipper, сооснователя и CEO Every. Он запустил Every в 2020 году вместе с Nathan Baschez, а сегодня Every — это команда из 15 человек, которая управляет 6 бизнес-юнитами и 4 продуктами, публикует ежедневную рассылку об AI и консалтит.
Как по мне масштаб компании небольшой, но тезисы амбициозные и интересные, поэтому я привел их здесь
1️⃣ Квантовый скачок при 100% adoption
Разница между организацией, где 90% инженеров используют AI, и организацией со 100% adoption — это не 10%, а 10x. Если хотя бы 10% команды использует традиционные методы разработки, вся организация откатывается к старым процессам. Физика разработки меняется только при полном переходе.
2️⃣ 2. Один разработчик = продакшн-приложение
В Every каждый из четырех продуктов построен одним инженером. Это не игрушки: Cora (AI email assistant) обрабатывает тысячи почтовых ящиков, Monologue (speech-to-text) используют для написания миллионов слов в неделю, Spiral (AI writing partner) генерирует контент с миллионами показов. 99% кода написано AI-агентами — никто не пишет код руками.
3️⃣ От code editor к делегированию агентнам
Ключевое изменение — переход от редактора кода к terminal-based workflow с Claude Code, который убирает традиционный code editor и позволяет делегировать задачи агентам. Это открывает возможность параллельного выполнения: разработчики запускают 4 окна с агентами одновременно, работая над разными фичами.
4️⃣ Demo culture vs Memo culture
Когда код становится дешевым, компании переходят от "memo culture" (писать документы и убеждать коллег) к "demo culture" — можно за пару часов сделать прототип и показать. Это позволяет делать более странные и интересные вещи, которые сложно описать словами, но легко почувствовать.
5️⃣ Compounding Engineering
Every разработала методологию Compounding Engineering: каждая фича делает следующую фичу проще, а не сложнее. Цикл состоит из 4 этапов:
- Plan (40%): агенты изучают кодовую базу и создают детальные планы
- Work (20%): агенты пишут код и тесты
- Review (20%): оценка качества через тесты, код-ревью, субагентов
- Compound (20%): кодификация всех learnings в промпты, субагентов, slash-команды
6️⃣ Вторичные эффекты
Полный AI-adoption разблокирует неочевидные преимущества:
- Tacit code sharing: агенты могут читать репо соседних проектов и переносить паттерны в другой стек без явных библиотек
- Новички продуктивны с первого дня: вся организационная база знаний закодирована в claude.md файлах
- Cross-app commits: разработчики фиксят баги в чужих продуктах, потому что это просто
- Polyglot stack: каждый продукт может использовать свой язык и фреймворк — AI справляется с трансляцией
- Менеджеры коммитят код: даже CEO может коммитить production code между встречами
7️⃣ Fractured Attention Programming
AI позволяет работать с "раздробленным вниманием", когда раньше нужен был 3-4 часовой фокус-блок. Теперь: вышел из встречи → дал задачу агенту → пошел на другую встречу → вернулся к готовому результату → сделал PR.
Это влечет за собой следующие изменения для разработки
1) Изменения экономики разработки
- Параллелизм вместо последовательности: с агентами разработчик работает с 3-4 задачами одновременно в разных worktrees, а не с одной, как было раньше
- Снижение стоимости старта: prototype-first подход становится доминирующим
- Инверсия роли разработчика: код пишут агенты, разработчики становятся "оркестраторами"
2) Трансформация процессов
- Новые примитивы: появляются agents.md файлы с контекстом проекта, кастомные субагенты для специфичных задач и т.д (это способ кодификации знаний организации)
- Сдвиг от документации к артефактам: агенты читают код и другие примитивы напрямую
- Изменение hiring: больше не нужны недели на онбординг и не так важно знание конкретного стека
#Engineering #AI #Metrics #Software #DevEx #Productivity #DevOps #Architecture #Culture #Engineering #ML #SystemDesign
YouTube
Dispatch from the Future: building an AI-native Company – Dan Shipper, Every, AI & I
The central thesis is that there is a "10x difference" between an organization where 90% of engineers use AI versus one where 100% do. At 100% adoption, the fundamental physics of software engineering change: a single developer can build and maintain complex…
🔥11❤7😱2⚡1😁1
История стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год (Рубрика #Startup)
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший инженер CERN (опыт в ML и физике), и Fabian Hedin, серийный предприниматель и инженер. Интересно, что история компании началась с вирального open-source проекта gpt-engineer, CLI-утилиты, которая позволяла сгенерировать кодовую базу проекта по одному текстовому промпту. Проект стал хитом на GitHub (набрал десятки тысяч звезд за дни), показав огромный спрос на автоматическую генерацию кода. Увидев интерес, основатели решили превратить инструмент в полноценный коммерческий продукт для веб-разработки и запустили в конце 2023 года коммерческую версию. А в декабре 2024 года произошел ребрендинг: платформа получила имя Lovable, чтобы отразить фокус на создании продуктов, которые «нравятся людям», и уйти от технического названия.
Если говорить про бизнес-модели, то они прошли путь
- Бесплатного open-source инструмента
- SaaS с фокусом на потребление ресурсов (usage-based pricing), где есть кредиты (что покрывают затраты на inference LLMs)
В итоге, сейчас Lovable продает не просто "редактор кода", а "результат". Вы платите за вычисления (compute credits), которые тратятся на итерации агента (написание кода, фикс багов, развертывание). И этот подход очень нравится инвесторам.
В 2025 году компания продемонстрировала одну из самых быстрых динамик роста оценки в истории европейских стартапов.
1. Pre-Series A (Февраль 2025) - $15 млн, лид-инвестор - Creandum, ангелы: Чарли Сонгхерст (экс-Microsoft), Адам Д'Анджело (CEO Quora), Томас Вольф (Hugging Face).
2. Series A (Июль 2025) - $200 млн, оценка - $1.8 млрд, лид-инвестор - Accel, участники: 20VC, byFounders, Hummingbird, Visionaries Club
3. Series B (Декабрь 2025) - $330 млн, оценка - $6.6 млрд, лид-инвесторы: CapitalG (фонд роста Alphabet/Google) и Menlo Ventures, стратегические инвесторы: NVentures (Nvidia), Salesforce Ventures, Databricks Ventures, Atlassian Ventures.
Уже в раунде B подключилились такие тяжеловесы, что видно, что Lovable воспринимается не просто как "еще один редактор", а как ключевой игрок в инфраструктуре AI-разработки.
На январь 2026 года Lovable представляет собой Full-Stack AI Builder. В отличие от Cursor (IDE для программистов), Lovable позиционируется как инструмент для создания конечного продукта, часто доступный даже не-инженерам (концепция "vibe coding" — вы описываете, что хотите, а система пишет код). Интерфейс Lovable выглядит как веб-приложение с чатом слева и живым превью приложения справа. На выходе получаются веб приложения на React, Tailwind, Node.js/Supabase код. Пользователь может видеть код, экспортировать его в GitHub и дорабатывать вручную (или при помощи других агентов). Из коробки работает интеграция с СУБД (Supabase), аутентификация и платежи. Агенты Lovable достаточно автономны - они умеют сами читать файлы проекта, находить ошибки и предлагать исправления, не требуя от пользователя указывать конкретную строку кода.
Если говорить про известные планы, то они примерно такие
1. Enterprise-сегмент: Внедрение функций Governance (управление политиками безопасности кода), чтобы крупные компании могли безопасно использовать инструмент.
2. Автономные агенты 2.0: Переход от "помощника" к "автономному инженеру", который может поддерживать проект, обновлять зависимости и рефакторить код в фоновом режиме.
3. Географическая экспансия: Открытие офисов в США (Бостон, Сан-Франциско) для агрессивного захвата американского рынка.
4. Lovable Cloud: Развитие собственной облачной инфраструктуры для хостинга приложений, чтобы пользователю вообще не нужно было думать о серверах или внешних провайдерах (Backend-as-a-Service).
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Компания Lovable (изначально известная как проект GPT Engineer) была официально основана в ноябре 2023 года в Стокгольме. Ее основали Anton Osika, бывший инженер CERN (опыт в ML и физике), и Fabian Hedin, серийный предприниматель и инженер. Интересно, что история компании началась с вирального open-source проекта gpt-engineer, CLI-утилиты, которая позволяла сгенерировать кодовую базу проекта по одному текстовому промпту. Проект стал хитом на GitHub (набрал десятки тысяч звезд за дни), показав огромный спрос на автоматическую генерацию кода. Увидев интерес, основатели решили превратить инструмент в полноценный коммерческий продукт для веб-разработки и запустили в конце 2023 года коммерческую версию. А в декабре 2024 года произошел ребрендинг: платформа получила имя Lovable, чтобы отразить фокус на создании продуктов, которые «нравятся людям», и уйти от технического названия.
Если говорить про бизнес-модели, то они прошли путь
- Бесплатного open-source инструмента
- SaaS с фокусом на потребление ресурсов (usage-based pricing), где есть кредиты (что покрывают затраты на inference LLMs)
В итоге, сейчас Lovable продает не просто "редактор кода", а "результат". Вы платите за вычисления (compute credits), которые тратятся на итерации агента (написание кода, фикс багов, развертывание). И этот подход очень нравится инвесторам.
В 2025 году компания продемонстрировала одну из самых быстрых динамик роста оценки в истории европейских стартапов.
1. Pre-Series A (Февраль 2025) - $15 млн, лид-инвестор - Creandum, ангелы: Чарли Сонгхерст (экс-Microsoft), Адам Д'Анджело (CEO Quora), Томас Вольф (Hugging Face).
2. Series A (Июль 2025) - $200 млн, оценка - $1.8 млрд, лид-инвестор - Accel, участники: 20VC, byFounders, Hummingbird, Visionaries Club
3. Series B (Декабрь 2025) - $330 млн, оценка - $6.6 млрд, лид-инвесторы: CapitalG (фонд роста Alphabet/Google) и Menlo Ventures, стратегические инвесторы: NVentures (Nvidia), Salesforce Ventures, Databricks Ventures, Atlassian Ventures.
Уже в раунде B подключилились такие тяжеловесы, что видно, что Lovable воспринимается не просто как "еще один редактор", а как ключевой игрок в инфраструктуре AI-разработки.
На январь 2026 года Lovable представляет собой Full-Stack AI Builder. В отличие от Cursor (IDE для программистов), Lovable позиционируется как инструмент для создания конечного продукта, часто доступный даже не-инженерам (концепция "vibe coding" — вы описываете, что хотите, а система пишет код). Интерфейс Lovable выглядит как веб-приложение с чатом слева и живым превью приложения справа. На выходе получаются веб приложения на React, Tailwind, Node.js/Supabase код. Пользователь может видеть код, экспортировать его в GitHub и дорабатывать вручную (или при помощи других агентов). Из коробки работает интеграция с СУБД (Supabase), аутентификация и платежи. Агенты Lovable достаточно автономны - они умеют сами читать файлы проекта, находить ошибки и предлагать исправления, не требуя от пользователя указывать конкретную строку кода.
Если говорить про известные планы, то они примерно такие
1. Enterprise-сегмент: Внедрение функций Governance (управление политиками безопасности кода), чтобы крупные компании могли безопасно использовать инструмент.
2. Автономные агенты 2.0: Переход от "помощника" к "автономному инженеру", который может поддерживать проект, обновлять зависимости и рефакторить код в фоновом режиме.
3. Географическая экспансия: Открытие офисов в США (Бостон, Сан-Франциско) для агрессивного захвата американского рынка.
4. Lovable Cloud: Развитие собственной облачной инфраструктуры для хостинга приложений, чтобы пользователю вообще не нужно было думать о серверах или внешних провайдерах (Backend-as-a-Service).
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
❤10🔥10⚡2👍2
[1/2] Архитектура платформы Lovable (Рубрика AI)
Раньше я уже рассказывал историю стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год. А в этой серии постов я хотел рассказать про то, что умеет этот продукт и как концептуально выглядит его архитектура. История собрана на основании публичных выступлений представителей компании (типа таких), а также утечек промптов навроде такой. Кроме того, можно почитать исходники проекта, с которого начинался Lovable, а именно gpt-engineer (и точечно промпты оттуда).
⚙️ Технологический стек и инфраструктура
Платформа Lovable генерирует полноценный исходный код веб-приложений и опирается на современные веб-технологии:
- На фронте используется React/TypeScript, а для стилизации по умолчанию применяется Tailwind CSS и блоки дизайн-системы на основе shadcn/ui (на базе Radix), а для иконок - lucide-react
- Для управления данными на клиенте встроены современные инструменты, например React Query (TanStack) для работы с серверными данными
- Генерируемый код следует принятым практикам: компоненты небольшие (до ~50 строк), приложение сразу адаптивное (responsive) и структурировано в духе атомарного дизайна Atomic Design
На бэкенде Lovable интегрируется с Supabase - это облачная платформа на базе PostgreSQL, которая
- Предоставляет базу данных
- Аутентификацию пользователей
- Хранение файлов и серверлесс-функции
Благодаря этой интеграции Lovable может автоматически создавать таблицы БД, настроивать авторизацию и даже развёртывать серверный код (например, обработчики оплаты или обращения к внешним API) в виде Edge Functions Supabase. Интересно, что не только Lovable хорошо получил денег на дальнейшее развитие, но и Supabase получил суммарно $300 млн (Series D + E) - я рассказывал про это при обзоре "Databases in 2025: A Year in Review by Andy Pavlo "
В итоге, архитектура приложения, создаваемого в Lovable, выглядит так: фронтенд на React/TypeScript/Tailwind/Atomic Desing + Supabase-бэкенд. Все это генерируется и настраивается AI в рамках единого процесса, без необходимости вручную поднимать что-то. Одновременно это можно опубликовать прямо на поддомене *.lovable.app (или кастомном домене) и пошарить пользователям. Для всего это не нужно обладать техническими знаниями - справится даже продакт.
Во втором посте я расскажу про агентскую архитектуру + инфраструктуру и устройство самой платформы.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Раньше я уже рассказывал историю стартапа Lovable, что вырос в оценке с нуля до $6.6 млрд всего за один год. А в этой серии постов я хотел рассказать про то, что умеет этот продукт и как концептуально выглядит его архитектура. История собрана на основании публичных выступлений представителей компании (типа таких), а также утечек промптов навроде такой. Кроме того, можно почитать исходники проекта, с которого начинался Lovable, а именно gpt-engineer (и точечно промпты оттуда).
Платформа Lovable генерирует полноценный исходный код веб-приложений и опирается на современные веб-технологии:
- На фронте используется React/TypeScript, а для стилизации по умолчанию применяется Tailwind CSS и блоки дизайн-системы на основе shadcn/ui (на базе Radix), а для иконок - lucide-react
- Для управления данными на клиенте встроены современные инструменты, например React Query (TanStack) для работы с серверными данными
- Генерируемый код следует принятым практикам: компоненты небольшие (до ~50 строк), приложение сразу адаптивное (responsive) и структурировано в духе атомарного дизайна Atomic Design
На бэкенде Lovable интегрируется с Supabase - это облачная платформа на базе PostgreSQL, которая
- Предоставляет базу данных
- Аутентификацию пользователей
- Хранение файлов и серверлесс-функции
Благодаря этой интеграции Lovable может автоматически создавать таблицы БД, настроивать авторизацию и даже развёртывать серверный код (например, обработчики оплаты или обращения к внешним API) в виде Edge Functions Supabase. Интересно, что не только Lovable хорошо получил денег на дальнейшее развитие, но и Supabase получил суммарно $300 млн (Series D + E) - я рассказывал про это при обзоре "Databases in 2025: A Year in Review by Andy Pavlo "
В итоге, архитектура приложения, создаваемого в Lovable, выглядит так: фронтенд на React/TypeScript/Tailwind/Atomic Desing + Supabase-бэкенд. Все это генерируется и настраивается AI в рамках единого процесса, без необходимости вручную поднимать что-то. Одновременно это можно опубликовать прямо на поддомене *.lovable.app (или кастомном домене) и пошарить пользователям. Для всего это не нужно обладать техническими знаниями - справится даже продакт.
Во втором посте я расскажу про агентскую архитектуру + инфраструктуру и устройство самой платформы.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥7⚡1
[2/2] Архитектура платформы Lovable (Рубрика AI)
Продолжая рассказ про архитектуру Lovable расскажу про агентский workflow + инфраструктуру и устройство самой платформы.
🤖 AI-движок и агентская архитектура
В основе Lovable – мощные модели генерации кода на естественном языке. Платформа использует несколько крупных языковых моделей (LLM) от ведущих провайдеров для кодогенерации(в 2025 году говорилось про модели от OpenAI и Anthropic). Особенностью Lovable является агентная архитектура AI (кстати: сам workflow можно увидеть в системном промпте, также полезно глянуть промпт с описанием инструментов)
- Система не просто дописывает код построчно, а воспринимает проект целиком и планирует решение прежде, чем писать код
- Сначала система анализирует запрос пользователя и формирует план приложения, затем пошагово генерирует фронтэнд, бэкэнд, API и даже документацию в соответствии с этим планом
Такой подход "смотрит на приложение в целом" позволяет получить согласованную архитектуру проекта и избежать ситуаций, когда AI ломается на середине задачи. Например, в этом обзоре отмечается, что Lovable способен из одного промпта создать полнофункциональный прототип (UI, база данных, авторизация, API) за считанные часы. Это стало возможным благодаря тому, что AI-агент “понимает” спецификацию целиком перед кодированием.
🚀 Инфраструктура платформы
- Сам сервис Lovable представляет собой облачное веб-приложение с собственным редактором и механизмом генерации кода. Фронтенд платформы (интерфейс, с которым работает пользователь) вероятно тоже написан на React/TS.
- Для хранения проектов и контроля версий Lovable использует интеграцию с Git-репозиториями. Каждому проекту соответствует репозиторий исходного кода: изменения, которые вносит AI, автоматически коммитятся, и пользователь при желании может подключить GitHub и синхронизировать проект для работы вне Lovable. Такая архитектура обеспечивает full code ownership: разработчик может в любой момент вывести код из платформы, продолжить работу локально и развернуть на своей инфраструктуре
- Масштабируемость обеспечивается за счёт вышеупомянутых облачных сервисов - Supabase берёт на себя хранение данных и выполнение серверных функций, а для хостинга фронтенда можно задействовать, например, Netlify или встроенный хостинг Lovable.
- Платформа генерирует проект как набор реальных файлов (включая package.json со всеми зависимостями, README и т.д.), поэтому развёртывание не требует проприетарного рантайма - код совместим с обычными Node.js-инструментами. В FAQ Lovable подчёркивается, что сгенерированный код продакшен-готов и следует лучшим практикам по масштабируемости, безопасности и поддерживаемости.
В будущем я еще расскажу про то, как выглядит процесс работы с Lovable и что происходит под капотом.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Продолжая рассказ про архитектуру Lovable расскажу про агентский workflow + инфраструктуру и устройство самой платформы.
В основе Lovable – мощные модели генерации кода на естественном языке. Платформа использует несколько крупных языковых моделей (LLM) от ведущих провайдеров для кодогенерации(в 2025 году говорилось про модели от OpenAI и Anthropic). Особенностью Lovable является агентная архитектура AI (кстати: сам workflow можно увидеть в системном промпте, также полезно глянуть промпт с описанием инструментов)
- Система не просто дописывает код построчно, а воспринимает проект целиком и планирует решение прежде, чем писать код
- Сначала система анализирует запрос пользователя и формирует план приложения, затем пошагово генерирует фронтэнд, бэкэнд, API и даже документацию в соответствии с этим планом
Такой подход "смотрит на приложение в целом" позволяет получить согласованную архитектуру проекта и избежать ситуаций, когда AI ломается на середине задачи. Например, в этом обзоре отмечается, что Lovable способен из одного промпта создать полнофункциональный прототип (UI, база данных, авторизация, API) за считанные часы. Это стало возможным благодаря тому, что AI-агент “понимает” спецификацию целиком перед кодированием.
- Сам сервис Lovable представляет собой облачное веб-приложение с собственным редактором и механизмом генерации кода. Фронтенд платформы (интерфейс, с которым работает пользователь) вероятно тоже написан на React/TS.
- Для хранения проектов и контроля версий Lovable использует интеграцию с Git-репозиториями. Каждому проекту соответствует репозиторий исходного кода: изменения, которые вносит AI, автоматически коммитятся, и пользователь при желании может подключить GitHub и синхронизировать проект для работы вне Lovable. Такая архитектура обеспечивает full code ownership: разработчик может в любой момент вывести код из платформы, продолжить работу локально и развернуть на своей инфраструктуре
- Масштабируемость обеспечивается за счёт вышеупомянутых облачных сервисов - Supabase берёт на себя хранение данных и выполнение серверных функций, а для хостинга фронтенда можно задействовать, например, Netlify или встроенный хостинг Lovable.
- Платформа генерирует проект как набор реальных файлов (включая package.json со всеми зависимостями, README и т.д.), поэтому развёртывание не требует проприетарного рантайма - код совместим с обычными Node.js-инструментами. В FAQ Lovable подчёркивается, что сгенерированный код продакшен-готов и следует лучшим практикам по масштабируемости, безопасности и поддерживаемости.
В будущем я еще расскажу про то, как выглядит процесс работы с Lovable и что происходит под капотом.
#AI #Software #Engineering #Future #Architecture #Startup #SystemDesign
Please open Telegram to view this post
VIEW IN TELEGRAM
❤7🔥6👍2
T-Hack Hardcore (Рубрика #Engineering)
7 февраля пройдет конференция T-Sync Conf, в рамках которой пройдет закрытый инженерный хакатон для Senior+ команд.
Мы решили попробовать новый формат для тех, кто принимает архитектурные решения в проде. Там команды будут решать практические задачи по оптимизации высоконагруженной распределенной системы. Но надо будет не только решить проблемы реально работающей системы, но и презентовать свое решение на широкий круг участников. В общем, мы решили попробовать микс траблшутинга, проектирования, реализации изменений, а дальше обоснования своего решения, причем "правильных ответов" нет, но есть компромиссы и их обоснование.
Если говорить подробнее, то формат такой
- Только офлайн
- 5 команд по 3–5 человек
- Участие — по отбору через анкету
- Уровень участников: Senior / Staff / Principal
Участникам предстоит заняться
- Диагностикой инфраструктуры, архитектуры приложений и базы данных
- Проектированием и внедрение решений в условиях ограничений
- Демонстрацией эффективности решения на боевой инфраструктуре
- Представлением решения в виде презентации с достигнутыми результатами
Участникам будет доступно
- Исходный код системы
- Инфраструктурные конфигурации
- Метрики, логи, трейсинги и наблюдаемость
- Opensource‑стек, полностью открытый для анализа и модификации
Если говорить про технологический стек, то он будет +/- стандартным
- Backend: Java/Go, PostgtreSQL, Kafka, Kubernetes
- Docker Compose, Terraform, Ansible
- Различные балансировщики: Envoy, Nginx
- Публичные облака
Мы думаем, что формат может быть интересным для разных специалистов, среди которых
- Архитекторы распределённых систем
- Staff / Principal инженеры
- Senior‑инфраструктурные и backend‑инженеры
- SRE и специалисты по highload и low-latency системам
- Engineering-менеджеры с большим практическим опытом
В командах особенно важны backend-инженеры и SRE.
Участникам будут доступны следующие ништяки
- Команда-победитель получает 500 000 рублей
- Все участники получат публичное признание на конференции и фиксации авторства решения
- Все команды-участники получают доступ на закрытую вечеринку конференции
Как попасть?
- Команда заполняет короткую анкету (до 10 минут)
- Мы выбираем 5 команд по опыту и инженерному мышлению
🗓 Анкеты принимаем до 30 января (заполнить ее можно здесь), а результаты сообщим сразу после закрытия приема заявок.
Если знаете команду, которая реально тянет хардовую инженерную задачу - перешлите им это сообщение.
#Engineering #Metrics #Software #DevEx #DevOps #Architecture #Culture #Engineering #SystemDesign #Conference
7 февраля пройдет конференция T-Sync Conf, в рамках которой пройдет закрытый инженерный хакатон для Senior+ команд.
Мы решили попробовать новый формат для тех, кто принимает архитектурные решения в проде. Там команды будут решать практические задачи по оптимизации высоконагруженной распределенной системы. Но надо будет не только решить проблемы реально работающей системы, но и презентовать свое решение на широкий круг участников. В общем, мы решили попробовать микс траблшутинга, проектирования, реализации изменений, а дальше обоснования своего решения, причем "правильных ответов" нет, но есть компромиссы и их обоснование.
Если говорить подробнее, то формат такой
- Только офлайн
- 5 команд по 3–5 человек
- Участие — по отбору через анкету
- Уровень участников: Senior / Staff / Principal
Участникам предстоит заняться
- Диагностикой инфраструктуры, архитектуры приложений и базы данных
- Проектированием и внедрение решений в условиях ограничений
- Демонстрацией эффективности решения на боевой инфраструктуре
- Представлением решения в виде презентации с достигнутыми результатами
Участникам будет доступно
- Исходный код системы
- Инфраструктурные конфигурации
- Метрики, логи, трейсинги и наблюдаемость
- Opensource‑стек, полностью открытый для анализа и модификации
Если говорить про технологический стек, то он будет +/- стандартным
- Backend: Java/Go, PostgtreSQL, Kafka, Kubernetes
- Docker Compose, Terraform, Ansible
- Различные балансировщики: Envoy, Nginx
- Публичные облака
Мы думаем, что формат может быть интересным для разных специалистов, среди которых
- Архитекторы распределённых систем
- Staff / Principal инженеры
- Senior‑инфраструктурные и backend‑инженеры
- SRE и специалисты по highload и low-latency системам
- Engineering-менеджеры с большим практическим опытом
В командах особенно важны backend-инженеры и SRE.
Участникам будут доступны следующие ништяки
- Команда-победитель получает 500 000 рублей
- Все участники получат публичное признание на конференции и фиксации авторства решения
- Все команды-участники получают доступ на закрытую вечеринку конференции
Как попасть?
- Команда заполняет короткую анкету (до 10 минут)
- Мы выбираем 5 команд по опыту и инженерному мышлению
🗓 Анкеты принимаем до 30 января (заполнить ее можно здесь), а результаты сообщим сразу после закрытия приема заявок.
Если знаете команду, которая реально тянет хардовую инженерную задачу - перешлите им это сообщение.
#Engineering #Metrics #Software #DevEx #DevOps #Architecture #Culture #Engineering #SystemDesign #Conference
❤7👍6🔥4🌚1
Head First. Паттерны проектирования (Head First. Паттерны проектирования) (Рубрика #Architecture)
Сегодня хотел вспомнить эту книгу про паттерны проектирования, которая вышла в серии Head First и выглядит как комикс:) Автор этой книги Эрик Фримен, экс-CTO Disney Online и один из создателей серии всей серии Head First.Сама книга вышла в середине 2000-х и быстро стала хитом среди разработчиков. В ней простым языком разбираются 23 классических шаблона проектирования. Авторы применили "визуально насыщенный формат, разработанный с учётом работы мозга", снабдив текст множеством иллюстраций, шуток и упражнений. Вместо сухой теории — живые примеры и головоломки. Уникальный стиль подачи сделал изучение паттернов увлекательным. Сравните эту подачу с классической "Паттерны объектно-ориентированного проектирования" от Gang of Four (Банды Четырех:)
Шаблоны в книге Head First объясняются на ярких метафорах из реальной жизни. Например, паттерн Стратегия иллюстрируется поведением разных уток 🦆, а паттерн Декоратор — добавками к базовому рецепту кофе ☕️. Такой подход помог читателям сразу увидеть практическую пользу шаблонов. Неудивительно, что книга уже помогла сотням тысяч разработчиков прокачать навыки проектирования.
Сейчас основные идеи книги остались такими же актуальными, хотя сами языки поменялись. Поэтому в 2019 году вышло обновлённое издание. Многие паттерны до сих пор в основе современного софта: одни встроены в языки (итераторы, наблюдатели событий), другие реализованы во фреймворках. Книга ценна и тем, что обучает базовым принципам ОО-дизайна (например, "программируйте на уровне интерфейсов, а не реализаций" и "предпочитайте композицию наследованию"). Эти идеи легли в основу более поздних правил вроде SOLID и не потеряли значимости.
Конечно, кое-что изменилось за годы. Некоторые классические приёмы сегодня реализуются иначе - например, Singleton всё чаще заменяют инъекцией зависимостей, а лямбда-функции упростили использование Strategy. Но сами концепции никуда не делись: понимание шаблонов по-прежнему помогает строить гибкую архитектуру и поддерживаемый код.
Если же в общем поговорить про развитие паттернов, то часть классических паттернов Gang of Four критиковалась экспертами за то, что многие из них лишь компенсируют ограничения языков. Так, Питер Норвиг выяснил, что 16 из 23 паттернов GoF фактически не нужны или упрощаются при реализации на Lisp. Но в то же время появились новые каталоги шаблонов для разных сфер. Шаблоны проникли на уровень архитектуры: от Enterprise Patterns для корпоративных систем, паттернов интеграции этих корп систем, и дальше до паттернов микросервисов для облачных сервисов. Сегодня инженеры широко применяют паттерны вроде API Gateway, Circuit Breaker и Event Sourcing - стандартные решения типовых проблем распределённых систем.
В итоге, книга Эрика Фримена и сегодня остаётся отличным путеводителем для тех, кто хочет научиться проектировать приложения. Книга показывает, что учиться архитектурным приёмам можно легко и с улыбкой. А знание паттернов - это тот самый багаж, который позволит инженеру уверенно строить сложные системы как вчера, так и сегодня.
#Patterns #Software #SoftwareArchitecture #SoftwareDevelopment #Architecture #SystemDesign
Сегодня хотел вспомнить эту книгу про паттерны проектирования, которая вышла в серии Head First и выглядит как комикс:) Автор этой книги Эрик Фримен, экс-CTO Disney Online и один из создателей серии всей серии Head First.Сама книга вышла в середине 2000-х и быстро стала хитом среди разработчиков. В ней простым языком разбираются 23 классических шаблона проектирования. Авторы применили "визуально насыщенный формат, разработанный с учётом работы мозга", снабдив текст множеством иллюстраций, шуток и упражнений. Вместо сухой теории — живые примеры и головоломки. Уникальный стиль подачи сделал изучение паттернов увлекательным. Сравните эту подачу с классической "Паттерны объектно-ориентированного проектирования" от Gang of Four (Банды Четырех:)
Шаблоны в книге Head First объясняются на ярких метафорах из реальной жизни. Например, паттерн Стратегия иллюстрируется поведением разных уток 🦆, а паттерн Декоратор — добавками к базовому рецепту кофе ☕️. Такой подход помог читателям сразу увидеть практическую пользу шаблонов. Неудивительно, что книга уже помогла сотням тысяч разработчиков прокачать навыки проектирования.
Сейчас основные идеи книги остались такими же актуальными, хотя сами языки поменялись. Поэтому в 2019 году вышло обновлённое издание. Многие паттерны до сих пор в основе современного софта: одни встроены в языки (итераторы, наблюдатели событий), другие реализованы во фреймворках. Книга ценна и тем, что обучает базовым принципам ОО-дизайна (например, "программируйте на уровне интерфейсов, а не реализаций" и "предпочитайте композицию наследованию"). Эти идеи легли в основу более поздних правил вроде SOLID и не потеряли значимости.
Конечно, кое-что изменилось за годы. Некоторые классические приёмы сегодня реализуются иначе - например, Singleton всё чаще заменяют инъекцией зависимостей, а лямбда-функции упростили использование Strategy. Но сами концепции никуда не делись: понимание шаблонов по-прежнему помогает строить гибкую архитектуру и поддерживаемый код.
Если же в общем поговорить про развитие паттернов, то часть классических паттернов Gang of Four критиковалась экспертами за то, что многие из них лишь компенсируют ограничения языков. Так, Питер Норвиг выяснил, что 16 из 23 паттернов GoF фактически не нужны или упрощаются при реализации на Lisp. Но в то же время появились новые каталоги шаблонов для разных сфер. Шаблоны проникли на уровень архитектуры: от Enterprise Patterns для корпоративных систем, паттернов интеграции этих корп систем, и дальше до паттернов микросервисов для облачных сервисов. Сегодня инженеры широко применяют паттерны вроде API Gateway, Circuit Breaker и Event Sourcing - стандартные решения типовых проблем распределённых систем.
В итоге, книга Эрика Фримена и сегодня остаётся отличным путеводителем для тех, кто хочет научиться проектировать приложения. Книга показывает, что учиться архитектурным приёмам можно легко и с улыбкой. А знание паттернов - это тот самый багаж, который позволит инженеру уверенно строить сложные системы как вчера, так и сегодня.
#Patterns #Software #SoftwareArchitecture #SoftwareDevelopment #Architecture #SystemDesign
1🔥24❤9👍8⚡1
Сайт по system design (Рубрика #Architecture)
Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.
Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
Многие мои подписчики знают, что я планировал написать книгу ... но я не уточнял какую. Суть была в том, что я параллельно занимался работой над несколькими книгами. Ближе всего к готовности была книга по System Design (с фокусом на подготовке к интервью) - мне просто было проще всего ее собрать из своих материалов. Я работал по стартинке - сделал желаемое оглавление, собрал часть глав из своих материалов и получил большой Google Doc. Но на каникулах меня осенило, что цель-то не в книге, а в удобной компиляции моих мыслей. Поэтому я поменял подход - скормил google doc сервису Lovable для создания интерактивного сайта, а дальше инкрементально начал его дорабатывать. Я этим занимался больше месяца и получился такой вот сайт system-design.space. Конечно, нет предела совершенству и я собираюсь продолжить его наполнение, но думаю, что он уже может принести пользу тем, кто хочет прокачаться в проектировании.
Если найдете какие-то ошибки или опечатки, то пишите - я буду править их по мере своих сил. В ближайшие месяцы я планирую добавить еще рекомендованных книг, поработать над пулом задачек, чтобы тут были не только классические из других книг + сделаю побольше красивых визуализаций. На более далеком горизонте я планирую пойти в стороне не только классическо system design, но и других типов, что описаны в главе про специфику интервью.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
1K🔥172👍35❤29🏆1
Современные методы описания функциональных требований к системам (Writing Effective Use Cases) (Рубрика #Software)
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
Во время подготовки материалов для своего сайта по System Design (https://system-design.space/) наткнулся в своей библиотеке на книгу Алистера Кокберна про написание функциональных требования. Сам Алистер - один из соавторов Agile-манифеста 2001 года, а также один из главных популяризаторов метода вариантов использования (Use Cases) для описания требований. Самой книге в этом году исполнилось 25 лет, поэтому я решил вспомнить про нее, а заодно про эволюцию подходов к описанию требований.
К концу 1990-х варианты использования стали одним из основных способов описания требований к поведению системы. Однако писать действительно хорошие use case было нелегко - требовались чёткие формулировки и логичная структура, как при написании хорошего эссе. Коберн решил эту проблему на практике, выпустив своё руководство по написанию вариантов использования в 2001 году. Книга подробно разъяснила как документировать сценарии: как определить границы системы (scope), описать актёров, их цели и пошаговый ход взаимодействия. Автор включил реальные примеры и сформулировал ряд правил, помогающих создавать понятные и полезные описания. Такой прикладной подход сделал книгу популярной среди инженеров.
На текущий момент индустрия разработки существенно изменилась. С появлением Agile-команд громоздкие спецификации требований уступили место более лёгким артефактам - таким как user stories (пользовательские истории). Формальные же use case многими стали считаться устаревшими. Однако на практике варианты использования до сих пор применяются, особенно в крупных сложных проектах. Их структурированный формат с проработкой логики и исключений даёт разработчикам понятное техническое задание. Подготовка use case более трудоёмка, но впоследствии экономится время на реализации и отладке требований.
Если же говорить про эволюцию подходов, то с момента выхода книги Алистера появились другие, более гибкие методы, ориентированные на работу с требованиями пользователей
1️⃣ User Story
A user story is a short, informal explanation of a software feature, written from the perspective of the end user.
Этот формат зародился в Agile-разработке: требования формулируются кратко от лица пользователя (по шаблону “As a ..., I want ..., so that ...”). User stories акцентируют ценность для пользователя и благодаря простоте быстро завоевали популярность в Agile-разработке.
2️⃣ Jobs to be Done (JTBD)
Jobs to be Done is a framework that helps product teams understand what job a customer is hiring a product to do — what problem, challenge, or opportunity is so important to them that they're willing to hire your product to address it.
JTBD - концепция, рассматривающая, какую «работу» пользователь «нанимает» продукт выполнить для решения своей проблемы.
3️⃣ Job Story
An exciting alternative for some teams is the job story. A job story is focused less on the user performing some function than on the job to be done by that story.
Формат job story появился как развитие подхода Jobs to be Done. В job story акцент смещён с образа пользователя на саму задачу и контекст её выполнения. Используется шаблон: “When [ситуация], I want to [действие], so I can [результат].” Такой подход чётко обозначает ситуацию и мотивацию, позволяя сконцентрироваться на решении реальной задачи.
4️⃣ Design Thinking
Design thinking is a problem-solving approach that focuses on understanding users’ needs and creating innovative solutions.
Design thinking (дизайн-мышление) – человеко-ориентированный творческий процесс решения проблем: через эмпатию и эксперименты команда ищет нестандартные решения, отвечающие потребностям пользователей.
В общем, книга Алистера сейчас уже устарела, но сам подход к написанию use cases полезно знать, особенно как предшественников очередных модных подходов, которые обыгрывают похожие идеи косметически изменяя формулировки:)
#Software #Architect #SystemDesign #SoftwareArchitecture #Processes
❤12🔥7👍5
AI Periodic Table Explained: Mapping LLMs, RAG & AI Agent Frameworks (Рубрика #AI)
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системыМенделеева "AI Periodic Table". У этой таблицы, как ни странно, два измеренияя
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
Посмотрел очередное интересное обучающее видео от Martin Keen из IBM, где он пытается свести AI терминологию в понятную систему. Все из-за того, что у нас куча терминов навроде таких: "агенты", "RAG", "эмбеддинги", "гардрейлы", все эти термины летают вокруг, и от разработчиков ожидается, что они просто знают, как это всё связано, но это далеко не так просто уложить в голове. Для этого Мартин предложил свою структуру для систематизации в виде периодическиой системы
Строки (периоды) - этпы
1. Primitives - атомарные блоки (Prompts, Embeddings, LLMs)
2. Compositions - комбинации примитивов (RAG, Vector DBs, Guardrails)
3. Deployment - продакшн-паттерны (Agents, Frameworks, Fine-tuning)
4. Emerging - передний край (Multi-Agent, Thinking Models, Interpretability)
Колонки (семейства)
1. Reactive (реактивные) - изменение входа → радикальное изменение выхода
2. Retrieval (поиск) - хранение и извлечение информации
3. Orchestration (оркестрация) - связывание множества компонентов
4. Validation (валидация) - безопасность и тестирование
5. Models (модели) - стабильные фундаментальные возможности
Если разбирать содержимое таблицы по колонкам, то получится интересно
Reactive Family
- Pr (Prompt) - инструкции для AI
- Fc (Function Calling) - вызов внешних API/инструментов
- Ag (Agent) - цикл думай-действуй-наблюдай
- Ma (Multi-Agent) - коллаборация нескольких AI агентов
Retrieval Family
- Em (Embeddings) - численные представления смысла
- Vx (Vector Database) - хранилище для семантического поиска
- Ft (Fine-tuning) - адаптация к доменным данным
- Sy (Synthetic data) - синтетические данные, на которых сейчас зачастую учатся новые модели
Orchestration Family
- Rg (RAG) - блок про Retrieval Augmented Generation
- Fw (Framework) - платформы вроде LangChain
Validation Family
- Gr (Guardrails) - runtime-фильтры безопасности
- Rt (Red Teaming) - adversarial-тестирование при помощи атакующих red teams
- In (Interpretability) - понимание "почему" модель именно так отрабатывает во время inference
Models Family
- Lg (LLM) - большие языковые модели от OpenAI, Antrhopic, Google, Alibaba, DeepSeek и других
- Mm (Multi-modal) - мультмодальные модели, что позволяют обрабатывать помимо текста изображения, аудио и так далее
- Sm (Small Models) - дистиллированные модели для edge и не только
- Th (Thinking Models) - chain-of-thought встроен в архитектуру новых моделей
Дальше в видео Мартин рассказывает как такая картинка в голове помогает лучше укладывать информацию, а также размышлять про решение задач, связанных с AI в реальном мире. Мне концепция нравится - я сам часто размышляю визуально схемами и эта схема выглядит неплохо и хорошо укладывается в мою голову:))
Плюс мне кажется, что эту схему можно использовать при проектировании и прогонять идеи через призму таблицы. Например, когда кто-то питчит "AI-решение", можно мгновенно декомпозировать его на элементы таблицы:
- Какие элементы используются?
- Какие реакции они запускают?
- Отсутствует ли элемент безопасности (Gr)?
- Нет ли over-engineering в оркестрации?
- Подходит ли Thinking Model там, где хватило бы Small Model?
#AI #DevOps #Software #Engineering #Architecture #SystemDesign
👍17❤5🔥4
Update по System Design Space (Рубрика #Engineering)
Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)
А если в целом, то мне давно не было так интересно заниматься разработкой софта в качестве хобби после работы - раньше мешало отсутствие времени, а теперь с новыми инструментами мешает только отсутствие идей ... А если идеи у вас есть, то возьмите и попробуйте новые инструменты и может быть вам это понравится.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
Я запустил этот сайт чуть больше недели назад и продолжил его активно дорабатывать и решил поделиться lessons learned.
- Дорабатывать сайт ипользуя только Lovable дорого - кредиты улетают как не в себя - я прошел такой путь за месячную подписку всего за полтора месяца 0$ -> 25$ -> 50$ -> 100$ -> 200$
- Как второй и основной помощник я сейчас использую OpenAI Codex, где подписки в 200$ хватает как на веб, deep research, так и на написание кода (сразу для целой пачки ресурсов)
- Я добавил очень много новых глав + отдельный раздел, что посвящен документальным фильмам про технологии
- Для сложных тем я сделал визуализации архитектуры и процесса работы - смотрите примеры из части с кейсами
- Я добавил светлую тему, оглавление, поменял верстку под мобилу и еще кучу всего
- Сайт успел за неделю полежать пару раз. Один раз мы с Codex оптимизировали сборку и lazy загрузку React, что локально все работало, а на внешнем хостинге нет - пришлось откатить эту оптимизацию. Второй раз была проблема с DNS - я забыл подтвердить email регистратору доменных имен и дальше делегирование сайта было преостановлено (дальше прожал кнопочку подтверждения из email и буквально всего через 2 часа все вернулось, а могло и через 2 дня)
- Как-то я попросил отрефакторить проект и агент ушел локально колбасить что-то на всю ночь - утром пришел проверил, сделал несколько фиксов и все полетело
- Тесты у меня есть, но из-за того, что я часто меняю внешний вид сайта, то я часто их просто заново гененрирую, а не прогоняю для проверки (главы - это отдельные ts файлы, поэтому изменения обычно хорошо локализованы и дают мало внешних эффектов)
- Я занимаюсь этим по выходным, а также по вечерам после работы и это затягивает - иногда в 2 часа ночи ловлю себя на мысли, что надо выдать задачку помасштабнее и наконец-то пойти спать:)
А если в целом, то мне давно не было так интересно заниматься разработкой софта в качестве хобби после работы - раньше мешало отсутствие времени, а теперь с новыми инструментами мешает только отсутствие идей ... А если идеи у вас есть, то возьмите и попробуйте новые инструменты и может быть вам это понравится.
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
2🔥54❤16⚡4👍3🏆1
Troubleshooting Interview (Рубрика #Engineering)
Вчера впервые за полгода или даже больше провел интервью по траблшутингу для SRE-инженера. Когда-то я был лидером этой секции найма, много рассказывал про нее (на Devops Conf) и даже провел публичное интервью на Devoops Conf. Но потом я передал секцию другому лидеру, а сам остался в пуле интервьюеров и мне почти никогда не прилетал этот вид собеседований. Но на этой неделе он прилетел и я хотел отказаться - слишком я был перегружен другими делами и не хотелось тратить время на то, чтобы освежить воспоминания. Но я решил, что это отличный способ размять мозг и вспомнить былое - я вспомнил регламент, взял одну из задач, которую я добавлял в пул задач по траблшутингу на основе постмортема одной из моих команд и отправился проводить интервью. На самом интервью я вспомнил как это круто играть в DnD в роли гейм-мастера - мы "побеждали дракона" и "спасали принцессу" (нашу систему), а мне было очень интересно:) В итоге, я решил, что надо бы на сайт system-design.space добавить главы про troubleshooting - вопрос надежности спроектированного решения часто очень важен в рамках интервью по system design. В общем, я добавил главу про интервью в общем, а в главе про публичное интервью еще сделал визуализации архитектуры приложения и старта сбоя). Думаю, что на досуге возьму еще постмортемов и сделаю практических задач - а потом может с ними сделаю публичные моки интервью:)
#Architecture #SRE #Engineering #Software #Management #Career #Devops #Interview #SystemDesign
Вчера впервые за полгода или даже больше провел интервью по траблшутингу для SRE-инженера. Когда-то я был лидером этой секции найма, много рассказывал про нее (на Devops Conf) и даже провел публичное интервью на Devoops Conf. Но потом я передал секцию другому лидеру, а сам остался в пуле интервьюеров и мне почти никогда не прилетал этот вид собеседований. Но на этой неделе он прилетел и я хотел отказаться - слишком я был перегружен другими делами и не хотелось тратить время на то, чтобы освежить воспоминания. Но я решил, что это отличный способ размять мозг и вспомнить былое - я вспомнил регламент, взял одну из задач, которую я добавлял в пул задач по траблшутингу на основе постмортема одной из моих команд и отправился проводить интервью. На самом интервью я вспомнил как это круто играть в DnD в роли гейм-мастера - мы "побеждали дракона" и "спасали принцессу" (нашу систему), а мне было очень интересно:) В итоге, я решил, что надо бы на сайт system-design.space добавить главы про troubleshooting - вопрос надежности спроектированного решения часто очень важен в рамках интервью по system design. В общем, я добавил главу про интервью в общем, а в главе про публичное интервью еще сделал визуализации архитектуры приложения и старта сбоя). Думаю, что на досуге возьму еще постмортемов и сделаю практических задач - а потом может с ними сделаю публичные моки интервью:)
#Architecture #SRE #Engineering #Software #Management #Career #Devops #Interview #SystemDesign
System Design Space
Глава 10. Troubleshooting Interview — System Design Space
Формат SRE-интервью: диагностика инцидентов, RED Method, workaround vs root cause, критерии оценки и сравнение с System Design. Формат: авторский материал. Часть 1: Подходы к найму в Big Tech компаниях.
1🔥34👍10❤5
Local-First Software: Taking Back Control of Our Data | a mini-doc (Рубрика #DistributedSystems)
Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.
Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.
Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.
В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.
P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)
P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.
#DistributedSystems #Architecture #SystemDesign #Software #Databases
Посмотрел интересный мини-документальный фильм, в котором засветились разные люди, но меня заинтересовал Мартин Клеппман, автор книги DDIA и один из апологетов подхода local-first. Собственно, этот подход предлагает альтернативу централизации хранения информации в облаке (и фиксации там источника истины). В local-first приложениях "истина" хранится на устройстве пользователя, работает без интернета и синхронизируется с облаком как с дополнительной копией.
Основные идеи концепции такие
1️⃣ Главная копия - у пользователя. Приложение читает/пишет локально → быстрый UX, офлайн по умолчанию. Облако нужно для синка между устройствами и бэкапа.
2️⃣ Cloud‑first ломается в быту. Например, пропал сигнал - пропал плейлист, хотя музыку «купили». И ещё хуже: сервис закрылся/выключил серверы - люди теряют доступ к своим данным.
3️⃣ Коллаборация возможна, но это сложно. Цель - как в лучших облачных продуктах (реал‑тайм, единые данные), но без постоянной связи с центральным сервером. Техники: CRDT, p2p/распределённая синхронизация, «слияние» изменений. Пока есть трудные кейсы и много инженерной работы.
4️⃣ Это уже движение. Сообщество растёт, появляются митапы/инструменты. Большинство «local‑first» продуктов пока гибридные (компромисс идеала и практики), но направление ясно: больше автономности и контроля пользователя.
Если прекладывать это на идеи для проектирования своих приложений и хочется попробовать двигаться в эту сторону, то можно сделать следующее
- Сделайте offline‑first базовым нефункциональным требованиям. Не «спиннер без сети», а работа с локальными данными + очередь/ретраи/идемпотентность (кстати, сейчас такой подход был бы актуален на случай блокирования мобильного интернета)
- Локальная БД + фоновый sync. SQLite/IndexedDB и слой репликации: журналы изменений, версии, мердж, лимиты/квоты, наблюдаемость синка.
- Конфликты - не баг, а сценарий. Опишите модель консистентности: last‑write‑wins, CRDT, явные конфликты в UI, правила домена.
- Контроль и долговечность данных. Экспорт, локальные бэкапы, миграции схем, E2E‑шифрование для синка/облака.
- Сдвиг сложности на клиент. Сервер может стать проще (координация/хранилище), но растут требования к тестированию офлайн/синка и к компетенциям в распределённых системах.
В общем. если подводить итог, то local-first пытается решить боли уехавших в облака приложений и ставших cloud-only, а список проблем большой: зависимость от сети, доверие и сохранность данных. Но надо отметить, что полный переход не обязателен, но уже сейчас можно внедрять элементы: локальное хранение, офлайн‑UX, безопасный sync и понятную модель конфликтов. Это даст продукту устойчивость и пользователю - ощущение контроля.
P.S.
Минидокументалка всего на 10 минут, поэтому ее вообще изян посмотреть почти как shorts:)
P.P.S.
Эта документалка тоже попала на сайт system-design.space, так как в ней очень интересно обсуждаются компромиссы при проектировании распределенных систем.
#DistributedSystems #Architecture #SystemDesign #Software #Databases
YouTube
Local-First Software: Taking Back Control of Our Data | a mini-doc
Most modern software assumes your data lives in the cloud. As long as you’re online, everything works. When you’re not, it often doesn’t.
Local-First software starts from a different idea - that your data should live on your device: fast, responsive, and…
Local-First software starts from a different idea - that your data should live on your device: fast, responsive, and…
❤10🔥9⚡1
Update: SDS (System-Design.Space)
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.
В общем, мне очень нравится дорабатывать и расширять сайт. Если у вас есть идеи улучшений или репорты о багах, то пишите в комменты и я их учту в планах разработки
#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software
System Design Space
System Design Space — Проектируй лучшие системы и проходи интервью
Изучай System Design для создания надёжных масштабируемых систем и успешного прохождения технических собеседований.
1🔥57❤10⚡3
The Man Who Revolutionized Computer Science With Math (Рубрика #DistributedSystems)
В этом видео Лэсли Лэмпорт за 8 минут рассказывает про специальную теорию относительности, причинность и распределённые системы, а также как это все свзяано между собой. Это видео - короткое интервью Quanta Magazine где он объясняет смысл своей классической фразы
- Lamport clocks + happens‑before: как упорядочивать события без «общих часов»
- Paxos и replicated state machine: фундамент отказоустойчивых кластеров/хранилищ
- LaTeX: де‑факто стандарт научной вёрстки
- TLA+: спецификации + model checking, чтобы ловить дизайн‑баги до кода
Самое вкусное в этом интервью - это рассказ про связь специальной теории относительности из физики и теории распределенных систем из информатики. Мне как учившемуся на Физтехе очень понравилась эта часть про мультидисциплинарность и пользу физики (хотя я учился на факультете прикладной математики, но физика у нас выдавалась всем так, чтобы никто не ушел обиженным от того, что ее недополучил). Так вот, в СТО (специальной теории относительности) нет универсального "сейчас": наблюдатели могут спорить, что было раньше. Но они не спорят о причинности - событие A может повлиять на B только если сигнал (не быстрее света) мог дойти от A до B. И Лэсли Лэмпорт перенес это 1‑в‑1 в распределённые системы:
- Нет глобального времени (латентности, дрейф, партиции)
- Зато есть причинный частичный порядок: "могла ли информация из A повлиять на B"
В итоге, в распределёнке важнее порядок, совместимый с причинностью, чем "точные таймстемпы". Отсюда появились логические часы, тотальный порядок поверх частичного и согласованная эмуляция одной последовательной state machine несколькими узлами. В общем, я раньше не знал как Лэсли к этому всему пришел, а тут узнал и понял, что действительно это блестящая игра разума.
Но если возвращаться на грешную землю, то можно почерпнуть такие инсайты для инженеров и технических руководителей
- Programming ≠ coding. Код - последняя миля. До него должны появиться модель поведения и явные допущения (сеть, сбои, порядок сообщений, часы).
- "Алгоритм без доказательства - гипотеза". Даже если вы не пишете формальные доказательства, TLA+/модель‑чекер часто ловят те баги, которые тестами почти не поймать.
- Ищите причинность. Когда спорите о порядке операций в БД/кэше/очереди - спрашивайте не "который час был раньше", а "какая информация могла попасть куда".
Ну и отдельный момент про любимый алгоритм Лэсли "Bakery (mutual exclusion)". Здесь метафора пекарни работает так: каждый процесс берёт «номерок», и в критическую секцию входит минимальный (при равенстве - по id). В оригинальной работе он даже отмечает, что такие "номерки" можно реализовать распределённо: хранить у владельца процесса и читать по сети.
Красота в том, что алгоритм корректен даже при очень слабых предположениях о памяти: чтение, пересекающееся с записью, может вернуть произвольный "мусор", а докатазательство всё равно работает. Лэмпорт понял это, когда дописывал доказательство - это отличный аргумент, зачем вообще писать спецификации/доказательства: они находят свойства, которых вы "не закладывали".
#DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign
В этом видео Лэсли Лэмпорт за 8 минут рассказывает про специальную теорию относительности, причинность и распределённые системы, а также как это все свзяано между собой. Это видео - короткое интервью Quanta Magazine где он объясняет смысл своей классической фразы
Вы понимаете, что пользуетесь распределенной системой, когда поломка компьютера, о существовании которого вы даже не подозревали, приводит к останову всей системы, а для вас - к невозможности выполнить свою работуНо лучше сначала расскзать, а чем известен Лэсли Лампорт, который получил премию Алана Тьюринга (аналог Нобелевской, но в информатике). За ним числятся
- Lamport clocks + happens‑before: как упорядочивать события без «общих часов»
- Paxos и replicated state machine: фундамент отказоустойчивых кластеров/хранилищ
- LaTeX: де‑факто стандарт научной вёрстки
- TLA+: спецификации + model checking, чтобы ловить дизайн‑баги до кода
Самое вкусное в этом интервью - это рассказ про связь специальной теории относительности из физики и теории распределенных систем из информатики. Мне как учившемуся на Физтехе очень понравилась эта часть про мультидисциплинарность и пользу физики (хотя я учился на факультете прикладной математики, но физика у нас выдавалась всем так, чтобы никто не ушел обиженным от того, что ее недополучил). Так вот, в СТО (специальной теории относительности) нет универсального "сейчас": наблюдатели могут спорить, что было раньше. Но они не спорят о причинности - событие A может повлиять на B только если сигнал (не быстрее света) мог дойти от A до B. И Лэсли Лэмпорт перенес это 1‑в‑1 в распределённые системы:
- Нет глобального времени (латентности, дрейф, партиции)
- Зато есть причинный частичный порядок: "могла ли информация из A повлиять на B"
В итоге, в распределёнке важнее порядок, совместимый с причинностью, чем "точные таймстемпы". Отсюда появились логические часы, тотальный порядок поверх частичного и согласованная эмуляция одной последовательной state machine несколькими узлами. В общем, я раньше не знал как Лэсли к этому всему пришел, а тут узнал и понял, что действительно это блестящая игра разума.
Но если возвращаться на грешную землю, то можно почерпнуть такие инсайты для инженеров и технических руководителей
- Programming ≠ coding. Код - последняя миля. До него должны появиться модель поведения и явные допущения (сеть, сбои, порядок сообщений, часы).
- "Алгоритм без доказательства - гипотеза". Даже если вы не пишете формальные доказательства, TLA+/модель‑чекер часто ловят те баги, которые тестами почти не поймать.
- Ищите причинность. Когда спорите о порядке операций в БД/кэше/очереди - спрашивайте не "который час был раньше", а "какая информация могла попасть куда".
Ну и отдельный момент про любимый алгоритм Лэсли "Bakery (mutual exclusion)". Здесь метафора пекарни работает так: каждый процесс берёт «номерок», и в критическую секцию входит минимальный (при равенстве - по id). В оригинальной работе он даже отмечает, что такие "номерки" можно реализовать распределённо: хранить у владельца процесса и читать по сети.
Красота в том, что алгоритм корректен даже при очень слабых предположениях о памяти: чтение, пересекающееся с записью, может вернуть произвольный "мусор", а докатазательство всё равно работает. Лэмпорт понял это, когда дописывал доказательство - это отличный аргумент, зачем вообще писать спецификации/доказательства: они находят свойства, которых вы "не закладывали".
#DistributedSystems #Software #Engineering #Architecture #Leadership #SystemDesign
YouTube
The Man Who Revolutionized Computer Science With Math
Leslie Lamport revolutionized how computers talk to each other. The Turing Award-winning computer scientist pioneered the field of distributed systems, where multiple components on different networks coordinate to achieve a common objective. (Internet searches…
❤12🔥6👍3
Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)
Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space
Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру
Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.
Встречаемся завтра c кофе ☕️ в 11:00 на YouTube
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Завтра, 21 февраля, в 11 часов утра по Москве мы с Гришей из клуба { между скобок } решили собраться и поговорить про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space
Мы точно обсудим вопросы, что есть в программе встречи
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты
• Что на самом деле проверяют на System Design интервью
• Как отличить «рисование кубиков» от настоящего архитектурного мышления
• Какие темы обязательно нужно понимать senior / staff инженеру
Но также думаю, что затронем вопросы системного мышления и фундаментальной подготовки, а не просто запоминания задач.
Встречаемся завтра c кофе ☕️ в 11:00 на YouTube
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Telegram
{ между скобок } анонсы 📣
21 февраля 11:00 по мск Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками — https://system-design.space.
Мы обсудим:
• Почему книга не лучший…
👍17❤10🔥6
Дискуссия с Гришей Скобелевым про подготовку к System Design Interview (Рубрика #Architecture)
На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие
- Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию"
- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования
- Разобрали типовые ошибки кандидатов
- - Сразу рисовать «кубики и стрелочки» без уточнения ограничений,
- - Оптимизировать за пределами реальных bottleneck’ов
- - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.)
- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры
- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии
- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями
- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения.
Если говорить про инсайты для руководителей, которыми можно поделиться, то
- Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно
Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника.
- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах).
- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги.
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
На этих выходных мы с Гришей из клуба { между скобок} поговорили про подготовку к System Design Interview и про то, как я дошел до жизни такой, что собрал сайт system-design.space. Основные моменты, что мы успели обсудить следующие
- Книга по System Design быстро устаревает: паттерны и требования меняются, а живой сайт можно непрерывно допиливать под практику, а не под "вечную теорию"
- Ожидания на интервью сдвигаются от "знаешь ли ты стандартный набор сервисов и buzzwords" к умению думать как архитектор: трезво выбирать компромиссы, задавать вопросы, формализовывать требования
- Разобрали типовые ошибки кандидатов
- - Сразу рисовать «кубики и стрелочки» без уточнения ограничений,
- - Оптимизировать за пределами реальных bottleneck’ов
- - Заучивать шаблоны задач вместо понимания инвариантов (consistency, durability, latency budgets и т.д.)
- System Design интервью на самом деле проверяет не "знаешь ли ты Kafka", а: как ты принимаешь решения, как разговариваешь с продакт менеджером, как эволюционируешь систему от MVP до сложной архитектуры
- Разница между "рисованием кубиков" и архитектурным мышлением: во втором случае ты всегда привязываешь решения к пользовательским сценариям, нагрузке, отказоустойчивости и стоимости владения, а не просто перечисляешь модные технологии
- Для senior/staff обязательны темы: масштабирование хранения и вычислений, очереди и асинхрованная работа, кэширование, консистентность, observability, эволюция схемы данных и rollouts, а также работа с неопределённостью и неполными требованиями
- Готовиться нужно не "по чек-листу задач", а системно: строить свой набор инвариантов и шаблонов мышления, прогонять реальные кейсы, а не просто зубрить решения.
Если говорить про инсайты для руководителей, которыми можно поделиться, то
- Интервью по SD стоит перестраивать с "угадай сервис" на разбор реального кейса: дать неполные требования, посмотреть, как кандидат уточняет, режет scope и развивает архитектуру итеративно
Хорошее SD-интервью - это мини-совместное проектирование: вы вместе выходите хотя бы к первому адекватному приближению системы, а не к идеальной картинке из учебника.
- Стоит явно формализовать, какие уровни архитектурного мышления вы ждёте от middle/senior/staff, и дать людям прозрачную лестницу роста (в идеале - с примерами на внутренних кейсах).
- Вместо того чтобы ждать от команды "чтения книг по SD", проще дать живую базу практик, чек-листы и разборы постмортемов - то есть institutional knowledge, а не набор ссылок на классические книги.
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
YouTube
Александр Поломодов: Как на самом деле готовиться к System Design интервью
Саша решил не писать книгу по System Design, а создать живой сайт с лучшими практиками - https://system-design.space.
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
Мы обсудим:
• Почему книга не лучший формат для System Design
• Как меняются ожидания на интервью
• Какие ошибки чаще всего допускают кандидаты…
1❤15🔥11👍8
Граф знаний сайта system-design.space (Рубрика #SystemDesign)
Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи.
Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ
- Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются
- Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу
- Скролл / pinch позволяыт зумить. При приближении появляются названия глав
- Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить
- Цвета узлов соответствуют своим темам (кластерам)
- По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные
- Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии.
Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить).
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
Материалов на сайте про system design стало слишком много и мне самому потребовалось средство для визуализации тем, глав и связей между ними. Так у меня получился граф знаний, который показывает 222 глав и 820 связей между ними. Каждый узел - это глава книги, а линия - смысловая связь между материалами. Связи строятся по перекрёстным ссылкам внутри контента глав: MarginNote на полях справа, ссылки из блоков "связанные главы" в конце глав и ссылки, что раскиданы по тексту статьи.
Я планирую в будущем добавить в этот граф возможность выбора траекторий изучения, но пока он работает попрощ
- Клик по кластеру в сайдбаре приводит к зуму и фокусу на главы из этой темы, а остальные главы затемняются
- Клик по ноде в графе открывает панель с деталями главы, списком связанных глав и появляется кнопка перехода к материалу
- Скролл / pinch позволяыт зумить. При приближении появляются названия глав
- Перетаскивание - можно передвигаться по графу или если потянуть за отдельный узело, то можно его перместить
- Цвета узлов соответствуют своим темам (кластерам)
- По разному отмечаются связи внутри кластера и между кластерами + сами связи направленные
- Для отрисовки графа используется force-directed layout (d3-force): узлы отталкиваются друг от друга, а связи притягивают. В итоге связанные главы оказываются рядом, а изолированные - на периферии.
Я использовал этот граф сам для того, чтобы проверить, что у меня я сам не забыл добавить кросс-ссылки между темами (на самом деле забыл и граф мне позволил это исправить).
#SystemDesign #Architecture #DistributedSystems #Career #Interview #Engineering
🔥40👍14❤9👏1