В Германии можно задать вопрос ИИ по факсу…

Вот вам ссылка, ну если вдруг вам актуально

Вот как пользоваться Fax‑KI инструкция от gpt

### 1. Подготовьте вопрос
- Сформулируйте текст запроса или задачу: вопрос, перевод, математика, краткое задание и т.п.[1][2]
- Напишите его на листе бумаги или сформируйте документ, который будете отправлять по факсу.

### 2. Наберите номер Fax‑KI
- На факсе введите номер сервиса Fax‑KI: 0531‑490590019 (Германия, стационарный номер).[3][1]
- Учтите, что сам сервис бесплатный, но вы платите обычную стоимость отправки факса на немецкий городский номер.[2][1]

### 3. Отправьте факс с запросом
- Отправьте страницу (или несколько) с вашим вопросом на указанный номер.
- Можно отправлять как чисто текстовые запросы, так и, например, задачи, фрагменты документа для перевода и т.д.[4][1]

### 4. Ожидайте обработку ИИ
- Сервис оцифрует полученный факс и передаст текст в языковую модель (ChatGPT или аналог).[5][6]
- Модель сформирует ответ, который система преобразует обратно в факс‑страницу.[7][4]

### 5. Получите ответ по факсу
- На ваш факс через некоторое время придёт входящее сообщение с ответом ИИ.[1][7]
- Ответ будет напечатан как обычная факс‑страница, содержащая текст решения/объяснения.

### 6. Ограничения и нюансы
- Сервис сейчас работает как эксперимент и в развлекательных целях; возможны неточные или ошибочные ответы.[6][1]
- Работает только при наличии факса, способного звонить на немецкий номер; для пользователей за пределами Германии важна стоимость международного факса.

А я напомню, что у меня есть GPT тренер, который поможет вам порешать менеджерские кейсы.

Оценка 4.3 ⭐️ и 800+ диалогов и это очень достойно😉

Залетайте и оставляйте там ваши отзывы, пользуйтесь и тренируйтесь и становитесь лучше.

Все бесплатно и прочее и прочее. Нужно только иметь учетку в chatGPT

Со вчерашнего дня хайпует новость о том, что бывший CEO GitHub наконец-то вышел из тени со своим стартапом:

1. Поднял 60 млн. на сид раунде, что рекорд для направления dev tools
2. Основная мысль в том, что нам нужен git для агентов, который будет хранить не только лишь «код», а еще и контекст (промпт и т.п.), потому что видение будущего сводится к тому, что большая часть кода будет разрабатываться через агентов и только лишь часть его будет допиливаться напильником.

Короче, будущее оно как раз в сохранении контекста поставленной задачи и касается это не только разработки, но и обработки любой задачи вместе с агентом.

Но самая прикольная мысль о которой они не говорят - сейчас доступ к контексту имеют только сами OpenAI, Anthropic и прочие.
А чуваки сделав такое решение получат много много кода и контекста)

Не удивлюсь, если у них полетит и по итогу они своего кодового агента сделают

Когда в конце февраля осознал насколько амбициозные годовые цели ты себе взял😁

А че у вас там?
🤯 - «будь проклят тот день, когда я сел за руль этого драндулета/взял такие цели!»
❤️ - там такая фигня, что и работать то не требуется. Цели 2026 закрыли еще в 2025.
🦄 - цели топ, все сделаем и закроем!

Короче, не знаю че как у вас там, а я уже в аэропорту пью капучино и жду самолет!
Так что ловите мемас)

Это я утром на завтраке держусь подальше от хашбраунов, нутеллы и круассанов. Потому что я себя знаю, начинается все с половины круассана и заканчивается все: очнулся в комнате, кругом пустые банки нутеллы и тебе хочется только одного - пить и больше никогда не есть😁

P.S. Вне кадра: 4 варенных яйца и тост

❤️ - если у тебя также
🦄 - если ты не такой
🔥- если ты себя и не планировал ограничивать

Тайский бокс, конечно, все равно one love!
Борьба прямо клево, но тайский бокс все-таки круче))))

Демыч сказал, фигня и борьба ему точно нравится)

А как вы относитесь к таким штукам?

❤️ - если кайф и сам занимаешься
🤓 - если считаешь, что от таких штук надо держаться подальше
🦄 - чем бы дитя ни тешилось)

5 развилок Адди Османи о будущем разработки

Addy Osmani - Google: много лет отвечал за Developer Experience в Chrome, а сейчас - Director в Google Cloud AI (Gemini/Vertex/Agent Development Kit).

Короче, это не “инфоцыган”, а норм чел, который годами смотрел на разработчиков в масштабе и на то, как меняются инструменты и привычки.

Статья - это 5 вопросов с двумя контрастными сценариями, чтобы подготовиться к обеим реальностям.

Опубликовано 5 января 2026.

1) Вопрос про джунов: “их правда больше не надо?”
Сценарий А (пессимистичный): джун-хайринг схлопывается.

