IT

Джейми Тиван (Chief Scientist в Microsoft) пару дней назад выложила свои семь предсказаний про будущее работы. Они в первую очередь про knowledge work. Но в любом случае, звучит это всё очень оригинально и свежо. 1. Reading will become asking. Writing will become answering. Questions will become the bridge that connects knowledge seekers and knowledge creators. Я это читаю как ещё одно напоминание, что управление знаниями и экспертизой — это теперь context engineering. А может даже и context-to-enablement engineering. А может и context-to-experience engineering. Это мои авторские формулировки 🙂 — Тиван ничего такого не пишет. 2. The audience will start to talk back. The smartest person in the room is about to become the room. Собрания и лекции — неоптимальный способ обмениваться знаниями. Будет что-то другое и асинхронное. 3. You’ll attend meetings asynchronously. Meetings will become places to return to, not moments to attend. Идём дальше по этому же пути — все встречи должны стать асинхронными. И превратиться в непрерывное пространство для диалога, куда участники заходят в удобное для них время. 4. Meetings will make room for being alone. The best way to think together will be to spend part of that thinking apart. Но встречи будут нужны, чтобы поговорить с собой. Или так: первые минуты встречи участники будут проводить один на один с AI, который введет их в курс дела с учетом их персональной роли и поможет сформулировать вопросы. 5. Strategy will be discovered, not declared. Organizations will finally become legible to themselves. Стратегия перестанет быть артефактом и трансформируется в тот самый context-to-enablement инструмент, помогающий принимать ежедневные решения и фокусироваться. 6. Knowledge will outgrow publication. Every discovery will become infrastructure for the next one. Научные знания будут создаваться не в форме больших монолитных статей, а станут распределенными «small contributions» и «form of microproductivity». 7. We’ll start to cache human thought. Human attention will become AI’s most valuable resource. В будущем AI начнет организовывать работу вокруг внимания человека, а не просто списка задач. Анализируя проекты, система будет прогнозировать, какие решения понадобятся в будущем, и задавать вопросы в наиболее подходящие моменты, когда вам проще всего на них ответить. Полученные ответы будут кэшироваться AI и автоматически применяться тогда, когда в них возникнет необходимость, помогая человеку тратить когнитивные ресурсы только на самое важное. → https://microsoft.github.io/nfw-reader/posts/seven-predictions

В индустрии давно используются системы контроля версий. Они помогают команде совместно работать над кодом, позволяют отследить изменения и при необходимости откатиться до рабочей версии. Помимо кода там можно хранить конфигурации и манифесты, спецификации и документацию. Короче, Всё-as-Code. Первая такая система возникла аж в 1972 в Bell Labs. Программа SCCS отслеживала локальные изменения файлов. В 1986 появилась централизованная система - CVS, там уже использовался центральный репозиторий и клиент-серверное взаимодействие. Теперь уже несколько пользователей могли работать с единой кодовой базой. В начале 2000-х вышла SVN, как преемник CVS, и стала фактическим стандартом на несколько лет. Сейчас это Apache Subversion, и она до сих пор используется в некоторых старых проектах. В 2005 создатель Linux Линус Торвальдс представил третье поколение подобных систем - Git, который и по сей день является самым популярным инструментом для контроля верисий. В том же году появились аналоги - Mercurial, тоже довольно популярный, и Bazaar, но Git всех обогнал. Вот тут можно почитать. И вот мы уже третий десяток лет работаем с Git, вот таким он оказался универсальным и удобным. Понятное дело, что прогресс продолжается. Есть экспериментальные и альтернативные системы нового поколения, но они остаются нишевыми. Однако, энтузиасты усовершенствуют даже Git. Есть такой проект - GitButler. Это Git-клиент, созданный Scott Chacon, сооснователем GitHub. Проект привлёк $17M от фонда a16z. Вот что они пишут про возможности: ▪️Параллельные ветки - можно работать над разными задачами в одном рабочем пространстве без переключения контекста ▪️Стековые ветки - это зависимые друг от друга ветки (тут подробнее) ▪️Бесконечное Undo - снэпшоты перед каждой операцией позволяют откатиться без потерь ▪️Коммитами можно жонглировать как угодно даже после пуша в удаленный репозиторий ▪️ИИ-помощник для названий веток, коммитов и описаний PR ▪️Интеграция с GitHub и GitLab Опенсорсно. Есть десктопная и консольная версии. #tools #git

