The history of C# and TypeScript with Anders Hejlsberg | GitHub (Рубрика #Software)

Интересное интервью Андерса Хейлсберга, создателя C#, Delphi, Turbo Pascal и ведущего архитектора TypeScript, которое он дал GitHub. Андреас разбирает, как создавались C# и TypeScript и какие компромиссы стояли за решениями и какие принципы помогают языкам и командам "жить долго".

Из получасовго интервью можно почерпнуть много интересного
1️⃣ Быстрый фидбек важнее почти всего
Короткий цикл «написал → сразу понял/проверил» определяет скорость и качество. Поэтому ценность TypeScript - не только в типах, но и в инструментах: подсказки, проверка, рефакторинг, быстрый компилятор.
2️⃣Масштаб требует жертвовать личным идеалом
Когда пользователей и сценариев много, побеждает прагматика: язык успешен, если вписывается в реальную работу команд, а не только в учебник.
3️⃣ Эволюция сильнее революции
TypeScript вырос как надстройка над JavaScript: улучшает поддерживаемость больших проектов, не заставляя «сжигать мосты» и менять экосистему.
4️⃣ Прозрачность ускоряет open source
Публичные PR/issue и обсуждения переводят приоритеты от "внутренних" к реальным потребностям, а решения становятся объяснимыми и проверяемыми.
5️⃣ Иногда нужен рывок в основании без ломки внешнего контракта
Переписывание критического компонента ради производительности имеет смысл, если пользователь не платит ценой совместимости.
6️⃣ Эпоха AI смещает роль инженера
Всё больше кода генерируется, а ценность инструментов - в точности: типы, проверки, тесты и рефакторинг как ограждения от правдоподобных ошибок.
7️⃣ "Память проекта" - это актив
История обсуждений и решений (почему сделали так, а не иначе) снижает повторение ошибок и облегчает онбординг.

Если эти lessons learned превратить в какие-то выводы, то они могу быть такими

Для инженеров
- Инвестируйте в быстрый цикл: локальные проверки, быстрые тесты, линтеры/типы, удобные IDE-инструменты.
- Пишите для "коллективного владения": читаемость, предсказуемость, простые правила важнее личной элегантности.
- Учитесь по контексту решений: обсуждения в issue/PR часто дают больше, чем абстрактные «best practices».
- При работе с AI-кодом усиливайте страховку: типизация + статанализ + тесты, иначе вы просто быстрее генерируете долг.

Для технических руководителей
- Ставьте скорость обратной связи в KPI инженерной системы: CI, тесты, статанализ, быстрые сборки. Медленный фидбек рождает процессы-«костыли».
- Держите баланс интересов: стандарты и совместимость важнее вкуса отдельных сильных инженеров.
- Внедряйте изменения через миграции и совместимость: постепенное улучшение обычно дешевле и надёжнее тотальной замены.
- Стройте институциональную память: ADR/решения, ссылки на обсуждения, понятные причины компромиссов - это снижает риски при росте и текучести.

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

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture #RnD

[1/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)

Anthropic опубликовала любопытный отчёт о ключевых трендах "агентного кодинга" на 2026 год. Этот документ рисует картину того, что разработка всё больше опирается на AI-агентов, которые пишут код, пока люди задают им цели и контролируют результат. Они приводят статистику, что разработчики Anthropic используют AI в 60% задач, хотя полностью доверяют ему лишь 0–20% работы (это из их декабрьской статьи "How AI is transforming work at Anthropic", о которой я уже рассказывал). В новом документе они приводят кейсы и других компаний, который смогли добиться значимых результатов, но все-таки фокус на 8 тенденциях, что сгруппированы в три категории: foundation trends, capability trends, impact trends. Ну и ниже я расскажу про каждый из трендов, а также поделюсь мыслями, а что делать с ними инженерам и руководителям

1️⃣ Foundation trends: The tectonic shift

Trend 1: The software development lifecycle changes dramatically
SDLC остаётся, но цикл сжимается: агент пишет/дебажит/документирует, тесты и мониторинг быстрее замыкают фидбек (недели → часы).
- Инженерам стоит начать прокачивать «оркестрацию» (декомпозиция, постановка задач агенту, критерии приёмки, быстрый ревью).
• CTO стоит пересобрать процесс и метрики (меньше “время на задачу”, больше “качество+output”), и реально использовать “онбординг за часы” для динамического перераспределения людей по продуктам/проектам

2️⃣ Capability trends: What agents can do

