Forwarded from Сиолошная
Интересная новость из свежей рассылки The Pragmatic Engineer:
Про запуск 3-5 окон в параллель в разных папках слышал, но про такое — ни разу. Интересно. когда добавят такую фичу в сам Codex🤔
Вот вам и 20x инженеры, выступающие в роли операторов агентов, контролирующие их работу и задающие направление разработки.
===
И ещё оттуда же:
Во время моего визита я встретился с Sulman Choudhry, который руководит направлениями инженерии и прикладных исследований ChatGPT. Он поделился несколькими интересными моментами:
Теперь OpenAI нанимает не только сеньоров, но и джунов. Компания успешно использует подход «супер-сеньор + супер-джун». «Супер-джуны» — это молодые инженеры, выросшие в эпоху ИИ, с предпринимательским складом мышления, многие из которых прошли акселератор стартапов Y Combinator. По словам Сулмана, супер-джуны используют ИИ-инструменты такими способами, которые удивляют их более опытных коллег.
Например, один из таких инженеров выполнил впечатляющую работу, и Сулман спросил, использовал ли тот Codex для этого. Это вызвало оборонительную реакцию, и Сулман сначала подумал, что инженер обиделся, так как сделал большую часть работы вручную и ему не понравилось предположение о том, что задачу просто поручили ИИ. Вот как Сулман пересказал ответ инженера:
«Это немного обидно, что ты спрашиваешь, использовал ли я Codex. Конечно же, один Codex не смог бы построить софт такой сложности, и ты наверняка это тоже понимаешь.
Именно поэтому мне пришлось использовать сразу несколько экземпляров Codex, наладив между ними каналы связи, чтобы они совместно решали задачу: один проверял работу, а остальные реализовывали специализированные части».
Выяснилось, что инженера раздражало не предположение об использовании Codex, а предположение, что он использовал только один его экземпляр! В конце концов, кто же захочет так замедлять свою работу? Супер-джуны в OpenAI двигают границы возможностей ИИ-инструментов и вдохновляют более опытных инженеров применять их по-новому.
Про запуск 3-5 окон в параллель в разных папках слышал, но про такое — ни разу. Интересно. когда добавят такую фичу в сам Codex
Вот вам и 20x инженеры, выступающие в роли операторов агентов, контролирующие их работу и задающие направление разработки.
===
И ещё оттуда же:
Одна из последних интересных внутренних фичей — кнопка «починить это», интегрированная во внутреннюю версию мобильного приложения OpenAI. Все мы привыкли к кнопке «сообщить об ошибке» в мобильных приложениях: делается скриншот, вы описываете проблему и отправляете отчёт. Команда OpenAI пошла дальше: вы заполняете форму с описанием ошибки и нажимаете кнопку «починить». Отчёт отправляется в Codex, который автоматически предлагает исправление. Инженеру остаётся только утвердить предложенный вариант — и этот цикл обратной связи значительно ускоряется!
Please open Telegram to view this post
VIEW IN TELEGRAM
👏6
Сиолошная
Интересная новость из свежей рассылки The Pragmatic Engineer: Во время моего визита я встретился с Sulman Choudhry, который руководит направлениями инженерии и прикладных исследований ChatGPT. Он поделился несколькими интересными моментами: Теперь OpenAI…
Когда инженеры работают с несколькими экземплярами Codex, они фактически создают распределённую систему агентов. Это превращает одиночного разработчика в "оркестр" операторов ИИ.
Это даёт 10-20x ускорение в прототипировании и снижает когнитивную фрикцию.
"Супер-джуны" - это не просто младшие специалисты, а оркестраторы ИИ-процессов, выросшие в эпоху prompt- и agent-first мышления.
Они не боятся делегировать, экспериментируют, не застревают в перфекционизме. Это именно то, что нужно для R&D, где ценится скорость обучения, а не стабильность кода.
⚠️ Минусы: когнитивная эрозия и инженерная иллюзия
Если джуны постоянно делегируют сложные задачи агентам, то у них может не формироваться системное мышление: почему решение работает, почему архитектура такая.
Через год - сильный оператор, но слабый архитектор.
Быстрое исправление ≠ качественное исправление.
Когда цикл feedback'а автоматизирован, легко утратить осознанность: исправление принято, но регрессия осталась.
ИИ фиксит симптомы, не всегда понимая причины.
Если компания строит процессы вокруг Codex, она рискует потерять "engineering muscle memory".
Умение дебажить, проектировать, понимать trade-offs - это навыки, которые ИИ пока не воспроизводит в полной мере.
Идеальный вектор развития - смешанные команды операторов и менторов.
Супер-джуны должны быть "пилотами" ИИ, а сеньоры - архитекторами и навигаторами, которые обеспечивают глубину решений.
Иначе получится не "инженер + Codex", а "Codex без инженера".
Итог:
Этот подход - не просто найм джунов, а переход к новой модели разработки: "операторы агентов" (пастухи агентов) вместо классических кодеров.
Если компании смогут встроить в это инженерную культуру осознанности и архитектурного мышления, мы увидим не просто рост продуктивности, а появление нового инженерного вида - homo orchestrator.
#LLM #AI #agentic #HomoOrchestrator #ПастухАгентов
Please open Telegram to view this post
VIEW IN TELEGRAM
This media is not supported in your browser
VIEW IN TELEGRAM
В городе Södertälje, неподалёку от Стокгольма, дикая птица семейства врановых получает за каждую подобранную окурок награду - орешек. Воронка приносит окурок, помещает его в автомат-контейнер, и получает свой паёк.
Они входят в семейство корвидов (crow family) и признаны одними из самых интеллектуальных птиц: сравниваются с семилетними детьми по уровню решения задач.
Они живут в городских условиях, легко адаптируются, могут наблюдать друг за другом и быстро учиться.
Вместе с тем, автомат запрограммирован так, чтобы минимизировать риск того, что птица съест мусор или что-то неподходящее.
По данным Keep Sweden Tidy Foundation, окурки составляют примерно 62% от всего мусора на улицах Швеции.
В Сёдертелье только уборка улиц обходится городу около 20 миллионов шведских крон (~$2 млн) в год.
Стартап оценивает, что с помощью птиц можно сократить затраты на сбор окурков до ~20 ёре (~$0.02) за штуку при нынешних ~80 ёре и выше.
Оптимистичные оценки ожидают экономию до ~75% затрат на данный вид мусора.
⚠️ Что важно учитывать?
Пока проект находится в пилотной стадии - проводятся тесты на устойчивость, здоровье птиц и долгосрочную эффективность.
Возникают вопросы: не будет ли это эксплуатацией птиц? Как они отреагируют на постоянный сбор потенциально вредного мусора?
Хотя идея звучит оригинально, её масштаб и устойчивость ещё предстоит доказать.
Инновационная комбинация "умных птиц + автоматизированная поощрительная система" может стать ярким примером экологического предпринимательства. Если всё пойдёт как задумано - меньше мусора, меньше затрат, и интересный кейс устойчивой городской экосистемы. При этом очень важно контролировать этическую сторону и долгосрочное воздействие на животных.
#стартап #технологии #smartbird
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥6👏2
Forwarded from Архитектор Данных
Переезд с Docker[-Compose] на Kubernetes - мини-разбор инфраструктурного вебинара глазами архитектора данных.
Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.
Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.
В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Выписал себе пункты:
1️⃣ Докер - отличный старт, когда контейнеров мало и инфра небольшая.
2️⃣ Докер решает только задачу запуска контейнера. Не управления многими контейнерами, не интеграции с инструментами разработки.
3️⃣ В докере нет централизованного хранилища секретов, что приводит к хранению паролей и ключей в .env и прочих текстовых файлах, и в конце концов рано или поздно, к утечкам критических доступов.
4️⃣ То же - для сетевых практик, например разделения dev & prod
5️⃣ Docker Compose - хороший способ поддержать локальное окружение разработки.
6️⃣ Docker Compose - по дизайну односерверная инфраструктура. Он не подходит для создания хоть сколь-нибудь отказоустойчивой конфигурации, непрерывной выкатки, масштабирования.
7️⃣ На основе K8S намного легче добиться ситуации когда выкатка для разработчика - это просто коммит. То же с непрерывным обслуживанием конечных пользователей.
8️⃣ То же - для возможности быстрой откатки на предыдущее состояние, если что-то идет не так
💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾 💾
Мне было весьма полезно, хотя бы в том плане, что есть четкий набор аргументов, чего именно мы добиваемся при переходе на Кубер. Какие реально есть аргументы переноса, допустим, небольшой аналитической инфраструктуры на кубер. Тот случай, когда вроде не вчера знаком со всеми технологиями, но нужно послушать специалиста для того, чтобы в голове все улеглось в стройную картину.
Я не настоящий ДевОпс, и часто кручу что-то простое в докере и докер-компоузе. Нужен просто Аэрфлоу или Суперсет - нет ничего проще развернуть готовый компоуз с ГитХаба и (какое-то время) радоваться, что все работает. Но все мы понимаем, что это времянка и рано или поздно при выходе на продакшен с SLA-ями придется переинжинирить инсталляцию на что-то более устойчивое.
Чуть ранее я анонсировал вебинар про перенос инфрастурктуры с докера на кубер от коллег. Теперь у нас есть его запись.
В вебинаре все разложили по полочкам - почему умные делают так, какие именно недостатки в простом докере и чего именно мы добиваемся переходя на более взрослое решение на основе K8S.
Выписал себе пункты:
Мне было весьма полезно, хотя бы в том плане, что есть четкий набор аргументов, чего именно мы добиваемся при переходе на Кубер. Какие реально есть аргументы переноса, допустим, небольшой аналитической инфраструктуры на кубер. Тот случай, когда вроде не вчера знаком со всеми технологиями, но нужно послушать специалиста для того, чтобы в голове все улеглось в стройную картину.
Please open Telegram to view this post
VIEW IN TELEGRAM
Telegram
Архитектор Данных
На вот этот вебинар запишитесь!
https://cloud.vk.com/events/migraciya-prilozheniya-kak-perenesti-infrastrukturu-s-monolita-v-upravlyaemyj-kubernetes-v-oblake
Ведут два абсолютных "отца" кубера и облачных миграций.
В прямом эфире показываем на реальном…
https://cloud.vk.com/events/migraciya-prilozheniya-kak-perenesti-infrastrukturu-s-monolita-v-upravlyaemyj-kubernetes-v-oblake
Ведут два абсолютных "отца" кубера и облачных миграций.
В прямом эфире показываем на реальном…
👏5
JetBrains представила открытую платформу для бенчмаркинга AI-агентов, которые помогают писать код.
🧠 DPAI Arena оценивает, как ИИ-инструменты справляются с задачами вроде:
Платформа открытая и нейтральная - JetBrains планирует передать её под крыло Linux Foundation.
Первый бенчмарк - на Java/Spring, но архитектура поддерживает и Python, Go, JS и др.
#ai #agents #agentic #llm #dev #jetbrains
Please open Telegram to view this post
VIEW IN TELEGRAM
Релиз 🖼️
🔘 Apache Airflow 3.1.2
🔘 Task SDK 1.1.2
🤔 Что нового
⏩ Улучшена стабильность при работе с динамическими задачами и TaskFlow API
⏩ Оптимизированы механизмы импорта и загрузки плагинов
⏩ Повышена совместимость с Python 3.12
⏩ Улучшения в логировании, UI и Scheduler
😊 Ничего нового, баги фиксят
📦 Релизные ресы
▶️ Дока
▶️ Release Notes
▶️ Constraints
#airflow #release #de
#airflow #release #de
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from DataEng
Best_practices_for_ETL_and_ELT_pipelines_with_Apache_Airflow_3.pdf
3.6 MB
Очередной подгон от Astronomer про лучшие практики построения ETL/ELT пайплайнов на базе Apache Airflow 3 — Best practices for ETL and ELT pipelines with Apache Airflow 3
Небольшая электронная книга на 50 страниц, удобно использовать как справочник.
Небольшая электронная книга на 50 страниц, удобно использовать как справочник.
Forwarded from 5 minutes of data
Pipedash
Десктопное приложение для управления CI/CD-пайплайнами от нескольких провайдеров
Большинство команд разработчиков со временем используют несколько платформ CI/CD.
Open source-проекты часто полагаются на GitHub Actions, внутренние сервисы могут работать на GitLab CI или Buildkite, нативные для Kubernetes — на Tekton, а обычно есть ещё какой-нибудь экземпляр Jenkins, который обслуживает legacy-системы.
Чтобы всё проверить, приходится открывать кучу вкладок и вручную обновлять.
Pipedash — собирает данные о пайплайнах из разных провайдеров и отображает их в одном месте.
@five_minutes_of_data
Десктопное приложение для управления CI/CD-пайплайнами от нескольких провайдеров
Большинство команд разработчиков со временем используют несколько платформ CI/CD.
Open source-проекты часто полагаются на GitHub Actions, внутренние сервисы могут работать на GitLab CI или Buildkite, нативные для Kubernetes — на Tekton, а обычно есть ещё какой-нибудь экземпляр Jenkins, который обслуживает legacy-системы.
Чтобы всё проверить, приходится открывать кучу вкладок и вручную обновлять.
Pipedash — собирает данные о пайплайнах из разных провайдеров и отображает их в одном месте.
@five_minutes_of_data
GitHub
GitHub - hcavarsan/pipedash: A desktop app for managing CI/CD pipelines from multiple providers
A desktop app for managing CI/CD pipelines from multiple providers - hcavarsan/pipedash
#meme #thisisfine #coin #sber
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Media is too big
VIEW IN TELEGRAM
На AI Day в Гуанчжоу IRON вышел на сцену, прошёл "кошачьим шагом" и жестами как человек. Зрители решили, что это костюм - поэтому Хэ Сяопэн прямо на сцене "распаковал" робота, показав skелет и "мышцы".
Что интересно:
Применение: витрины/гиды в ритейле и промышленные инспекции (партнёрство с China Baowu уже в работе).
#XPeng #IRON #роботы #гуманоид #AI #humanoid #robotics
Please open Telegram to view this post
VIEW IN TELEGRAM
🍺
🔧 Написал скрипт, который берёт свежак из репозитория.
⬇️ Пользуйся:
brew не хочет обновлять codex?🔧 Написал скрипт, который берёт свежак из репозитория.
⬇️ Пользуйся:
#!/usr/bin/env bash
set -e
echo "🔍 Detecting system architecture..."
ARCH=$(uname -m)
OS=$(uname -s)
VERSION=$(curl -s https://api.github.com/repos/openai/codex/releases/latest | grep -o '"tag_name": *"[^"]*"' | cut -d'"' -f4)
BASE_URL="https://github.com/openai/codex/releases/download/${VERSION}"
EXT=".tar.gz"
# Определяем правильный бинарь
if [[ "$OS" == "Darwin" ]]; then
if [[ "$ARCH" == "arm64" ]]; then
FILE="codex-aarch64-apple-darwin"
else
FILE="codex-responses-api-proxy-x86_64-apple-darwin"
fi
elif [[ "$OS" == "Linux" ]]; then
if [[ "$ARCH" == "aarch64" ]]; then
FILE="codex-aarch64-unknown-linux-musl"
else
FILE="codex-x86_64-unknown-linux-musl"
fi
else
echo "❌ Unsupported OS: $OS"
exit 1
fi
DEST="/usr/local/bin/codex"
if [[ "$OS" == "Darwin" && -d "/opt/homebrew/bin" ]]; then
DEST="/opt/homebrew/bin/codex"
fi
echo "⬇️ Downloading ${FILE}${EXT} from Codex ${VERSION}..."
curl -fL -o codex.tmp "${BASE_URL}/${FILE}${EXT}" || {
echo "❌ Download failed — release or file not found at ${BASE_URL}/${FILE}${EXT}"
exit 1
}
mv codex.tmp codex.tar.gz
mkdir -p codex_unpack
tar -xzf codex.tar.gz -C codex_unpack || {
echo "⚠️ tar extraction failed, maybe it's pure gzip. Trying gunzip..."
gunzip -c codex.tar.gz > codex_unpack/codex
}
# Ищем бинарь "codex" или файл, начинающийся с codex-
BIN_PATH=$(find codex_unpack -type f \( -name "codex" -o -name "codex-*" \) | head -n 1)
if [[ -z "$BIN_PATH" ]]; then
echo "❌ Could not find extracted codex binary after unpacking."
echo " Contents of archive:"
ls -R codex_unpack
exit 1
fi
echo "⚙️ Installing to ${DEST}..."
sudo mv "$BIN_PATH" "$DEST"
sudo chmod +x "$DEST"
rm -rf codex_unpack codex.tar.gz
echo "✅ Codex updated successfully!"
"$DEST" --version
Forwarded from О разработке и не только
Я, конечно, не пробовал эту штуку, но почему-то кажется, что она работает. Возможно, потому что уже наловчились проходить собесы другими подобными инструментами. И вот как теперь быть нанимающей стороне?
Я вижу 3 варианта:
1. Нанимать на срочный договор на полгода и лишь затем брать в штат. Далеко не все кандидаты на такое пойдут, особенно высоких грейдов.
2. Организовать "чистые комнаты" (ловите идею для стартапа!) — на базе Почты России, СДЭКа и т.п. сделать отдельное помещение с компом. Т.к. эти организации есть примерно в каждом Мухосранске, можно не терять кандидатов.
3. Личное знакомство. Конференции, бары и прочий нетворкинг всё-таки победит. Онтико сможет поднять цены на билеты и организовать стенд "Ищу работу".
Честно говоря, ни один из них мне не нравится, но реагировать как-то надо 🤷♂️
А какой вариант вас бы устроил? 🤝 - №1, 🤔 - № 2, 👌 - № 3.
https://www.interviewcoder.co/ #dev
Я вижу 3 варианта:
1. Нанимать на срочный договор на полгода и лишь затем брать в штат. Далеко не все кандидаты на такое пойдут, особенно высоких грейдов.
2. Организовать "чистые комнаты" (ловите идею для стартапа!) — на базе Почты России, СДЭКа и т.п. сделать отдельное помещение с компом. Т.к. эти организации есть примерно в каждом Мухосранске, можно не терять кандидатов.
3. Личное знакомство. Конференции, бары и прочий нетворкинг всё-таки победит. Онтико сможет поднять цены на билеты и организовать стенд "Ищу работу".
Честно говоря, ни один из них мне не нравится, но реагировать как-то надо 🤷♂️
А какой вариант вас бы устроил? 🤝 - №1, 🤔 - № 2, 👌 - № 3.
https://www.interviewcoder.co/ #dev
Interview Coder
Interview Coder - AI Interview Assistant for Technical Interviews
AI Interview Assistant for Technical Interviews, designed specifically for LeetCode interviews. Get real-time coding assistance to enhance your performance.
Forwarded from 🔋 Труба данных
https://topicpartition.io/blog/postgres-pubsub-queue-benchmarks
Прекрасная статья о том, что момент, когда вам в большинстве случаев, перестанет хватать Posgres на самом деле очень и очень далек.
И как Pub/Sub решение, и как Redis решение, и Data Lake решение.
Циферки, метрики, замеры внутри, все как вы любите 😃
P.S. Конечно же, никто не говорит о том, что Kafka надо заменять на Postgres. The claim isn’t that Postgres is functionally equivalent to any of these specialized systems. The claim is that it handles 80%+ of their use cases with 20% of the development effort.
Но поздно, стервятники уже налетели...https://www.morling.dev/blog/you-dont-need-kafka-just-use-postgres-considered-harmful/
@ohmydataengineer
Прекрасная статья о том, что момент, когда вам в большинстве случаев, перестанет хватать Posgres на самом деле очень и очень далек.
И как Pub/Sub решение, и как Redis решение, и Data Lake решение.
Циферки, метрики, замеры внутри, все как вы любите 😃
P.S. Конечно же, никто не говорит о том, что Kafka надо заменять на Postgres. The claim isn’t that Postgres is functionally equivalent to any of these specialized systems. The claim is that it handles 80%+ of their use cases with 20% of the development effort.
Но поздно, стервятники уже налетели...https://www.morling.dev/blog/you-dont-need-kafka-just-use-postgres-considered-harmful/
@ohmydataengineer
TopicPartition
Kafka is fast -- I'll use Postgres
Why you should just use Postgres instead of Kafka for small-scale message queuing and pub-sub patterns. Benchmarks and practical tests included.
💯7😁1