Скажи, пожалуйста, для кого будет вставать на первое место? Для бизнеса? Для PO, для РП?
У бизнеса есть CTO, который выстраивает взаимодействие с разработкой. В крупных проектах всегда смотрят на метрики: количество/скорость прихода багов, метрики скорости сервисов, метрики скорости работы приложений и многие другие. При запуске новой фичи в АБ тесте аналитики могут принести самые неожиданные результаты, противоположные от тех, что ожидали PO/PM. И это может быть некачественный/медленный/багованный код. Тут и наступает отвественность разработчиков, которые в угоду скорости доверили написание всей фичи LLM. Всегда должен быть баланс между скоростью и качеством.
Для этого в бигтехе развивают свои LLM, чтобы снять риски утечки информации. Плюс дополнительно используют договоры с поставщиками услуг (Cursor и пр.), где есть пункты про конфиденциальность.
Нужно начинать контекст с нуля. Если LLM где-то исправил код так как вам не нужно, то он будет повторять эту ошибку снова и снова с текущим контекстом.
Это задача разработчика выстроить архитектуру приложения, а последние модели уже могут достаточно неплохо "по образу и подобию" реализовывать новые части.
Речь как раз про маленькие атомарные этапы решения какой-то большой задачи с помощью LLM. Каждый этап контролирует сам разработчик. Вайб-кодинг - конечно, игрушка и фантазии.
Есть ещё один вариант использования схемы rest<=>kafka.
Например, когда инстансы имеют некий высонагруженный и очень большой (сотни гигабайт) кеш, обновляемый, к примеру, через консюмер Кафки по ключу сообщения. В результате мы имеем этот большой кеш размазанный по всем инстансам.
Подход rest<=> kafka в данном случае позволит использовать тот же ключ в сообщении к Кафке, чтобы запрос был обработан именно тем инстансом, где этот кеш точно есть.
Такой подход позволит снизить до нуля обновление кеша из БД, к примеру. БД будет работать только при прогреве инстанса.
Это не глюк. Понятно, что вы тут пытались исправить: перенос div.helper на новую строку в случае длинного содержимого в контейнере child.
Решается проблема просто: Текст, который заключён во внутренний блок.
Как “нестандартное положение” отлично пошутило про позорный вылет французов с Кубка Мира: “все через жопу? – че, с годом России во Франции”, так щас можно смело говорить: «че, встечайте Сколково»
В тексте ровно про это же. Разве что не согласен, что ждуны совладают с ИИ, а работодатель поверит, что джун совладал
У бизнеса есть CTO, который выстраивает взаимодействие с разработкой. В крупных проектах всегда смотрят на метрики: количество/скорость прихода багов, метрики скорости сервисов, метрики скорости работы приложений и многие другие. При запуске новой фичи в АБ тесте аналитики могут принести самые неожиданные результаты, противоположные от тех, что ожидали PO/PM. И это может быть некачественный/медленный/багованный код. Тут и наступает отвественность разработчиков, которые в угоду скорости доверили написание всей фичи LLM. Всегда должен быть баланс между скоростью и качеством.
Для этого в бигтехе развивают свои LLM, чтобы снять риски утечки информации. Плюс дополнительно используют договоры с поставщиками услуг (Cursor и пр.), где есть пункты про конфиденциальность.
Нужно начинать контекст с нуля. Если LLM где-то исправил код так как вам не нужно, то он будет повторять эту ошибку снова и снова с текущим контекстом.
Это задача разработчика выстроить архитектуру приложения, а последние модели уже могут достаточно неплохо "по образу и подобию" реализовывать новые части.
Речь как раз про маленькие атомарные этапы решения какой-то большой задачи с помощью LLM. Каждый этап контролирует сам разработчик. Вайб-кодинг - конечно, игрушка и фантазии.
Есть ещё один вариант использования схемы rest<=>kafka.
Например, когда инстансы имеют некий высонагруженный и очень большой (сотни гигабайт) кеш, обновляемый, к примеру, через консюмер Кафки по ключу сообщения. В результате мы имеем этот большой кеш размазанный по всем инстансам.
Подход rest<=> kafka в данном случае позволит использовать тот же ключ в сообщении к Кафке, чтобы запрос был обработан именно тем инстансом, где этот кеш точно есть.
Такой подход позволит снизить до нуля обновление кеша из БД, к примеру. БД будет работать только при прогреве инстанса.
На дворе июль и уже RC 1.0.0 по Traces
Решается проблема просто:
Текст, который заключён во внутренний блок.