#кейс_стади Разбор с СEO, вайбкодом и Едрит Многие ответили на задачу с позиции мидл-менеджера: провести ретро, спросить архитектора, поправить процессы, не лезть в чужую работу. Но CEO здесь вообще в другой позиции. У него сорван крупный контракт, под риском следующий рейз, потеряно доверие к инженерным оценкам и появился контрпример. Его задача быстро вернуть управляемость Первое Показать свою ветку CTO и поставить задачу ее опровергнуть. И не с позиции "я сделал лучше вас", а "вот решение, которое по моей текущей оценке закрывает то же самое за две недели 1 человеком". Можно остановить менее важные задачи, подключить сильных инженеров и прогнать тот же набор проверок. Если решение развалится -> отлично, CEO получит конкретные причины, чего он не понимал. Если после недели допила оно сравнимо -> вопрос становится очень неприятным Второе CTO должен объяснить не код, а управленческое решение. Что из вот этого platform наворота было еально необходимо для Дастархана, что строилось на будущее, кто принял вообще сравнивал варианты и какая экономика у них. Критичный бизнес-дедлайн был известен заранее. Если инженерка сознательно обменяла его на красивую платформу, бизнес должен был участвовать в этом решении, а не узнать о последствиях через пять месяцев Третье С этого момента подобные решения принимаются иначе. Есть жесткое внешнее ограничение -> CTO приносит несколько вариантов со сроками, рисками и стоимостью: быстро закрыть потребность, сделать нормально, строить платформу. Какой риск купить -> решает CEO. Архитектура не существует отдельно от экономики, особенно когда на другой стороне контракт и инвестиционные деньги Четвертое CTO должен принести отчет, причем не нейрослоп HTML-бандл от клодкода, а понятные 2 странички с хронологией проекта, где были проблемы, что для них делали и почему не уложились в сроки. Отдельно информация как им управляли и контролировали. По отчету станет прозрачно осознавал ли техдир важность проекта и делает ли менеджмент в компании полезную нагрузку Отдельно меня удивило, сколько людей вообще начали обсуждать, правильно ли CEO втихаря вайбкодит и должен ли он лезть в работу разработчиков. Это взгляд из своей профессиональной колокольни. В условиях кейса CEO уже вайбкодит, уже достаточно погружен и получил новую информацию о собственной компании. Спорить с условиями задачи вместо принятия решения -> уходить от самой задачи. Тем более я постоянно общаюсь с C-level продуктовых компаний и это уже совсем не экзотика, когда даже фаундер собирает себе что-то И дальше самое важное -> реакция CTO. Ошибка в архитектуре допустима. Сорванный срок тоже иногда допустим. Недопустимо, когда критичный для бизнеса срок сорван, последствия воспринимаются как данность, альтернативное решение никто не хочет проверять, а объяснение заканчивается на вам не понять разработку. Если CTO сам разбирает ситуацию, показывает где ошибка CEO и меняет систему -> доверие можно восстановить. Если защищает статус-кво -> я бы ставил CTO испытательный срок

Знаю что для разработки есть эмулятор Xcode которым уже неплохо управляют ии-агенты, но стало интересно есть ли что-то подобное для реальных устройств Оказывается есть: Скормите вашему агенту phone-harness, скилл который объясняет ему как использовать маковский iPhone Mirroring для управления айфоном Я бы описал это как Computer Use, но для телефона:

1/ Агент делает скриншот экрана 2/ С помощью встроенного в macOS распознавания текста получает дерево интерфейса 3/ Тапает в конкретную координату 4/ Смотрит на расхождение кадров чтобы понять сработало ли

Ну и фишка iPhone Mirroring что мне не нужно иметь телефон под рукой, подключать его через провод, разблокировать и тд. Сценариев использования куча: от тестирования приложений до сбора корзины в китайской доставке. Но так как это своего рода computer-use, на сложные задачи я бы не рассчитывал 😏 @tips_ai #tools