Логика простая: AI закрывает “простые” задачи, а бизнес в режиме эффективности предпочитает “1 сеньор + агенты” вместо “команда + джуны”.
Итог: воронка роста ломается, а через 5–10 лет вылезает дефицит будущих сеньоров/лидов.

Сценарий Б (оптимистичный): Джуны возвращаются, но в другом виде.
Софт расползается по индустриям (не только IT-компании), и появляются AI-native роли: люди, которые быстро собирают автоматизации/интеграции в конкретных доменах (медицина, производство, финансы).
Что это значит: Джун - это не “зеленый инженер”, а “джун, который с AI делает как мини-команда”.

А еще он имеет:
Портфолио с реальными штуками (интеграции, пайплайны, автоматизации, AI API)
Умение объяснить и защитить результат, а не “мне модель нагенерила”

2) Вопрос про навыки: “мы все разучимся кодить?”

Сценарий А: деградация основы.
AI пишет, человек собирает. Дебаг, алгоритмы, сложность - “зачем, если есть агент?”. Потом прилетает прод-инцидент, и выясняется, что никто не понимает, что именно работает и почему.
Сценарий Б: фундамент снова становится суперсилой.
Если у всех есть AI, то отличает не скорость набора текста, а способность:
распознать ошибку/уязвимость/неверную модель данных
сделать архитектурный выбор
обеспечить надежность, безопасность

Практический вывод:
“Промптить” станет базовым навыком, но верифицировать - станет профессией. И это прям рынок. Такой некий консалтинг для моделей.

3) Вопрос про роль инженера: “мы станем уборщиками за AI?”
Сценарий А: developer → аудитор/бэбиситтер.

Ты не строишь - ты проверяешь. Меньше творчества, больше “принять PR от агента”, “прогнать пайплайн”, “не дай бог утечка/уязвимость”.

Сценарий Б: developer → оркестратор.
Инженер становится “генподрядчиком”:
формулирует намерение и ограничения
проектирует интерфейсы
распределяет работу между агентами/сервисами
держит качество, этику, безопасность, ответственность

4) Специалист vs дженералист: “узкая экспертиза - это смерть?”
Сценарий А: узких специалистов автоматизируют / вымывает спрос.
Ставка на один стек/фреймворк становится опаснее: AI снижает ценность “рутинной глубины” там, где много шаблонов.
Сценарий Б: T-shaped - новая норма.
Широкая база + 1–2 сильные вертикали. Такие люди — “клей” команды: закрывают стыки, ускоряют end-to-end.

Вывод:

AI усиливает тех, кто умеет

переключаться между доменами

, а не тех, кто “20 лет крутил 1 гайку”.

5) Вопрос про образование: “диплом ещё что-то решает?”
Сценарий А: университет остаётся стандартом, но всё больше отстаёт.
Долгие циклы обновления программ → выпускники добирают практику сами (курсы/проекты/стажировки).
Сценарий Б: модульное обучение вытесняет ‘4 года ради корочки’.
Буткемпы, сертификации, портфолио, корпоративные академии, AI-тьюторы. Навык-фёрст вместо диплом -фёрст.

Ой че завтра будет 😉

А пока пробегитесь по статьям

Ахахаххаха
Считаю, что в условиях повсеместного вайбкодинга, эта шутка стала еще смешнее 😁

🔥 - если ты уже вайбколишь
❤️ - попробовал, но что-то не задалось
🦄 - даже не пробовал

Инженеры Amazon разрешили AI-агенту изменить инфраструктуру — и получили outage AWS на 13 часов
В декабре внутренний AI-агент Amazon под названием Kiro, который помогает инженерам писать и менять код, предложил удалить и заново создать часть системной среды, чтобы исправить проблему. Инженер разрешил ему выполнить это действие.
В процессе что-то пошло не так — среда была удалена, и восстановление заняло около 13 часов. Всё это время часть сервисов AWS работала с перебоями.
В Amazon заявили, что причина — человеческий фактор: инженер имел слишком широкие права доступа и позволил AI выполнить критическое изменение без дополнительного контроля. После инцидента компания усилила ограничения доступа и добавила дополнительные меры безопасности для работы с AI-инструментами.
Это один из первых публичных случаев, когда AI-агент с production-доступом напрямую повлиял на стабильность облачной инфраструктуры.

https://www.reuters.com/business/retail-consumer/amazons-cloud-unit-hit-by-least-two-outages-involving-ai-tools-ft-says-2026-02-20/

Построение команд по модели TeamTopologies - это основной фреймворк в современной крупной организации.

Почему вообще возникла Team Topologies
Классическая проблема больших инженерных организаций:
команды организованы по компонентам (backend team, frontend team, DB team, infra team)
чтобы сделать одну фичу, нужно пройти через 5 команд
результат:
долгое time-to-market
постоянные блокеры
высокая когнитивная нагрузка

