Многие с появлением AI инструментов поверили, что разработчики не нужны и агенты будут «писать код за человека». Это главное заблуждение, на мой взгляд.
В марте прошла AI Dev Day 2026 от Яндекса. Эта конференция стала моментом истины для всей индустрии. Главный вопрос - стали ли разработчики действительно продуктивнее спустя год тотальной «нейронизации»?
Авито представили данные внутреннего исследования: написание кода занимает лишь 32% времени разработчика. Если ваш AI-агент станет идеальным, получится сэкономить только треть рабочего дня. Цифры из Яндекса аналогичные - разработчики тратят 35% на написание кода, 30% времени на коммуникации, 15% на планирование и поиск информации, и по 5% на DevOps, работу с данными и кодревью.
Я посмотрел не все, только некоторые выступления. В частности, ТБанк представил довольно интересные метрики на основе технических данных (DORA), удовлетворенности (SPACE) и когнитивной нагрузки (DevEx). Но слишком мало подробностей. Конечно хотелось бы услышать, как считали и как подкручивали процессы.
Понятно, что для опытного разработчика это помощник, не заменитель. На практике агенты способны закрывать лишь часть рутинной работы. Более того, опыт сеньоров становится еще более критичным: например, в Amazon именно senior-инженеров явно просят валидировать изменения в коде, которые вносят ИИ-модели и менее опытные сотрудники.
Компании понимают, что оптимизировать надо не только написание кода, но и остальные блоки, и прилагают усилия к уменьшению времени поиска, ускорению код ревью и тд. Общая производительность определяется не суммой усилий всех участников, а пропускной способностью одного единственного узкого места.
#ai
NgStream
В марте прошла AI Dev Day 2026 от Яндекса. Эта конференция стала моментом истины для всей индустрии. Главный вопрос - стали ли разработчики действительно продуктивнее спустя год тотальной «нейронизации»?
Авито представили данные внутреннего исследования: написание кода занимает лишь 32% времени разработчика. Если ваш AI-агент станет идеальным, получится сэкономить только треть рабочего дня. Цифры из Яндекса аналогичные - разработчики тратят 35% на написание кода, 30% времени на коммуникации, 15% на планирование и поиск информации, и по 5% на DevOps, работу с данными и кодревью.
Я посмотрел не все, только некоторые выступления. В частности, ТБанк представил довольно интересные метрики на основе технических данных (DORA), удовлетворенности (SPACE) и когнитивной нагрузки (DevEx). Но слишком мало подробностей. Конечно хотелось бы услышать, как считали и как подкручивали процессы.
Понятно, что для опытного разработчика это помощник, не заменитель. На практике агенты способны закрывать лишь часть рутинной работы. Более того, опыт сеньоров становится еще более критичным: например, в Amazon именно senior-инженеров явно просят валидировать изменения в коде, которые вносят ИИ-модели и менее опытные сотрудники.
Компании понимают, что оптимизировать надо не только написание кода, но и остальные блоки, и прилагают усилия к уменьшению времени поиска, ускорению код ревью и тд. Общая производительность определяется не суммой усилий всех участников, а пропускной способностью одного единственного узкого места.
#ai
NgStream
YouTube
AI Dev Day // 15 марта 2026
AI Dev Day — митап Яндекса, посвящённый реальному опыту внедрения AI-инструментов в процессы разработки. Вместе с руководителями и инженерами из Яндекса, Авито, Сбера, Т-Банка и Ozon мы поговорим об эффективности. Разберём, как измеряют полезность AI в разработке…
👍9
Обратная связь SBI
Месяца три назад я писал о корректирующей обратной связи и обещал поделиться инструментом для нее. Так вот, этот инструмент - модель SBI. Мне её посоветовал бывший руководитель. Я уже понял, что она отлично работает, и стараюсь использовать её в работе.
Рассмотрим на примере. Допустим, вы обсуждаете получившуюся ситуацию с коллегой.
Сначала описываем ситуацию (Situation): «На проекте X, в рамках спринта, который завершился вчера…»
Затем фиксируем поведение/факт (Behavior): «…я увидел, что два коммита, связанные с задачей A, были внесены после дедлайна, и код не прошёл ревью.»
И наконец, объясняем влияние (Impact): «Из-за этого: 1) QA не успели протестировать фичу, 2) релиз отложен на день, 3) команде пришлось экстренно менять план.»
Почему это работает?
Мы показываем последствия, а не навешиваем ярлыки. Человек часто не видит цепочку последствий своих действий. Это превращает обратную связь из личного упрёка в анализ системной проблемы. Такой подход убирает обвинения («ты непрофессионален») и переводит разговор в плоскость конкретных фактов и их системных последствий.
Важно дать ее вовремя (не сразу же на эмоциях, но и не по прошествии долгого времени), по фактам (максимально безоценочно), с уважением к человеку (когда мы разделяем: ты хороший человек, но поступил в конкретной ситуации не самым эффективным образом).
Кстати, случайно, у меня получилась отдельная серия постов на тему обратной связи.
#нетехзаметки
NgStream
Месяца три назад я писал о корректирующей обратной связи и обещал поделиться инструментом для нее. Так вот, этот инструмент - модель SBI. Мне её посоветовал бывший руководитель. Я уже понял, что она отлично работает, и стараюсь использовать её в работе.
Рассмотрим на примере. Допустим, вы обсуждаете получившуюся ситуацию с коллегой.
Сначала описываем ситуацию (Situation): «На проекте X, в рамках спринта, который завершился вчера…»
Затем фиксируем поведение/факт (Behavior): «…я увидел, что два коммита, связанные с задачей A, были внесены после дедлайна, и код не прошёл ревью.»
И наконец, объясняем влияние (Impact): «Из-за этого: 1) QA не успели протестировать фичу, 2) релиз отложен на день, 3) команде пришлось экстренно менять план.»
Почему это работает?
Мы показываем последствия, а не навешиваем ярлыки. Человек часто не видит цепочку последствий своих действий. Это превращает обратную связь из личного упрёка в анализ системной проблемы. Такой подход убирает обвинения («ты непрофессионален») и переводит разговор в плоскость конкретных фактов и их системных последствий.
Важно дать ее вовремя (не сразу же на эмоциях, но и не по прошествии долгого времени), по фактам (максимально безоценочно), с уважением к человеку (когда мы разделяем: ты хороший человек, но поступил в конкретной ситуации не самым эффективным образом).
Кстати, случайно, у меня получилась отдельная серия постов на тему обратной связи.
#нетехзаметки
NgStream
👍6❤2
В офисах ИТ компаний в воздухе все чаще слышно напряженное гудение, пока нейросети на "сверхзвуковых скоростях" развертывают целые модули и генерируют тысячи строк кода в секунду.
Вышедший недавно State of AI 2026, говорит, что 56% кода, в среднем, генерируется AI. Год назад было 28%. А доля тех, кто генерирует 75%+ кода, выросла сильнее всего. Ресурс говорит, что поучаствовало 7 258 разработчиков. Выборка смещена в сторону тех, кто уже использует AI, но тренды внутри неё показательные. Еще один показатель - частота использования. Доля разработчиков, использующих AI "постоянно", удвоилась за год.
Помните мой прошлый пост? Я писал, что AI - усилитель, а не замена. Эти цифры это подтверждают, но с тревожным нюансом.
Когда AI генерирует больше половины кода, проверять его становится отдельной профессией. И это проверка требует больше опыта, чем написание с нуля. При этом, старшие разработчики нужны ещё больше - именно они могут заметить галлюцинацию или архитектурную ошибку, которую сгенерировала модель. Кода генерируется больше и быстрее, но появляется дополнительная нагрузка на проверку и синхронизацию внутри команды. И еще немаловажно, что ты быстрее устаешь, потому что больше времени тратишь на проверки.
Этот "налог на ревью", в первую очередь, бьет по Senior инженерам. На них обрушивается лавина посредственного кода. Да, можно сказать, прикрутите ИИ ревьюера и дело в шляпе. Это означает, упростить проверку, но не решить проблему, на мой взгляд. Все-таки ответственность за баги по-прежнему несет человек, а не модель! Кстати, кто прикрутил ревьюера, пишите в комментариях, интересен ваш опыт:)
ИИ действительно ускоряет написание кода, но не так, как любят показывать в маркетинге. Более реальные цифры - в исследовании. Это, примерно, 7-8% прироста производительности, но часть этого потом идет на ревью и дополнительные затраты на координацию. Команды постепенно уходят от общих метрик и начинают смотреть на cycle time, cognitive load. И больше кода уже не равно “быстрее delivery”.
Что делать?
Если в вашей команде AI уже генерирует 50%+ кода - спроси себя:
- Кто и как проверяет эти 50%?
- Сколько времени уходит на исправление AI-багов?
- Не растёт ли когнитивная нагрузка на сеньоров?
По моему мнению, генерация кода подорожала по деньгам, но не подешевела по времени на отладку. Просто время перетекло из "написать" в "проверить и переписать".
Если вам интересны посты об опыте применения AI - ставьте ❤️.
#нетехзаметки
NgStream
Вышедший недавно State of AI 2026, говорит, что 56% кода, в среднем, генерируется AI. Год назад было 28%. А доля тех, кто генерирует 75%+ кода, выросла сильнее всего. Ресурс говорит, что поучаствовало 7 258 разработчиков. Выборка смещена в сторону тех, кто уже использует AI, но тренды внутри неё показательные. Еще один показатель - частота использования. Доля разработчиков, использующих AI "постоянно", удвоилась за год.
Помните мой прошлый пост? Я писал, что AI - усилитель, а не замена. Эти цифры это подтверждают, но с тревожным нюансом.
Когда AI генерирует больше половины кода, проверять его становится отдельной профессией. И это проверка требует больше опыта, чем написание с нуля. При этом, старшие разработчики нужны ещё больше - именно они могут заметить галлюцинацию или архитектурную ошибку, которую сгенерировала модель. Кода генерируется больше и быстрее, но появляется дополнительная нагрузка на проверку и синхронизацию внутри команды. И еще немаловажно, что ты быстрее устаешь, потому что больше времени тратишь на проверки.
Этот "налог на ревью", в первую очередь, бьет по Senior инженерам. На них обрушивается лавина посредственного кода. Да, можно сказать, прикрутите ИИ ревьюера и дело в шляпе. Это означает, упростить проверку, но не решить проблему, на мой взгляд. Все-таки ответственность за баги по-прежнему несет человек, а не модель! Кстати, кто прикрутил ревьюера, пишите в комментариях, интересен ваш опыт:)
ИИ действительно ускоряет написание кода, но не так, как любят показывать в маркетинге. Более реальные цифры - в исследовании. Это, примерно, 7-8% прироста производительности, но часть этого потом идет на ревью и дополнительные затраты на координацию. Команды постепенно уходят от общих метрик и начинают смотреть на cycle time, cognitive load. И больше кода уже не равно “быстрее delivery”.
Что делать?
Если в вашей команде AI уже генерирует 50%+ кода - спроси себя:
- Кто и как проверяет эти 50%?
- Сколько времени уходит на исправление AI-багов?
- Не растёт ли когнитивная нагрузка на сеньоров?
По моему мнению, генерация кода подорожала по деньгам, но не подешевела по времени на отладку. Просто время перетекло из "написать" в "проверить и переписать".
Если вам интересны посты об опыте применения AI - ставьте ❤️.
#нетехзаметки
NgStream
❤6💯3
Angular 22!
Что нового? Посмотрим вместе на основные фичи!
Команда позиционирует обновление, как
📌 Signal Forms - stable! Наконец-то!
Представили финальную версию со всеми улучшениями, включая
Добавлена поддержка Angular Material для бесшовного внедрения сигнальных форм. И поддержка Angular Aria, предоставляющая набор основных a11y паттернов.
📌 Resources (resource и httpResource) - stable!
Напомню, что базовый resource используется для общих асинхронных операций, httpResource предназначен для получения данных по HTTP. Он автоматически отслеживает сигналы и управляет состоянием запроса. Также обновили гайд.
📌 OnPush по умолчанию.
А Default переименован в Eager. Что же, теперь меньше "шума" в классах, можно убрать явное указание использования стратегии для каждого компонента. При переходе будет произведена автоматическая миграция.
📌 И, конечно же, улучшение опыта работы с AI. Ведь это "новая эра разработки":)
- Обновили MCP. Новый инструмент
- Более тесная интеграция с Antigravity. Учитывая, что недавно выпустили 2 версию, звучит заманчиво. Кто уже потрогал новую версию - напишите, пожалуйста, в комменты или личные сообщения, интересно ваше мнение.
📌 Декоратор
📌 Асинхронный DI
📌 Host Directives
Теперь автоматически обрабатываются случаи, когда одна и та же директива применяется к элементу несколько раз (через шаблон и как host directive), предотвращая конфликты.
📌 Обновления роутинга.
📌 Обновили шаблоны. Добавлена поддержка switch/case (подробнее), spread синтаксиса (например, для передачи данных в input компонента), стрелочных функций и комментариев внутри HTML. Теперь можно писать вот такое… Как вам данное решение?
📌 Недавно показанная фича
📌 Помечены deprecated
Поддержка Webpack, сборщики
Вот такое насыщенное обновление! Еще команда запланировала event с презентацией релиза на 9 июня 20:00 мск онлайн. Подробности релиза в блоге. Пишите, какую фичу ждали больше всего?
#angular
NgStream
Что нового? Посмотрим вместе на основные фичи!
Команда позиционирует обновление, как
…фундаментальный сдвиг в философии фреймворка. Мы переходим от концепции просто стабильной библиотеки к модели «стартовой площадки», созданной для развертывания сложнейших современных приложений.
📌 Signal Forms - stable! Наконец-то!
Представили финальную версию со всеми улучшениями, включая
debounce(), validateAsync/validateHttp() и тд. И обновили гайд. Добавлена поддержка Angular Material для бесшовного внедрения сигнальных форм. И поддержка Angular Aria, предоставляющая набор основных a11y паттернов.
📌 Resources (resource и httpResource) - stable!
Напомню, что базовый resource используется для общих асинхронных операций, httpResource предназначен для получения данных по HTTP. Он автоматически отслеживает сигналы и управляет состоянием запроса. Также обновили гайд.
export class WeatherComponent {
selectedCity = signal('RND');
weather = httpResource<Type>(() =>
api/v1/forecast/${this.selectedCity()};
);
protected changeCity(newCity: string) {
this.selectedCity.set(newCity);
}
}📌 OnPush по умолчанию.
А Default переименован в Eager. Что же, теперь меньше "шума" в классах, можно убрать явное указание использования стратегии для каждого компонента. При переходе будет произведена автоматическая миграция.
📌 И, конечно же, улучшение опыта работы с AI. Ведь это "новая эра разработки":)
- Обновили MCP. Новый инструмент
devserver.wait_for_build, позволяет агентам запускать сборку и анализировать логи, а ai_tutor или modernize автоматически исправляет ошибки компиляции.- Более тесная интеграция с Antigravity. Учитывая, что недавно выпустили 2 версию, звучит заманчиво. Кто уже потрогал новую версию - напишите, пожалуйста, в комменты или личные сообщения, интересно ваше мнение.
📌 Декоратор
@Service() приходит на замену @Injectable({ providedIn: 'root' }). Представляют, как более лаконичный способ определения глобального синглтона. При этом классический @Injectable остается доступным для случаев, требующих сложной конфигурации или внедрения через конструктор.📌 Асинхронный DI
injectAsync - инструмент для реализации ленивой загрузки сервисов. Теперь тяжелые зависимости можно загружать только в тот момент, когда они действительно нужны.export class ReportComponent {
// Сервис будет загружен только при вызове export()
private exporter = injectAsync(() => import('./report-exporter'), {
prefetch: 'onIdle' // Опциональная предварительная загрузка в фоне
});
async export() {
const exporter = await this.exporter();
exporter.run();
}
}📌 Host Directives
Теперь автоматически обрабатываются случаи, когда одна и та же директива применяется к элементу несколько раз (через шаблон и как host directive), предотвращая конфликты.
📌 Обновления роутинга.
withExperimentalAutoCleanupInjectors - механизм очистки ресурсов. Для этого используется алгоритм "mark and sweep", который выявляет неиспользуемые инжекторы и освобождает ресурсы. Рекомендуется использовать для автоматической очистки. Подробнее можно почитать здесь. 📌 Обновили шаблоны. Добавлена поддержка switch/case (подробнее), spread синтаксиса (например, для передачи данных в input компонента), стрелочных функций и комментариев внутри HTML. Теперь можно писать вот такое… Как вам данное решение?
<button
(click)="item.update(p => ({ ...p, stock: p.stock - 1 }))">
Decrease Stock
</button>
📌 Недавно показанная фича
@boundary станет доступна в developer preview в Q3 2026.📌 Помечены deprecated
Поддержка Webpack, сборщики
@angular-devkit/build-angular, @ngtools/webpack и тд в версии 22 отмечены deprecated. Команда сосредоточена на поддержке TSGo.Вот такое насыщенное обновление! Еще команда запланировала event с презентацией релиза на 9 июня 20:00 мск онлайн. Подробности релиза в блоге. Пишите, какую фичу ждали больше всего?
#angular
NgStream
1❤🔥9👍3
В субботу посетил Сезон кода.
Сам фестиваль проходил в офисе ТБанка - у ребят очень уютно! И солнечная Питерская погода добавила красок;)
В программе 3 секции докладов, всякие активности на стендах, зоны чилла, несколько кофеен. За счет геймификации нас ненавязчиво подталкивали к общению, чтобы сообщество тусовалось не только в своих компаниях, а знакомилось! Мне понравилось! Вообще было много классных ребят! Для себя отметил выступление с дашбордами для мониторинга и реагирования на инциденты, поскольку сам недавно с этим работал. Запомнилась активность, где нужно было разобраться с решениями, предложенными AI. Я кайфанул! Узнал кое-что новое в демозоне с графовой аналитикой, пообщался с командой на тему SDLC.
В общем, самые положительные впечатления и спасибо организаторам, ребятам на стендах! Вам удалось сделать это максимально круто💪🏻
NgStream
Сам фестиваль проходил в офисе ТБанка - у ребят очень уютно! И солнечная Питерская погода добавила красок;)
В программе 3 секции докладов, всякие активности на стендах, зоны чилла, несколько кофеен. За счет геймификации нас ненавязчиво подталкивали к общению, чтобы сообщество тусовалось не только в своих компаниях, а знакомилось! Мне понравилось! Вообще было много классных ребят! Для себя отметил выступление с дашбордами для мониторинга и реагирования на инциденты, поскольку сам недавно с этим работал. Запомнилась активность, где нужно было разобраться с решениями, предложенными AI. Я кайфанул! Узнал кое-что новое в демозоне с графовой аналитикой, пообщался с командой на тему SDLC.
В общем, самые положительные впечатления и спасибо организаторам, ребятам на стендах! Вам удалось сделать это максимально круто💪🏻
NgStream
🔥9👎1
В Angular 22 была улучшена обработка
Наверное, одно из самых мощных нововведений, с точки зрения DX, это полноценная поддержка сужения типов (Type Narrowing) в шаблонах. Раньше, даже если вы проверили свойство в
Angular продолжает движение в сторону более корректной типизации и прозрачности, полностью синхронизируя работу с типами в шаблонах со стандартами JavaScript и TypeScript.
#angular
NgStream
null и undefined, которую многие не заметили. Поведение ?. в шаблонах теперь точно соответствует семантике JavaScript: если цепочка обрывается на позиции со значением null или undefined, результатом будет undefined. При этом сохранена обратная совместимость - если нужно старое поведение, специфичное для Angular, можно обернуть выражение в $null(…).Наверное, одно из самых мощных нововведений, с точки зрения DX, это полноценная поддержка сужения типов (Type Narrowing) в шаблонах. Раньше, даже если вы проверили свойство в
@if, компилятор часто требовал повторного использования ?. при обращении к вложенным полям, что сильно раздражало. Теперь после проверки на истинность (truthiness check) тип сужается, как в обычном коде TypeScript, так что последующий доступ без ?. является типобезопасным.@if (user?.isMember) {
{{ user.isMember }}
}Angular продолжает движение в сторону более корректной типизации и прозрачности, полностью синхронизируя работу с типами в шаблонах со стандартами JavaScript и TypeScript.
#angular
NgStream
🔥14❤2
Будущее JS инструментов
На прошлой неделе Vite+ перешел в статус Beta. Это не просто очередная библиотека, а попытка создать единую, монолитную и невероятно быструю платформу (набор инструментов), которая возьмет на себя управление всем циклом разработки. Что важно, проект полностью открыт и распространяется под лицензией MIT. В состав входят следующие инструменты:
Vite 8 - ядро для разработки и сборки;
Vitest - для тестирования (теперь с поддержкой ARIA-снапшотов);
Rolldown - новый "blazing fast" сборщик на Rust;
Oxlint и Oxfmt - линтер и форматировщик из семейства Oxc;
tsdown - bundler с нативной поддержкой CSS-модулей.
В Vite 8 важным изменением является переход на Rolldown по умолчанию. Раньше использование разных сборщиков в dev и prod режимах приводило к трудноуловимым багам. В этом же решении предлагается использовать Rolldown, чем обеспечить консистентность на всех этапах. Технически это стало возможным, благодаря глубокой интеграции с экосистемой Oxc. Использование Rust это не только про скорость, а про общее AST. Команда работает над тем, чтобы парсер, линтер и сборщик работали с одним деревом в памяти, минимизируя дорогостоящую сериализацию данных.
Забавно, что при генерации нового проекта через vp create, автоматически добавляются файл agent.md и инструкции для агентов Cursor, Copilot, Claude. Теперь AI сразу понимает контекст проекта, знает о правилах линтинга и специфике архитектуры.
Одной из самых обсуждаемых функций Vite 8.1 стал Experimental Bundled Dev Mode. Это переименованный Full Bundle Mode. Изначально Vite отдавал файлы по одному, но на больших проектах это стало бутылочным горлышком. Когда браузер пытается одновременно загрузить 10K модулей, его сетевой стек и DevTools просто вешаются. И сейчас опять возвращается к идее бандлинга в dev-режиме, объединяя модули в крупные chunks. Это позволяет сохранить мгновенный старт, не перегружая браузер бесконечными HTTP-запросами.
Еще для Enterprise добавили поддержку прокси, custom CA-сертификатов, а также organization templates для стандартизации сетапа во всех отделах компании.
В заметке в блоге отмечают, что релиз почти полностью стабилен и будет продолжена работа над улучшением.
#js
NgStream
На прошлой неделе Vite+ перешел в статус Beta. Это не просто очередная библиотека, а попытка создать единую, монолитную и невероятно быструю платформу (набор инструментов), которая возьмет на себя управление всем циклом разработки. Что важно, проект полностью открыт и распространяется под лицензией MIT. В состав входят следующие инструменты:
Vite 8 - ядро для разработки и сборки;
Vitest - для тестирования (теперь с поддержкой ARIA-снапшотов);
Rolldown - новый "blazing fast" сборщик на Rust;
Oxlint и Oxfmt - линтер и форматировщик из семейства Oxc;
tsdown - bundler с нативной поддержкой CSS-модулей.
В Vite 8 важным изменением является переход на Rolldown по умолчанию. Раньше использование разных сборщиков в dev и prod режимах приводило к трудноуловимым багам. В этом же решении предлагается использовать Rolldown, чем обеспечить консистентность на всех этапах. Технически это стало возможным, благодаря глубокой интеграции с экосистемой Oxc. Использование Rust это не только про скорость, а про общее AST. Команда работает над тем, чтобы парсер, линтер и сборщик работали с одним деревом в памяти, минимизируя дорогостоящую сериализацию данных.
Забавно, что при генерации нового проекта через vp create, автоматически добавляются файл agent.md и инструкции для агентов Cursor, Copilot, Claude. Теперь AI сразу понимает контекст проекта, знает о правилах линтинга и специфике архитектуры.
Одной из самых обсуждаемых функций Vite 8.1 стал Experimental Bundled Dev Mode. Это переименованный Full Bundle Mode. Изначально Vite отдавал файлы по одному, но на больших проектах это стало бутылочным горлышком. Когда браузер пытается одновременно загрузить 10K модулей, его сетевой стек и DevTools просто вешаются. И сейчас опять возвращается к идее бандлинга в dev-режиме, объединяя модули в крупные chunks. Это позволяет сохранить мгновенный старт, не перегружая браузер бесконечными HTTP-запросами.
Еще для Enterprise добавили поддержку прокси, custom CA-сертификатов, а также organization templates для стандартизации сетапа во всех отделах компании.
В заметке в блоге отмечают, что релиз почти полностью стабилен и будет продолжена работа над улучшением.
#js
NgStream
vitejs
Vite 8.1 is out!
Vite 8.1 Release Announcement
🔥5👍3
Пару недель назад в репозитории Angular появился любопытный MR, направленный на улучшение работы Router и его более глубокую интеграцию с resource.
Основная цель - предотвратить мерцание интерфейса путем замораживания состояния данных во время навигации. И обеспечить согласованность отображения, удерживая старое значение до тех пор, пока новый маршрут не будет полностью загружен или успешно восстановлен после отмены.
При отмене навигации, например, когда,
Для обеспечения транзакционности Angular накладывает жесткие ограничения на API обертки - скрыты методы для прямой записи состояния ( set/ update), его невозможно случайно перевести в невалидное состояние.
Уверен, работать с ресурсами будет еще удобнее. И отдельно заметно, что фреймворк в очередной раз берет на себя сложнейшую задачу синхронизации асинхронных потоков данных с состоянием роутинга, избавляя нас от написания десятков проверок в компонентах.
#angular
NgStream
Основная цель - предотвратить мерцание интерфейса путем замораживания состояния данных во время навигации. И обеспечить согласованность отображения, удерживая старое значение до тех пор, пока новый маршрут не будет полностью загружен или успешно восстановлен после отмены.
During navigation, the state of the resource (value, status, error, and loading signals) is frozen so the application state and UI do not eagerly change/flash during an in-progress navigation.
При отмене навигации, например, когда,
canActivate вернул false, предполагается откат. Ресурс удерживает замороженный snapshot состояния и будет показывать старые данные, пока не закончится фоновая перезагрузка текущего состояния. Если замороженное состояние не было валидным (например, ресурс находился в состоянии ошибки), фаза восстановления пропускается. Ресурс размораживается, что позволяет ему сразу перейти в новое состояние. Кроме того, работает логика New Navigation Preemption: если в процессе отката пользователь инициирует новую навигацию, система мгновенно отменяет восстановление и переключается на новую цель. Это и делает механизм по-настоящему транзакционным.Для обеспечения транзакционности Angular накладывает жесткие ограничения на API обертки - скрыты методы для прямой записи состояния ( set/ update), его невозможно случайно перевести в невалидное состояние.
Уверен, работать с ресурсами будет еще удобнее. И отдельно заметно, что фреймворк в очередной раз берет на себя сложнейшую задачу синхронизации асинхронных потоков данных с состоянием роутинга, избавляя нас от написания десятков проверок в компонентах.
#angular
NgStream
👍8🔥2
История с исчезновением ngneat пакетов получила продолжение!
Если вы пропустили эту новость, то все репозитории ngneat в прошлом месяце были удалены/скрыты. Это стало неожиданностью для команд разработчиков, использующих привычные инструменты. На reddit есть обсуждение на эту тему, можно почитать. Конечно сами npm пакеты никто не удалил, но вопрос дальнейшей поддержки оставался открытым.
И вот, пару дней назад, я увидел новость о том, что была создана организация OpenNG, которая будет координировать работу над форками проектов, включая elf, query и spectator! И уже вышел первый релиз.
Один из организаторов сообщества - Gerome Grignon, довольно известный Angular Certified Expert, open source contributor, создатель Angular CanIUse. Команда планирует поддерживать работу проектов и, в первую очередь, сделать ревью МР от сообщества. Как пишут у себя на странице, организация OpenNG планирует поддерживать и совместно разрабатывать и другие open-source проекты на Angular, помогать подбирать для проектов мэйнтейнеров, готовых развивать их дальше.
Ссылки на страницу проекта и страницу организации на GitHub.
#angular
NgStream
Если вы пропустили эту новость, то все репозитории ngneat в прошлом месяце были удалены/скрыты. Это стало неожиданностью для команд разработчиков, использующих привычные инструменты. На reddit есть обсуждение на эту тему, можно почитать. Конечно сами npm пакеты никто не удалил, но вопрос дальнейшей поддержки оставался открытым.
И вот, пару дней назад, я увидел новость о том, что была создана организация OpenNG, которая будет координировать работу над форками проектов, включая elf, query и spectator! И уже вышел первый релиз.
Один из организаторов сообщества - Gerome Grignon, довольно известный Angular Certified Expert, open source contributor, создатель Angular CanIUse. Команда планирует поддерживать работу проектов и, в первую очередь, сделать ревью МР от сообщества. Как пишут у себя на странице, организация OpenNG планирует поддерживать и совместно разрабатывать и другие open-source проекты на Angular, помогать подбирать для проектов мэйнтейнеров, готовых развивать их дальше.
Ссылки на страницу проекта и страницу организации на GitHub.
#angular
NgStream
🔥12👍2
На прошлой неделе вышел TypeScript 7
И у меня только сейчас дошли руки написать об этом.
Это релиз нативной версии TypeScript, которая работает в 10 раз быстрее текущей, о чем было заявлено в прошлом году. Цель была в том, чтобы максимально эффективно использовать современное железо и сделать перенос близко к оригиналу с сохранением структуры и логики исходной кодовой базы, обеспечивая совместимость между двумя компиляторами. В результате мы получили скорость нативного кода, многопоточность с общей памятью и ряд новых оптимизаций, которые обычно дают ускорение от 8 до 12 раз при полной сборке.
⚡️ На практике обещают прирост скорости на каждом этапе - загрузка проекта, поиск всех ссылок, автодополнение и более короткий цикл обратной связи при запуске в режиме
👀 Режим
🧵Новый компилятор теперь выполняет многие шаги параллельно: парсинг, type checking и генерацию кода. Некоторые из них, например парсинг и генерация, выполняются практически независимо для каждого файла - параллелизация автоматически хорошо масштабируется на больших кодовых базах с минимальными накладными расходами.
Были введены экспериментальные флаги
⚠️ Важное замечание для Angular разработчиков! Angular не перейдёт на TypeScript 7 сразу, поскольку новый API компилятора ещё не готов. Команда планирует выпустить стабильную версию API в следующем релизе - 7.1, после чего Angular и другие фреймворки и инструменты, такие как Vue, MDX, Astro, Svelte начнут интеграцию.
Звучит масштабно, ожидаем примерно такой же график релизов, как и до TypeScript 7.0: новые версии с полноценными возможностями будут выходить каждые 3–4 месяца.
Оригинал в блоге.
#typescript
NgStream
И у меня только сейчас дошли руки написать об этом.
Это релиз нативной версии TypeScript, которая работает в 10 раз быстрее текущей, о чем было заявлено в прошлом году. Цель была в том, чтобы максимально эффективно использовать современное железо и сделать перенос близко к оригиналу с сохранением структуры и логики исходной кодовой базы, обеспечивая совместимость между двумя компиляторами. В результате мы получили скорость нативного кода, многопоточность с общей памятью и ряд новых оптимизаций, которые обычно дают ускорение от 8 до 12 раз при полной сборке.
⚡️ На практике обещают прирост скорости на каждом этапе - загрузка проекта, поиск всех ссылок, автодополнение и более короткий цикл обратной связи при запуске в режиме
--watch.👀 Режим
--watch полностью переработан и работает на базе file-watcher из бандлера Parcel, обеспечивает эффективное и стабильное отслеживание изменений файлов на разных платформах.🧵Новый компилятор теперь выполняет многие шаги параллельно: парсинг, type checking и генерацию кода. Некоторые из них, например парсинг и генерация, выполняются практически независимо для каждого файла - параллелизация автоматически хорошо масштабируется на больших кодовых базах с минимальными накладными расходами.
Были введены экспериментальные флаги
--checkers и --builders для настройки параллелизации таких шагов, как проверка типов и сборка ссылок на проекты. И добавлен флаг --singleThreaded для полного отключения параллелизации, который полезен при отладке или в средах с ограниченными ресурсами.⚠️ Важное замечание для Angular разработчиков! Angular не перейдёт на TypeScript 7 сразу, поскольку новый API компилятора ещё не готов. Команда планирует выпустить стабильную версию API в следующем релизе - 7.1, после чего Angular и другие фреймворки и инструменты, такие как Vue, MDX, Astro, Svelte начнут интеграцию.
Звучит масштабно, ожидаем примерно такой же график релизов, как и до TypeScript 7.0: новые версии с полноценными возможностями будут выходить каждые 3–4 месяца.
Оригинал в блоге.
#typescript
NgStream
👍7🔥3
This media is not supported in your browser
VIEW IN TELEGRAM
Selectel Day Off возвращается 💚
ИТ-фестиваль пройдет 25 июля в музее Эрарта! Если разбираться с будущим, то там, где его уже нарисовали😉
По опыту прошлого года могу сказать, что день запомнился крутой атмосферой! Живые дискуссии, возможность и пообщаться, и узнать что-то новое, и просто выдохнуть)
⭐️ 8 докладов про ИИ в найме, профессии и искусстве;
⭐️ 8 воркшопов, чтобы развиваться в эпоху ИИ;
⭐️ перфомансы, активности и другие развлечения, чтобы выдохнуть — все же выходной.
Присоединяйся - вживую или онлайн. Места есть, но лучше не тянуть: прошлый раз показал, что они тают быстрее, чем аргументы противников нейросетей.
ИТ-фестиваль пройдет 25 июля в музее Эрарта! Если разбираться с будущим, то там, где его уже нарисовали😉
По опыту прошлого года могу сказать, что день запомнился крутой атмосферой! Живые дискуссии, возможность и пообщаться, и узнать что-то новое, и просто выдохнуть)
⭐️ 8 докладов про ИИ в найме, профессии и искусстве;
⭐️ 8 воркшопов, чтобы развиваться в эпоху ИИ;
⭐️ перфомансы, активности и другие развлечения, чтобы выдохнуть — все же выходной.
Присоединяйся - вживую или онлайн. Места есть, но лучше не тянуть: прошлый раз показал, что они тают быстрее, чем аргументы противников нейросетей.
🔥6👎3
В пятницу вышла новость об изменении релизного цикла Angular. Теперь major release планируется выпускать каждые 12 месяцев и 4-6 minor releases между ними. Изменение продиктовано просьбами сообщества из-за влияния критических изменений и обновлений на их проекты, а также на корпоративных клиентов.
Примерный план релизов ниже и ссылка на МР.
v22.2 | ~ September 2026
v22.3 | ~ November 2026
v22.4 | ~ January 2027
v22.5 | ~ March 2027
v23.0 | ~ June 2027
#angular
NgStream
Примерный план релизов ниже и ссылка на МР.
v22.2 | ~ September 2026
v22.3 | ~ November 2026
v22.4 | ~ January 2027
v22.5 | ~ March 2027
v23.0 | ~ June 2027
#angular
NgStream
🔥10👍2
Для крупных enterprise проектов время сборки - не просто техническая метрика, а вопрос эффективности бизнеса. При каждом ожидании разработчиком завершения CI/CD или локального билда, происходит разрушение когнитивного потока и падение "developer velocity". На масштабе нескольких команд это замедляет вывод фич на рынок.
Долгое время Angular CLI, несмотря на переход на esbuild и Vite, сохранял зависимость от Babel. Сейчас, как видим, решено отказаться от legacy в пользу сверхбыстрых инструментов нового поколения Oxc и Magic String. Ранее каждый плагин требовал повторной сериализации и десериализации AST, что создавало огромные накладные расходы. Теперь будет использоваться
📌 Oxc (Rust-based parser) берет на себя часть с построением структуры и понимания семантики.
📌 MagicString вносит корректировки в исходный код без дорогостоящей регенерации всего AST на каждом этапе.
Новое решение на базе Oxc выполняет ряд низкоуровневых преобразований
- Оптимизация TypeScript. Стандартный вывод Enums часто генерирует IIFE, которые инструменты вроде Terser или esbuild не всегда могут эффективно подвергнуть tree-shaking. А новый трансформер оборачивает их, чтобы гарантировать чистоту кода для минимизатора.
- Оптимизация статических членов классов.
- Удаление
- Аннотирование для Tree Shaking. Автоматическое добавление комментариев
Наибольший выигрыш от перехода получат проекты с огромной кодовой базой. В монорепах, содержащих сотни библиотек, даже 10% экономии времени на трансформации каждого файла суммируются в минуты сэкономленного времени на критическом пути CI/CD.
Переход на Oxc - логическое продолжение стратегии по улучшению инфраструктуры, перехода от неповоротливости к тому, чтобы задавать стандарты производительных инструментов для сборки. А для нас улучшение DX и повышение скорости доставки кода.
#angular
NgStream
Долгое время Angular CLI, несмотря на переход на esbuild и Vite, сохранял зависимость от Babel. Сейчас, как видим, решено отказаться от legacy в пользу сверхбыстрых инструментов нового поколения Oxc и Magic String. Ранее каждый плагин требовал повторной сериализации и десериализации AST, что создавало огромные накладные расходы. Теперь будет использоваться
oxc-parser для более быстрого анализа кода и magic-string для его модификации.📌 Oxc (Rust-based parser) берет на себя часть с построением структуры и понимания семантики.
📌 MagicString вносит корректировки в исходный код без дорогостоящей регенерации всего AST на каждом этапе.
Новое решение на базе Oxc выполняет ряд низкоуровневых преобразований
- Оптимизация TypeScript. Стандартный вывод Enums часто генерирует IIFE, которые инструменты вроде Terser или esbuild не всегда могут эффективно подвергнуть tree-shaking. А новый трансформер оборачивает их, чтобы гарантировать чистоту кода для минимизатора.
- Оптимизация статических членов классов.
- Удаление
setClassMetadata и других отладочных данных. Это не только уменьшает размер файла, но и снижает вычислительную нагрузку при обработке.- Аннотирование для Tree Shaking. Автоматическое добавление комментариев
/* @__PURE__ */ к вызовам функций и конструкторов. Это явное указание сборщику, что данный код можно безопасно удалить, если он не используется.Наибольший выигрыш от перехода получат проекты с огромной кодовой базой. В монорепах, содержащих сотни библиотек, даже 10% экономии времени на трансформации каждого файла суммируются в минуты сэкономленного времени на критическом пути CI/CD.
Переход на Oxc - логическое продолжение стратегии по улучшению инфраструктуры, перехода от неповоротливости к тому, чтобы задавать стандарты производительных инструментов для сборки. А для нас улучшение DX и повышение скорости доставки кода.
#angular
NgStream
👍3🔥2🤔2
Знаменательный день
Сегодня оказывается уже 5 лет как существует этот канал! Уже 5 лет каждую неделю (за исключением, например, отпусков) здесь выходят новости, мысли и просто важные заметки!
Спасибо тебе, что подписан, читаешь и остаешься здесь! За эти годы я понял, что канал живёт не новостями, а разговором. Поэтому не стесняйся заходить в комментарии и оставайся с нами дальше!
NgStream
Сегодня оказывается уже 5 лет как существует этот канал! Уже 5 лет каждую неделю (за исключением, например, отпусков) здесь выходят новости, мысли и просто важные заметки!
Спасибо тебе, что подписан, читаешь и остаешься здесь! За эти годы я понял, что канал живёт не новостями, а разговором. Поэтому не стесняйся заходить в комментарии и оставайся с нами дальше!
NgStream
🎉20🔥10❤3
В индустрии от многих звучит фраза: "Нам запрещено использовать ИИ". Объяснимо - страх перед утечкой интеллектуальной собственности и конфиденциальных данных заставляет компании возводить цифровые стены. Разберем, что на самом деле происходит с кодом при использовании ИИ-инструментов.
Первое, что важно отметить - не используется для обучения ≠ не сохраняется. Многие разработчики успокаивают себя настройкой "не использовать мои данные для обучения". Однако, важно понимать фундаментальную разницу между обучением (Training) и хранением (Retention). Даже если провайдер гарантирует, что код не станет частью следующей версии нейросети, данные всё равно могут сохраняться. Провайдеры удерживают информацию для мониторинга нарушений, отладки систем и выполнения юридических обязательств.
Следующий важный пункт - риски, связанные с агентами, т.к. они, в отличие от чат-ботов, обладают полномочиями.
- чтение файлов репозитория. Исследования показывают, что Codex или Cursor, способны обходить
- контакт с недоверенным контентом. Агент может анализировать сторонние зависимости или вредоносные issue в репозитории.
- Возможность отправки данных. Агент может быть "обманут" (через инъекцию промпта) и принужден к отправке кода. Причем, "Песочница - это забор, а не закон физики" и может быть преодолен при определенных условиях.
И еще один немаловажный пункт - защита и правила обработки данных, которые кардинально меняются в зависимости от подписки. Разрыв между персональными и бизнес-аккаунтами в 2026 году стал критическим.
- Личные подписки: В марте 2026 года GitHub Copilot обновил правила, согласно которым данные пользователей индивидуальных планов по умолчанию могут использоваться для обучения (opt-out модель). Аналогичный подход у OpenAI и Anthropic для персональных аккаунтов.
- Корпоративные планы: Здесь стандарты выше. По умолчанию данные не используются для обучения моделей, а условия хранения (retention) более жесткие и регулируемые.
В итоге можно сделать вывод, что для работы с коммерческим кодом обязательна корпоративная учетная запись с Enterprise-уровнем защиты.
Некоторые компании используют модель светофора для принятия решения об использовании ИИ.
- Зеленая зона: Публичные проекты, документация, Open Source. Использование любых ИИ-инструментов разрешено и поощряется.
- Желтая зона: Внутренний проприетарный код. Допускается работа только через одобренные Enterprise-версии инструментов с отключенным обучением. Обязательное условие: каждый сгенерированный diff должен проходить ревью человеком.
- Красная зона: Секреты (API-ключи, пароли), персональные данные клиентов, критическая инфраструктура. Использование облачных ИИ категорически запрещено.
Безопасность в эпоху ИИ - это не вопрос "использовать или нет". Это вопрос управления рисками. На мой взгляд, не стоит запрещать ИИ, а по возможности создавать безопасные коридоры для его использования.
#нетехзаметки
NgStream
Первое, что важно отметить - не используется для обучения ≠ не сохраняется. Многие разработчики успокаивают себя настройкой "не использовать мои данные для обучения". Однако, важно понимать фундаментальную разницу между обучением (Training) и хранением (Retention). Даже если провайдер гарантирует, что код не станет частью следующей версии нейросети, данные всё равно могут сохраняться. Провайдеры удерживают информацию для мониторинга нарушений, отладки систем и выполнения юридических обязательств.
Следующий важный пункт - риски, связанные с агентами, т.к. они, в отличие от чат-ботов, обладают полномочиями.
- чтение файлов репозитория. Исследования показывают, что Codex или Cursor, способны обходить
.gitignore и считывать файлы .env, содержащие секреты.- контакт с недоверенным контентом. Агент может анализировать сторонние зависимости или вредоносные issue в репозитории.
- Возможность отправки данных. Агент может быть "обманут" (через инъекцию промпта) и принужден к отправке кода. Причем, "Песочница - это забор, а не закон физики" и может быть преодолен при определенных условиях.
И еще один немаловажный пункт - защита и правила обработки данных, которые кардинально меняются в зависимости от подписки. Разрыв между персональными и бизнес-аккаунтами в 2026 году стал критическим.
- Личные подписки: В марте 2026 года GitHub Copilot обновил правила, согласно которым данные пользователей индивидуальных планов по умолчанию могут использоваться для обучения (opt-out модель). Аналогичный подход у OpenAI и Anthropic для персональных аккаунтов.
- Корпоративные планы: Здесь стандарты выше. По умолчанию данные не используются для обучения моделей, а условия хранения (retention) более жесткие и регулируемые.
В итоге можно сделать вывод, что для работы с коммерческим кодом обязательна корпоративная учетная запись с Enterprise-уровнем защиты.
Некоторые компании используют модель светофора для принятия решения об использовании ИИ.
- Зеленая зона: Публичные проекты, документация, Open Source. Использование любых ИИ-инструментов разрешено и поощряется.
- Желтая зона: Внутренний проприетарный код. Допускается работа только через одобренные Enterprise-версии инструментов с отключенным обучением. Обязательное условие: каждый сгенерированный diff должен проходить ревью человеком.
- Красная зона: Секреты (API-ключи, пароли), персональные данные клиентов, критическая инфраструктура. Использование облачных ИИ категорически запрещено.
Безопасность в эпоху ИИ - это не вопрос "использовать или нет". Это вопрос управления рисками. На мой взгляд, не стоит запрещать ИИ, а по возможности создавать безопасные коридоры для его использования.
#нетехзаметки
NgStream
👍4❤1🔥1
Вчера релизнули Angular22.1.
Обновили возможности управления кэшированием при использовании SSR. Стали доступны две настройки для
-
-
По умолчанию оба параметра
В общем, предоставили более гранулярный контроль над механизмом Transfer Cache в SSR.
#angular
NgStream
Обновили возможности управления кэшированием при использовании SSR. Стали доступны две настройки для
withHttpTransferCacheOptions.-
includeRequestsWithCredentials. Позволяет явно разрешить или запретить кеширование запросов с учетными данными.-
includeNonCacheableRequests - инструмент, когда нужно принудительно передать данные от сервера к клиенту, даже если API возвращает Cache-Control: no-store или no-cache. Это позволяет избежать повторного запроса в браузере сразу после загрузки страницы.По умолчанию оба параметра
false, однозначно дают понять, что стандартные механизмы кеширования останутся нетронутыми, пока вы сами сознательно не разрешите их обойти.В общем, предоставили более гранулярный контроль над механизмом Transfer Cache в SSR.
#angular
NgStream
👍4
На неделе смотрел, что нового было добавлено в предыдущих версиях Angular и кое-какое изменение прошло незамеченным.
В 21.1 представили более чистый способ управления программной фокусировкой в формах с помощью Signal Forms и нового API focusBoundControl(). Этот метод доступен на уровне
При работе с формами особенно важен позитивный user experience, а данный метод существенно упрощает жизнь. Вместо навешивания
Благодаря новой структуре
1. Сбор ошибок. Мы получаем массив всех текущих ошибок из состояния формы через сигнал
2. Извлечение ссылки. Каждый объект в этом массиве содержит свойство field - это сигнал, который возвращает прямую ссылку на состояние поля формы.
3. Точечный фокус. Берем первую ошибку из списка и вызываем
Angular Signal Forms продолжают обрастать инструментами, которые делают разработку сложных интерфейсов проще. Я нашел репозиторий, где наглядно показан пример работы, можно ознакомиться.
#angular
NgStream
В 21.1 представили более чистый способ управления программной фокусировкой в формах с помощью Signal Forms и нового API focusBoundControl(). Этот метод доступен на уровне
fieldState и избавляет нас от необходимости вручную манипулировать DOM-деревом и использовать прямые ссылки на элементы через @ViewChild только для того, чтобы поставить курсор в поле. Если поле связано с нативным HTML-элементом (например, <input>), вызов focusBoundControl() автоматически передает ему фокус. Это база, которая радикально упрощает код: теперь состояние формы само знает, как "достучаться" до UI. Работает только в том случае, если FormControl уже отрисован в DOM.При работе с формами особенно важен позитивный user experience, а данный метод существенно упрощает жизнь. Вместо навешивания
disabled состояния кнопки submit, что является плохой практикой, мы оставляем кнопку активной и при возникновении ошибок мгновенно переносим фокус. Особенно важно для сложных/вложенных форм. Например, в DatePicker вы можете решить, что при ошибке фокус должен всегда падать на выпадающий список Месяц (select), а не на текстовое поле Год. Теперь это реализуется парой строк кода внутри компонента, не ломая абстракцию формы.Благодаря новой структуре
errorSummary, реализация выглядит максимально технично и в декларативном стиле:1. Сбор ошибок. Мы получаем массив всех текущих ошибок из состояния формы через сигнал
errorSummary.2. Извлечение ссылки. Каждый объект в этом массиве содержит свойство field - это сигнал, который возвращает прямую ссылку на состояние поля формы.
3. Точечный фокус. Берем первую ошибку из списка и вызываем
firstError.field().state.focusBoundControl(). Angular Signal Forms продолжают обрастать инструментами, которые делают разработку сложных интерфейсов проще. Я нашел репозиторий, где наглядно показан пример работы, можно ознакомиться.
#angular
NgStream
🔥6❤2👍1
Найм в эпоху AI
С перестроением рабочих процессов перестраиваются и механизмы найма. Компаниям приходится видоизменять процесс собеседований в сторону оценки реальных навыков работы с ИИ.
Я наткнулся на любопытную публикацию компании Coinbase (точнее, спасибо @Basters за рекомендацию), в которой они приходят к мысли, что написание кода с нуля больше не создает основной ценности. Когда ИИ генерирует реализацию за секунды, инженерный труд перемещается в область спецификаций, глубокого ревью и исправления "уверенных" архитектурных галлюцинаций моделей.
Действительно, в мире, где, код сам по себе, обесценивается, самым дорогим ресурсом становятся проверка, верификация и принятие решений в точках неопределенности. Инженер превращается из исполнителя в контролера качества и системного архитектора.
И в Coinbase теперь оценивают не объем знаний, а используют новый стандарт оценки, который стал обязательным для всех уровней - от джунов до топ-менеджмента. Они вывели три принципа «AI Fluency». Или грамотности, если угодно.
1. Usage. Насколько эффективно и ответственно кандидат применяет инструменты? Умеет ли он выбирать правильную модель для конкретной задачи и интегрировать её в свой рабочий процесс?
2. Application. Способен ли инженер проектировать процессы, где ИИ создает реальную бизнес-ценность, а не просто автоматизирует рутину?
3. Understanding Limits. Видит ли человек, где ИИ ошибается? Понимает ли он риски безопасности и приватности? Это о способности находить тонкие ошибки в работе моделей.
На мой взгляд, основная мысль статьи - оценка умения вовремя "нажать на тормоз" и оспорить решение модели теперь ценится выше, чем любая скорость написания функций вручную. И теперь нужно владеть не просто инженерным набором знаний и умений, а уметь ставить задачи и проверять результат, применяя данные навыки.
Поскольку нейросети умнеют ежемесячно, задача, которая была сложной в январе, может стать тривиальной для новой модели в марте. Поэтому процесс найма в Coinbase теперь пересматривается ежеквартально. Даже поведенческие интервью изменились: теперь кандидатам задают вопросы об использовании ИИ в своей повседневной работе.
Но вопросы у меня вопросы остались. И некоторые из них в области практического применения. Например:
- предполагается ли на собеседовании использование модели в контуре компании или кандидата
- насколько глубокой должна быть задача и какой уровень задач
- сколько времени на это мы можем позволить потратить.
Допустим, проверили уровень владения ИИ, но технику и базу разработки тоже мне хотелось бы проверить. Я бы рассмотрел как дополнительную проверку - ИИ хорошие подсказки дал на предыдущем этапе и по наитию кандидат ответил или перед нами действительно хороший специалист.
В общем, любопытно побеседовать на эту тему с коллегами. Поэтому, если имеете отношение к найму у себя в компании и есть желание, welcome в личные сообщения:)
#нетехзаметки
NgStream
С перестроением рабочих процессов перестраиваются и механизмы найма. Компаниям приходится видоизменять процесс собеседований в сторону оценки реальных навыков работы с ИИ.
Я наткнулся на любопытную публикацию компании Coinbase (точнее, спасибо @Basters за рекомендацию), в которой они приходят к мысли, что написание кода с нуля больше не создает основной ценности. Когда ИИ генерирует реализацию за секунды, инженерный труд перемещается в область спецификаций, глубокого ревью и исправления "уверенных" архитектурных галлюцинаций моделей.
Действительно, в мире, где, код сам по себе, обесценивается, самым дорогим ресурсом становятся проверка, верификация и принятие решений в точках неопределенности. Инженер превращается из исполнителя в контролера качества и системного архитектора.
И в Coinbase теперь оценивают не объем знаний, а используют новый стандарт оценки, который стал обязательным для всех уровней - от джунов до топ-менеджмента. Они вывели три принципа «AI Fluency». Или грамотности, если угодно.
1. Usage. Насколько эффективно и ответственно кандидат применяет инструменты? Умеет ли он выбирать правильную модель для конкретной задачи и интегрировать её в свой рабочий процесс?
2. Application. Способен ли инженер проектировать процессы, где ИИ создает реальную бизнес-ценность, а не просто автоматизирует рутину?
3. Understanding Limits. Видит ли человек, где ИИ ошибается? Понимает ли он риски безопасности и приватности? Это о способности находить тонкие ошибки в работе моделей.
На мой взгляд, основная мысль статьи - оценка умения вовремя "нажать на тормоз" и оспорить решение модели теперь ценится выше, чем любая скорость написания функций вручную. И теперь нужно владеть не просто инженерным набором знаний и умений, а уметь ставить задачи и проверять результат, применяя данные навыки.
Поскольку нейросети умнеют ежемесячно, задача, которая была сложной в январе, может стать тривиальной для новой модели в марте. Поэтому процесс найма в Coinbase теперь пересматривается ежеквартально. Даже поведенческие интервью изменились: теперь кандидатам задают вопросы об использовании ИИ в своей повседневной работе.
Но вопросы у меня вопросы остались. И некоторые из них в области практического применения. Например:
- предполагается ли на собеседовании использование модели в контуре компании или кандидата
- насколько глубокой должна быть задача и какой уровень задач
- сколько времени на это мы можем позволить потратить.
Допустим, проверили уровень владения ИИ, но технику и базу разработки тоже мне хотелось бы проверить. Я бы рассмотрел как дополнительную проверку - ИИ хорошие подсказки дал на предыдущем этапе и по наитию кандидат ответил или перед нами действительно хороший специалист.
В общем, любопытно побеседовать на эту тему с коллегами. Поэтому, если имеете отношение к найму у себя в компании и есть желание, welcome в личные сообщения:)
#нетехзаметки
NgStream
👍5
В Angular 22.1 добавили еще одну фичушку. Это CSS variable namespacing.
Суть заключается в физической невозможности конфликта имен между независимыми приложениями. Особенно важно для корпоративных систем, где разные команды интегрируют свои части интерфейса в общую оболочку. Для такой изоляции Angular внедрил элегантный двухэтапный механизм, который работает следующим образом:
Этап компиляции. Компилятор находит все CSS-переменные и заменяет их на внутреннее представление с заглушкой. Например,
Runtime. Здесь заменяется
DOM больше не является «источником истины» для имен переменных. Привычный вызов
Для решения этой проблемы представлен сервис
Поскольку процесс автоматизирован, разработчик продолжает писать чистый CSS, а Angular берет на себя всю рутину по обеспечению уникальности.
#angular
NgStream
Суть заключается в физической невозможности конфликта имен между независимыми приложениями. Особенно важно для корпоративных систем, где разные команды интегрируют свои части интерфейса в общую оболочку. Для такой изоляции Angular внедрил элегантный двухэтапный механизм, который работает следующим образом:
Этап компиляции. Компилятор находит все CSS-переменные и заменяет их на внутреннее представление с заглушкой. Например,
--foo превращается в --%NS%foo. Это касается как файлов стилей (styles, styleUrls), так и динамических привязок в шаблонах (например, [style.--foo]="val").Runtime. Здесь заменяется
%NS% на реальное имя пространства имен, заданное при конфигурации (например, --my-app_foo).DOM больше не является «источником истины» для имен переменных. Привычный вызов
getComputedStyle(el).getPropertyValue('--foo') теперь официально считается опасным паттерном, так как реальное имя переменной в runtime будет содержать префикс.Для решения этой проблемы представлен сервис
CssVarNamespacer. Его использование становится критически важным, особенно для авторов библиотек компонентов. Если ваша библиотека работает с CSS-переменными через JS и не поддерживает этот сервис, она фактически становится несовместимой с современными enterprise-стандартами Angular.export const appConfig: ApplicationConfig = {
providers: [
{ provide: APP_ID, useValue: 'crm-app' },
// Использование разделителя для чистоты имен
provideCssVarNamespacing('crm-app_'),
],
};Поскольку процесс автоматизирован, разработчик продолжает писать чистый CSS, а Angular берет на себя всю рутину по обеспечению уникальности.
#angular
NgStream
🔥5