Trend 2: Single agents evolve into coordinated teams
Один агент → команда агентов с ролями + оркестратор. Это про параллельную работу и синхронизацию в VCS. Пример из отчёта: multi-agent оркестрация дала Fountain 50% быстрее screening и сократила срок укомплектования нового центра до <72 часов.
- Инженерам надо научиться резать задачи так, чтобы их можно было делать параллельно (и собирать через PR/чеки).
- CTO стоит внедрять паттерны multi-agent (роли, протоколы, правила мержа/ревью для “агентских” изменений).

Trend 3: Long-running agents build complete systems
Агенты работают «долго»: часы → дни/недели. Могут тащить фичу/подсистему целиком, закрывать техдолг, делать “невыгодные руками” улучшения. Пример: Rakuten прогнали Claude Code по задаче в vLLM (12,5 млн строк) - 7 часов автономной работы и 99,9% точности.
- Инженерам пора начать мыслить чекпоинтами (контракты, тесты, инварианты) и строить ограждения, чтобы агент не «уехал».
- CTO стоит подготовить среду для длинных прогонов (sandbox, CI, лимиты, наблюдаемость) и выделить задачи “под агента” (миграции, рефакторинги, чистка бэклога).

Trend 4: Human oversight scales through intelligent collaboration
Ключ в том, чтобы масштабировать контроль. Агенты учатся звать человека, а не молча “дожимать”; AI проверяет AI (security/архитектура/качество), человек смотрит только «что важно».
- Инженерам надо собирать пайплайн “генерация → автопроверки → человек”.
- CTO стоит формализовать уровни риска и эскалации (что агент может сам, что только через человека), инвестировать в автоматизированный ревью/тестирование.

Trend 5: Agentic coding expands to new surfaces and users
Агентный кодинг выходит за IDE: больше языков (включая legacy типа COBOL/Fortran), больше ролей (ops, security, design, DS), больше интерфейсов для не-разработчиков.
- Инженерам пора готовиться к "коду от доменных экспертов" - нужны шаблоны, guardrails, API/платформа, чтобы это было безопасно. Тут можно вспомнить про условный Lovable и приложения, что продакты сгенерировали через него
- CTO надо сознательно открывать агентные инструменты другим отделам, но через песочницы, права доступа и наблюдаемость.

В продолжении я расскажу про последние три тренда из этого интересного отчета.

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

[2/2] 2026 Agentic Coding Trends Report - How coding agents are reshaping software development (Рубрика #AI)

В этом посте мы закончим разбирать короткий trend-report Anthropic, который задает фокус того, что стоит делать в 2026 году нам как инженерам и руководителям, чтобы не отстать от стремительно меняющейся индустрии разработки софта.

3️⃣ Impact trends: What agents may change in 2026

Trend 6: Productivity gains reshape software development economics
Эффект - не только "быстрее", но "больше": растёт объём shipped-результата, появляется работа, которую раньше бы не делали (в отчёте ~27% AI-задач - “не сделали бы иначе”). TELUS, например, сделали 13k внутренних AI-решений и ускорили shipping кода на 30%, сэкономив 500k+ часов.
- Инженерам надо пересмотреть приоритеты - закрывать техдолг и “papercuts” становится выгодно.
• CTO стоит ожидать “взрыва output” и заранее ставить рамки качества, иначе скорость съест поддерживаемость.

Trend 7: Non-technical use cases expand across organizations
Неинженерные команды начинают автоматизировать процессы сами: меньше тикетов в разработку, больше локальных “мини-продуктов”. Zapier в отчёте - 89% adoption и 800+ внутренних агентов; у Anthropic юристы сократили маркетинг-ревью до 24 часов, причём self-service инструменты собрал юрист без опыта кодинга.
- Инженерам надо помогать через внутренние библиотеки/коннекторы/примеры, а не “делать за всех”.
- CTO пора строить governance для citizen devevelopers (что можно автоматизировать, где хранятся секреты, кто отвечает за поддержку).

Trend 8: Dual-use risk requires security-first architecture
Агентный кодинг усиливает и защиту, и атаки. Любой инженер может делать security-review с агентом - и любой атакующий тоже масштабирует свои попытки.
- Инженерам надо двигать практики безопасности: “least privilege” для инструментов агента, изоляция, журналирование, защита от инъекций/подмены контекста.
- CTO надо идти в security by design агентных систем (права, контуры, аудит, red teaming) до того, как агенты получат доступ к продовым данным/деплою.

Если свести отчёт к одному тезису: выиграют команды, которые научатся
- Ууправлять несколькими агентами
- Масштабировать контроль качества
- Безопасно расширить агентные инструменты за пределы инженерии

#AI #Engineering #Software #Management #Leadership #Startup #LLM #ML #Architecture

Путешествие в Лондон (Рубрика #Travel)

Через пару недель мы с женой сгоняем на недельку в Лондон, где мы побываем впервые:) Когда я начинал учить английский в школе в Северодвинске и проговаривал "London is the capital of Great Britain" я и представить не мог, что когда-то поеду в этот самый London. Правда, сейчас путешествия уже стали рутиной, но я попросил жену добавить в нашу поездку посещение Блетчли-парка, где в период Второй мировой войны в Блетчли-парке располагалось главное шифровальное подразделение Великобритании, а сейчас там расположен Национальный музей компьютеров. Все остальные достопримечательности подбирала моя жена, которой я верю больше чем себе в вопросе планирования досуга:) А ближе к концу апреля мы поедем в Лондон уже с детишками, благо UK - это не Португалия, а значит дает нормальные визы (на полгода).