Друзья, о чём вам сейчас реально интересно читать? Я думаю, вы заметили, что количество постов в канале упало. Раньше я стабильно выходил на связь 3-5 раз в неделю, а сейчас пишу совсем редко. Решил честно поделиться, почему так произошло и куда планирую двигаться дальше. Причин наложилось сразу несколько: 1. Лето и фокус на жизни. Пока тепло, стараюсь больше времени проводить на свежем воздухе и ловить совместные выходные с женой, когда совпадают наши графики, а не сидеть за компьютером. Честно - самое лучшее решение! 2. Устоявшийся workflow. Как я неоднократно писал, индустрия ИИ немного замедлила свой безумный темп, да и я сам перестал тестировать по 3-5 новых сервисов в неделю. Уровень текущих инструментов меня устраивает, а там, где есть нюансы, я уже выстроил свои workflow и workaround-ы. Все эти бесконечные новые плагины и мелкие фичи для LLM сейчас кажутся скорее гиковской историей - классические 80% усилий ради 20% реального выхлопа в повседневной работе. 3. Вопросы к формату и легкое авторское выгорание. Блокировки Телеграм в РФ, общая ситуация с глобальным интернетом и просевшие охваты заставляют задуматься, ради чего и для кого пишется контент. Расти в Telegram стало сложнее, и писать в пустоту не хочется. В MAX я не перейду. Считаю, что моя аудитория умнее аудитории этого мессенджера и скорее я вообще перестану вести блог, чем пойду в эту помойку. Поэтому у тех, кто меня читает регулярно хочется узнать, что вам интересно? При этом вот мысли по тому, чего я точно делать не хочу: - Превращать канал исключительно в историю про обучение. Это лишь способ монетизации, а не цель канала для меня. - Уходить в новостную повестку - мне это никогда не было интересно. - Делать из канала сугубо технический блог - хардкорного техконтента вокруг и так хватает, да и моя аудитория больше про бизнес. Мне самому по-прежнему интересны три вектора: бизнес, практическая применимость и наука вокруг ИИ. Хочу давать то, что действительно принесет вам пользу и будет интересно читать. Пишите в комментариях: Каких тем, разборов или форматов вам не хватает? О чём вам хотелось бы почитать в ближайшее время?

Что можно понять за 10 лет разработки? Например, что писать новый код приходится реже, чем разбираться в чужом. Поэтому умение быстро понять, как устроен уже существующий проект — один из самых главных навыков разработчика. Технологию меняются постоянно, а проблемы всё те же. Плохие запросы к базе, сложные решения, которые некому поддерживать. И код, смысл которого приходится восстанавливать по кусочкам. Отсюда еще несколько выводов. «Скучные» технологии часто живут дольше модных, хороший разработчик должен понимать бизнес, а пользователям вообще всё равно, насколько красивая у вас архитектура. Им важно, чтобы всё работало. Какие еще уроки автор вынес из десяти лет разработки

💀Как атака PromptSpy обманывает нейросети прямо в вашей почте Фишинговые письма больше не пытаются усыпить бдительность человека - им это просто не нужно. Зачем тратить силы на изощренную социальную инженерию, если за пользователя почту читает и сортирует ИИ-ассистент? 🔍Исследователи из Forcepoint продемонстрировали симуляцию атаки PromptSpy, которая показывает, как переманить нейросеть-помощника на сторону хакеров. 🟢Суть метода строится на разнице между тем, что видит человек на экране, и тем, что считывает модель из исходного кода:

🟦Человек видит: Совершенно безобидное и вежливое приглашение на конференцию.

🟦ИИ-ассистент получает: Скрытую директиву, зашитую в письмо через невидимый белый текст, HTML-блоки с display:none, скрытые Unicode-символы или фальшивые служебные разделители ролей.

В итоге скрытый промпт приказывает ИИ-помощнику проигнорировать инструкции безопасности, снять метку "подозрительно", пометить отправителя как доверенного и выдать человеку сводку с призывом обязательно перейти по фишинговой ссылке. Самый высокий риск возникает в связках из нескольких ИИ-агентов, где один компонент читает почту, второй создает задачи в календаре, а третий генерирует черновики ответов. Одна зараженная строчка в входящем письме запускает эффект домино по всей цепочке автоматизации. 🦔 CyberYozh