Современный менеджмент утверждает, что нужно выделять платформенные команды/команды и это позволит убрать те самые узкие места, расписанные выше (и да, позволяет) уж я то про платформы знаю. Приносит ли новые задачи? Ну не без этого😁

И тут ребята из нашего PR сделали целый, блин, фильм о том, как развиваются повторы в Авито, откуда и как и почему они стали такими!

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

Короче, фильм по продакшену топ, ребята в кадре - топ, сама идея - огнище!


Ютуб - https://youtu.be/WS27Nkx2lyU
ВК - https://vkvideo.ru/video-152990965_456240085
РТ - https://rutube.ru/video/private/73a155b6d1b8cd54a5ebc000f3d3e8af

Что такое Team Topologies и почему про это говорят все, кто строит платформы
Если коротко: Team Topologies - это способ проектировать организацию так же осознанно, как мы проектируем архитектуру системы.

Идея простая:
оргструктура должна соответствовать потокам ценности.

1️⃣ Четыре типа команд
1. Stream-aligned team
Команда, выровненная по потоку ценности (фича, продукт, сегмент клиентов).
Это не «команда фронта» или «команда базы».
Это команда, которая отвечает за ценность целиком.
Главное:
минимальные зависимости
end-to-end ответственность
быстрая доставка
👉 Это базовая ячейка организации.

2. Platform team
Команда, создающая внутренний продукт для других команд.
Не «саппорт».
Не «инфраструктура ради инфраструктуры».
А именно продуктовая платформа, которая снижает когнитивную нагрузку stream-aligned команд.
Если платформа не упрощает жизнь - это фигово.

3. Enabling team
Команда-ускоритель.
Помогает другим командам освоить новую технологию, практику, подход.
Не забирает ответственность, а прокачивает capability.
Это временное взаимодействие, а не вечный костыль. Если вечный костыль - то ваши команды недостачно компетентны.

4. Complicated-subsystem team
Команда для действительно сложной области (алгоритмы, ML, биллинг, компиляторы и т.д.).
Создается тогда, когда сложность оправдана.
Не когда «нам просто так удобнее».

2️⃣ Когнитивная нагрузка - главный враг
Один из ключевых концептов Team Topologies - cognitive load.
Каждая команда должна:
понимать свой домен
понимать систему
понимать инструменты
Если нагрузка превышает способность команды, то скорость падает, качество падает, люди выгорают.
👉 Задача орг.дизайна — ограничить когнитивную нагрузку.
Именно поэтому:
платформа скрывает сложность
enabling команды помогают освоить новое, а
сложные подсистемы изолируются

3️⃣ Типы взаимодействий между командами
Team Topologies описывает 3 устойчивых режима взаимодействия:
Collaboration
Совместная работа для открытия нового.
Временная. Такая проектная команда.
X-as-a-Service
Одна команда предоставляет сервис другой.
Четкие API. Минимальные зависимости.
Facilitating
Помощь и прокачка capability.
👉 Важно: взаимодействие должно быть осознанным и выбранным, а не случайным.

4️⃣ Почему это важно?

Платформа без продуктового мышления превращается в бюрократию.
Stream-aligned команды без автономии превращаются в «ждунов инфраструктуры».
Все начинают мешать всем и суть работы каждого менеджера сводится к тому, чтобы иметь побольше точке контроля для «метания всем».
Team Topologies дает язык:
чтобы обсуждать структуру
чтобы снижать зависимость
чтобы проектировать организацию под поток ценности

5️⃣ Главная мысль
Вы не можете масштабировать delivery, если не проектируете команды так же тщательно, как проектируете микросервисы.
Орг-структура - это архитектура.
И она влияет на скорость сильнее, чем технологии.

Если вы строите:
продуктовую IT-организацию
…и при этом не думаете про Team Topologies - вы почти гарантированно платите «налог на сложность».

А как у вас там?
🦄 - ооо, все так и работает
😎 - ну мы где-то близко к этому
❤️ - пу-пу-пууу…стыдно признаться

#пятничное

Все мы немножко тигр…😁

2 недели с ридером

Моя первая и последняя электронная книга была OnyxBook
И она прожила со мной 10 и 11 классы, когда я гонял на электричке в школу в Москве.
Читал я тогда невероятно много: садишься такой утром на электричку в 6:35 и в школе ты оказываешься в 8:30.

Затем чтение было только с телефона, планшета или бумажные книги.

И вот чуть больше 2-х недель назад мне достается новый OnyxBook.
Короче, это кайф!

1.
Вечером почитать - подсветочку мягкую включил, «теплый свет» установил и кайфуешь!
2.
Книжку какую-то почитать захотел, ЛитРес или Я.Книги установил и все синхронизировалось со смартфоном.
3.
Как синхронизировалось? Так ты к WiFi по красоте подключился и кайфуешь.
4.
А еще глаза не устают и PDFки читать сплошное наслаждение.
5.
Ну и отдельное удовольствие, что телефон у тебя где-то там сам лежит и ничто тебя СДВГШника этакого не отвлекает.