В общем, я уже предвкушаю интересную поездку:)

P.S.
Если кто 28 февраля будет в Лондоне и захочет пообщаться, то пишите в личку - мы выделили это воскресенье под встречи со своими знакомыми, кого сложно встретить в Москве:)

#Travel #Software #Engineering #History

Interview with ‘Just use a VPS’ bro (OpenClaw version) (Рубрика #AI)

Я давно так не смеялся, как с этого видео:) С учетом того, что я сам люблю возиться с Linux, то юмор попал в точку - раньше приходилось читать мануалы, а сейчас мне с этими настройками помогают всякие perplexity. В этом видео высмеивается стереотипный "сисадмина-параноик" и культура селфхостинга (self-hosting). Юмор строится на контрасте между простым желанием пользователя ("Я просто хочу запустить AI-агента") и безумно сложным, перегруженным инструктажем от "VPS-бро", для которого "просто" означает полноценную настройку Linux-сервера с нуля. В конце, когда пользователь отчаивается и просит сменить агента, что ему помогает, появляется новый "консультант", который начинает затирать про AWS EC2, Security Groups и Kubernetes. Шутка в том, что убегая от сложности Linux пользователь проваливается еще глубже в кроличью нору (прямо как Алиса).

В общем, автор этого канала просто топ, рекомендую его всем знакомым айтишникам:)

#Humor #Engineering #Software #AI #DevOps #DevEx

Update: SDS (System-Design.Space)

С прошлого апдейта я не останавливал работу над проектом и добавил на сайт кучу нового:
- Добавил уровень сложности для глав и разметил их
- Добавил фильтрацию по типу материала и сложности
- Добавил возможность отслеживать прогресс прохождения, отмечая пройденные главы, а таже возможность откладывать главы в закладки (это завязано на local storage, поэтому пока не переносится по устройствам)
- Добавил много интерактивных архитектурных диаграмм в часть с задачами/кейсами
- Добавил в базовые практики проектирования главы про балансировку трафика, кеши, асинхронность
- Добавил части про безопасность и фронтовую архитектуру
- Добавил кучу глав в разные части программы.

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

#SystemDesign #Interview #Career #Architecture #DistributedSystems #Databases #Engineering #Software

Бывший CEO GitHub стартанул новую компанию для создания новой платформы для разработчиков (Рубрика #Engineering)

Интересная новость от Томаса, который недавно ушел из Microsoft (а точнее из GitHub), чтобы заняться своим стартапом. Он вышел из неизвестности с анонсом компании "EntireHQ", которая подняла $60 млн в сид раунде с оценкой в $300 млн на создание новой платформы с примерно таким видением
- Git‑совместимая база данных, объединяющая код, намерение, ограничения и рассуждения в единую систему с контролем версий.
- Универсальный семантический слой рассуждений, позволяющий координацию нескольких агентов через граф контекста.
- AI‑native интерфейс, который заново изобретает жизненный цикл разработки ПО для сотрудничества "агент–человек"

Это видение обусловлено тем, что за последние три месяца фундаментальная роль разработчика ПО была фактически "пересобрана". Невероятные улучшения в последних моделях от Anthropic, Google и OpenAI сделали кодинговых агентов настолько хорошими, что во многих ситуациях теперь проще написать промпт, чем вручную писать код. Терминал снова стал центром притяжения на наших компьютерах. Лучшие инженеры могут одновременно запускать десяток агентов.

Ну и компания не просто анонсировала сид-раунд и видение - ребята уже выкатили продукт Checkpoints, который автоматически сохраняет контекст агента. С этим новым кубиком мы получаем автоматическое сохранение контекста агента как данных первого класса, с версионированием в Git. Когда вы коммитите код, сгенерированный агентом, Checkpoints сохраняет полную сессию вместе с коммитом: транскрипт, промпты, затронутые файлы, расход токенов, вызовы инструментов и многое другое. Ребята уже опубликовали этот продукт в виде open‑source CLI на GitHub.

Будет очень интересно следить за начинаниями ребят - тем более Томас обещал, что они будут разрабатывать свой продукт в формате Open Source.

#AI #Software #Engineering #Architecture #Agents #Software #ML #Leadership #Startup

The rise of the professional vibe coder (Рубрика #Engineering)

На днях у Ленни вышло интервью про вайб кодинг с Лазаром Йовановичем из Lovable (его должность буквально “Professional Vibe Coder”). И там отлично сформулировано то, что как использовать Lovable и не только для вайб инжиниринга и быстрой поставки фичей в свое приложение. Из интеррвью можно получить много инсайтов, среди которых следующие

Что такое vibe engineering (по‑честному)
- Это переход от "микроменеджмента синтаксиса" к управлению намерениями
- Раньше: пишешь классы/циклы, гуглишь ошибки, дебажишь полдня
- Теперь: описываешь что должно быть (UX, бизнес-логика, ограничения, edge cases) → AI строит решение → ты валидируешь как продакт и инженер одновременно

Я прямо на system-design.space это все проходил и это действительно так и работает - за вечер и часть ночи я пересобрал сборку проекта, оптимизировав производительность + SEO, переехал на другой хостинг (как раз съехал с Lovable), добавил поиск по сайту. В общем, это очень вдохновляющий опыт - цикл обратной связи коротки и от идеи до результата проходят часы.

Лазар формулирует работу в своем видео как формулировку "желания джинну"
- Что за продукт/фича
- Кто пользователь
- Что считается “готовым” или критерии DoD (definition of done)
- Ограничения (данные, доступы, SLA, безопасность)
И у него в Lovable за 20–40 минут получается скелет: UI, API, модели, базовую логику. Это момент, когда из головы появляется "что-то кликабельное", и команда перестаёт спорить абстракциями.

И я примерно так стартую проекты - с условного визуала. Но потом я иду в Codex и докручиваю то, что отличает демку от продакшена: проверки, обработка ошибок, миграции, тесты, логирование, права доступа, рефакторинг. Наверное, можно это делать и в Lovable, но мне удобнее делать это по другому. В итоге, получаются короткие итерации: собрал → кликнул → сломал → уточнил промпт → повторил. Время цикла - часы, не спринты.

Главный инсайт из интервью относится к не-технарям
Они могу быть реально быстрее инженеров, потому что их не засасывает в "а давай выберем библиотеку/идеальную архитектуру". Они держат в голове только одно: ценность для пользователя.
Но я как технарь и руководитель добавлю: качество и ответственность никуда не делись - просто точка приложения усилий сместилась. И дальше все равно

Если оцеивать, а что такой подход меняет для рынка и команд, то на ум приходит следующее
- Умение писать бойлерплейт обесценилось. Ценится то, что раньше было "поверх кода": декомпозиция, архитектура, продуктовый вкус, ответственность за риск.
- Роли продакт-менеджеров и инженеров размываются. Появляется гибрид: product engineer, который может придумать и сразу собрать продукт
- Для MVP и внутренних тулов это вообще чит‑код: закрывать бэклог можно силами 1–2 людей, если у них сильный product sense + дисциплина.

Но есть и тёмная сторона “вайба”:
Если просто «навайбить» без рамок - получишь красивый интерфейс с дырявой безопасностью и техдолгом, который взорвётся через квартал. Поэтому мой rule of thumb:
✅ Вайб - для скорости и формы,
✅ Инженерия - для границ (security, доступы, тесты, наблюдаемость, данные),
✅ Ответственность - всегда на людях, не на модели.

Короче: делать продукт стало проще, но делать его хорошо - всё ещё требует профессиональных навыков. Просто теперь эти навыки - это не набор синтаксических трюков, а способность быстро и точно "заказывать" систему и доводить её до надёжного состояния.

#AI #VibeEngineering #Product #Software #Architecture #Lovable #Codex #Productivity #Management #Leadership