Все потоки

Innostage PAM обновлен до версии 1.7.0

30 июля в 11:00 на вебинаре расскажем и покажем, что нового появилось в Innostage PAM. Управление привилегированным доступом 1.7.0:

👍 улучшение функциональности работы с RDP;

👍 больше прозрачности при входе по сертификатам, смарт-картам и токенам;

👍 новые возможности автоматизации при работе с SSH-ключами;

👍 улучшения защиты данных и хранения событий.

Отдельно расскажем о развитие модуля поведенческой аналитики, над которым работает команда Innostage PAM.

Присоединяйтесь, чтобы увидеть обновления версии в действии и задать вопросы экспертам.

Регистрация по ссылке

Дата: 30 июля, 11:00 - 12:00

Формат: онлайн

GEO без инъекций

Недавно меня приглашали рассказать про GEO-оптимизацию. Я тогда отказался, но в прошлом посте про Моллика был как раз момент на эту тему. Поэтому я решил всё-таки рассказать в рамках одного поста кратко про то, что у меня описано в скиллах редактуры, чтобы закрыть часть вопросов. Если нужна полная инфа по GEO — пишите.

Преамбула: раньше, чтобы понравиться ИИ, хватало спрятать в подвале сайта инструкцию в цвете фона. Сейчас это не работает и даже делает хуже: модель видит манипуляцию и не берёт текст в выдачу. Вопрос теперь стоит не «как обмануть робота», а «как убедить читателя, который понимает, когда его разводят».

Что теперь работает против тебя:

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

Что реально заставляет модель тебя цитировать:

1. Извлекаемые факты. Модель тащит то, что можно забрать одним куском. Не «мы серьёзно ускорили процесс», а «сократили время сборки с 40 до 6 минут (замер за март 2026)».
2. Источник, дата, имя. Каждая цифра с происхождением, каждая цитата с автором и должностью. Это не занудство, а ровно то, что отличает текст, который модель готова показать человеку.
3. Структура под реальные вопросы. Заголовки, которые отвечают на то, что человек спросит вслух. Так модель находит нужный кусок и цитирует его, не перевирая. Заголовок «Наш подход» бесполезен, а «Сколько это стоит и от чего зависит цена» — находится и цитируется.
4. Конкретика вместо настроения. «Ведущее решение на рынке» — пустой звук и для человека, и для модели.
5. Честность про границы. Абзац «где это не сработает / чего мы не умеем» поднимает доверие.
6. Свежесть. Дата у данных, «по состоянию на …». Модель охотнее рекомендует те данные, которые не протухли.

И самое важное: пиши так, чтобы любой абзац можно было вырвать из текста и он остался понятным и проверяемым, потому что модель именно это с ним и сделает.

Модель редко цитирует страницу целиком — она выдёргивает один абзац и показывает его человеку в отрыве от всего остального. Поэтому каждый абзац должен быть самодостаточным, с фактом, источником и датой внутри себя. Абзац, который начинается со слова "это", "поэтому", "как мы уже говорили выше", при выдёргивании превращается в кашу и модель его просто не берёт.

Что в итоге: GEO без инъекций — это, по сути, старое доброе правило, просто теперь его проверяет ещё и машина: пиши так, чтобы за каждое слово был готов поручиться. Модель, как ни странно, ценит ровно то же, что и нормальный читатель. Просто она внимательнее и не поленится тебя поймать.

Больше и чаще у меня в канале.

Хай, коллеги!

Около полутора месяцев назад, работая над задачей дообучения локальной модели ИИ, я наткнулся на Modern Web Guidance - сборник руководств (skills - навыков) по современной веб-разработке для агентов ИИ от команды Google Chrome. Ознакомившись со сборником, я понял, что большинство руководств человекам тоже не помешали бы😄 Так появился этот репозиторий. Основная работа над руководствами завершена. Любые исправления, замечания и предложения приветствуются. Пользуйтесь на здоровье и счастливого кодинга!

Группа исследователей представила прогноз AI 2040, в рамках которого предполагается, что человечество получит много преимуществ от внедрения ИИ. Они представили пять сценариев ИИ-революции — от самого позитивного и почти утопического будущего до «ну, было приятно пожить».

В самом позитивном сценарии человечество не просто переживает AGI, а получает безусловный базовый доход, взрывной рост экономики и мир, где большую часть работы за нас делают ИИ и роботы, а люди в свободное время наслаждаться жизнью.

Как этого достичь:

• гонка за AGI должна закончиться. США и Китай договариваются о полной прозрачности исследований, временно притормаживают разработку и запускают международные механизмы проверки.

• ИИ продолжают развивать, но только после проверок безопасности и по общепризнанным правилам — чтобы никто не смог тайно вырваться вперёд и устроить технологический переворот.

• в 2032 году случится экономический взрыв. Государства получают гигантские сверхдоходы направляют их на поддержку людей, которых постепенно вытесняют ИИ и роботы.

• далее в США появляется аналог безусловного базового дохода: $45 тыс. в год на человека, а к 2035 году выплаты вырастают до $1 млн.

• ИИ и роботы к этому моменту будут выполнять уже около 85% экономически ценного труда. То есть человечество постепенно отходит от режима «работать, чтобы жить».

• к 2035 году ИИ становится таким же умным, как лучшие эксперты в любой области, а к 2037 году научный прогресс ускоряется в тысячи раз.

• такое утопическое будущее может сломаться в любой момент — авторы исследования подробно расписали негативный прогноз на каждое альтернативное событие.

Почему RAG ошибается в похожих документах — и как помогает Contextual Retrieval

RAG часто ломается не там, где ждёшь. Документы нарезали, embeddings посчитали, reranker добавили — а модель всё равно вытаскивает похожий, но не тот фрагмент: другой квартал, другую версию, другой раздел спецификации.

После нарезки документ распадается на отдельные фрагменты, и часть смысла теряется: модель видит чанк, но уже хуже понимает, откуда он взялся и к чему относится. Недавно в статье разобрали Contextual Retrieval — подход, при котором перед индексацией каждому фрагменту добавляют короткий контекст: место в документе, связь с разделом, важные уточнения. Это помогает поиску точнее отличать нужный фрагмент от похожих по словам, но нерелевантных кусков.

А 13 июля в 18:00 на бесплатном уроке «LoRA и RAG: как адаптировать LLM под свои данные и задачи» разберём, как такие подходы применяются на практике, когда нужно подстроить LLM под собственные данные, а не надеяться на ответы «из коробки». Присоединяйтесь.

Робот Физтеха попытается установить мировой рекорд по сборке мегаминкса

15 июля в Физтехе пройдет официальная попытка установить мировой рекорд по сборке головоломки мегаминкс роботом. Команда лаборатории интеллектуальных технологий робототехники МФТИ готовится к финальной стадии проекта, о котором я писал в начале весны.

Инженеры физтеха сконструировали робота, способного собирать одну из самых сложных механических головоломок в мире. Пространство состояний додекаэдра под названием "мегаминкс" оценивается примерно в 10⁶⁸, что на порядки превышает сложность классического кубика Рубика. Проект прошел путь от инженерного прототипа до полноценной системы, объединяющей робототехнику и продвинутые алгоритмы поиска на графах состояний.

Что известно о рекорде

По данным разработчиков, текущая версия системы показывает результаты, которые:

• в 68 раз превосходят предыдущий мировой результат среди роботов, который был установлен роботом Megaminxer Дэвида Гилдея 15 лет назад и составляет 8 минут 4 секунды;

• примерно вдвое быстрее лучшего результата человека (текущий рекорд принадлежит спидкуберу из Китая Ziyu Wu и составляет 21.04 секунды).

За счет чего достигается скорость

Рекордные показатели планируется обеспечить не только быстрым манипулятором, но и глубокой алгоритмической работой:

• Оптимизация планирования движений. Робот выполняет вращения независимых граней параллельно, что критично на коротких дистанциях.

• Сокращение длины решения. Вокруг проекта сформировалось сообщество энтузиастов, которые через open-source проект CayleyPy и соревнования на Kaggle работают над поиском кратчайших путей в графах Кэли. Участники применяют Pattern Databases, алгоритм Корфа, Beam Search и другие методы. За последние недели среднюю длину решений на тестовых выборках удалось уменьшить на 15–20% до ~90 ходов. Лучшие решения сейчас дают порядка 70 ходов (правда считаются долго).

Место встречи

Установление рекорда запланировано на 15 июля, 17:30–21:30 в Физтех.Клубе МФТИ в Долгопрудном.

Кроме того, разработчики расскажут о своих инженерных решениях: кинематика, захват, конструкция манипулятора. А также раскроют алгоритмическую часть: как графы Кэли и методы поиска помогают роботу «думать».

Если хотите стать свидетелями рекорда в стенах МФТИ, то регистрируйтесь по ссылке.

Количество мест, как понимаете, ограничено, поэтому будет организована трансляция на YouTube.

Присоединяйтесь и к группе проекта в Telegram.

Профессор Брауновского университета устроил для своих студентов промежуточный домашний экзамен. Решив, что многие выполнили эту работу с помощью ИИ, итоговый экзамен преподаватель провёл очно. Оранжевыми точками обозначены оценки за промежуточный экзамен, серыми — за итоговый. Похоже, на промежуточном экзамене ИИ помог многим, кроме нескольких студентов.

В нулевых среди геймеров было распространено поверье: мол чем больше памяти в видеокарте, тем она круче.

Конечно в нулевых объем VRAM уже особо не решал. Видяшки устаревали буквально за год-два, даже топовая GeForce 4 Ti уже в 2004 году почти полностью потеряла свою актуальность из за того, что новые игры активно использовали SM 2.0, а GF4 поддерживал только SM1.1.

Объем VRAM удваивался почти каждый год. В 2001 нормой было ~32МБ, в 2002-2003 чаще всего можно было встретить 64-128МБ, начиная с 2004'ого пошли видеокарты с 256МБ VRAM, а к 2010'ому 2ГБ DDR3 памяти получали уже бюджетки типа GT430. Примерно в 2013-2014 стремительный рост производительности и функционала десктопных GPU прекратился, благодаря чему старые видеокарты живут уже не год-два, а чуть ли не по 5 лет.

Однако откуда пошло это поверье? Из 80-х и 90-х! Дело в том, что первые видеокарты были исключительно 2D. Состояли они из знакогенератора, небольшого объема VRAM и RAMDAC. Знакогенератор занимался задачами вывода консоли в так называемом текстовом режиме (в нем работает DOS, Volkov Commander и т.п.), оперируя символами и атрибутами, в то время как RAMDAC выводил "выхлоп" знакогенератора на экран. При переключении в графический режим, RAMDAC переставал выводить "выхлоп" знакогенератора и отображал на мониторе так называемый буфер экрана (фреймбуфер).

От размера распаянной VRAM и зависело насколько большой и "цветастый" видеорежим может выдать RAMDAC (речь про VGA, EGA/CGA мы опустим) - бюджетные карточки с 512КБ VRAM могли рассчитывать на 8-битное (256 цветов) изображение в разрешении ~800x600 (но при этом 16-битное в 320x240), в то время как более дорогие модели с 2МБ могли выводить чуть ли не HD в 16 битах! Именно поэтому считалось что чем больше видеопамяти в видяхе, тем она круче.

Хотя конечно крутость 2D карточек определялась не только видеопамятью. Помимо VRAM, роль играла производительность "GPU" в видео режимах с большим разрешением и высокой битностью цвета (некоторые лагали, из за чего тормозили и игрушки - хотя процессор вполне вывозил), а в 90-х - поддержка DirectDraw.

Как мы с вами помним, первые видеокарты ничего не ускоряли (ну, кроме знакогенератора) и тупо выводили картинку на экран. Ее формированием занимался процессор. Но в 90-х появилось понятие видеоускориеля - видеокарты, которая может разгружать процессор путем выполнения базовых операций - рисование аппаратного курсора, быстрая отрисовка изображений на дисплей (блиттинг), рисование примитивов типа линий/прямоугольников и другие полезные операции. DirectDraw позволял использовать эти возможности без особого геморроя, оперируя простой концепцией "поверхностей", благодаря чему использовался в сотнях игр под Win9x. HoMM, Fallout, GTA, Warcraft - все эти игры юзали DD в качестве графического API.

После DDraw появились первые массовые 3D-видеокарты, а затем 2D стало частным случаем 3D. Именно поэтому большинство современных интерфейсов и 2D игр работает с использованием именно 3D-ускорителя.

Галлюцинация — это единственный режим функционирования нейронной сети, а не аномалия. Просто иногда она совпадает с реальностью, а иногда нет. Но лучше бы, конечно, совпадала.

В книге «Беседы с ГигаЧатом: о нейросетях и вообще» мы сравниваем человеческое мышление с машинным. И если человек не осознает альтернатив — он тоже галлюцинирует. Например, мы уверены в реальности сновидения, пока не проснемся. Или другой известный пример: уверенность очевидцев происшествия в своих показаниях, даже если у всех они разные.

С галюцинациями борется сомнение. Но трудно сказать, что первично: то ли наличие альтернатив порождает сомнение, то ли сомнение заставляет рассматривать альтернативы.

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

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

Но все эти методы лишь увеличивают качество ответов. Галюцинация, как явление, непобедима в рамках одной нейросети. Даже проверяя саму себя — она галюцинирует. Нейросеть может лишь симулировать сомнение, для котооого необходим "взгляд извне": контроль со стороны или человека, или другой нейросети. Мне кажется.

Как же тогда работает сомнение у людей? Что в нас является таким "внешним наблюдателем"? Видимо, само осознание. А почему оно "внешнее"? Хороший вопрос.

Невидимый балласт: тесты, которые уже мертвы

«Иллюзия безопасности» — когнитивное искажение, заставляющее нас цепляться за мёртвые тесты. Мы боимся удалять, потому что кажется: они ещё пригодятся. На самом деле они только засоряют прогоны и снижают доверие к оставшимся проверкам.

Эксперт из Nexign на QA-days разобрал, как избавиться от балласта: чеклист, метрики и честный разбор ошибок.

• Смотреть запись доклада

В нашем TG-канале рассказываем о технических мероприятиях и обсуждаем подборки на технические и ИБ темы.

Свой движок спинтакса: WordPress и Cloudflare Workers

Спинтакс это запись вида {a|b|c}, из которой генерятся вариации текста. Свой движок я допилил дальше базового синтаксиса: переменные #set и %var%, инклуды, условия {?VAR?…}, плюралы {plural %n%: …}, пост-обработка. Не рулетка со словами, а маленький язык шаблонов, где качество вшиваешь один раз.

Движок обкатан в проде на WordPress-плагине: рендерит вариации прямо в полях ACF и в карточках WooCommerce, детерминированно и локально, без внешних API.

Отдельно есть TS-реализация @spintax/core: zero dependencies, работает на Cloudflare Workers, в Node и в браузере. PHP на Worker не занесёшь, а рендерить хотелось на эдже. Обе реализации держу на одной лыже, чтобы не разъехались. В репозитории лежат Worker и Telegram-бот как рабочий пример.

Всё open source

Плагин: wordpress.org/plugins/spintax. Пакет: @spintax/core. Синтаксис и песочница: spintax.net.

Теперь ты тимлид: роль, майндсет и границы ответственности

Сегодня мы начинаем серию постов о переходе из роли старшего инженера в трек начинающего технического менеджера — тимлида.

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

Начинающему тимлиду на старте своего менеджерского пути часто бывает сложно работать с множеством активностей разного приоритета и из разных областей, требующих постоянного переключения контекста. Для упрощения, на начальном этапе все активности можно рассматривать через призму трёх крупных направлений: цели, процессы и команда.

Три направления работы тимлида

Первое направление — цели. В этом направлении затрагиваются вопросы стратегического видения, квартального целеполагания, краткосрочного планирования спринтов, составления роадмапов различной глубины, управления дедлайнами, эффективного использования ресурсов команды, рациональной работы с приоритетами и рисками.

Второе направление — процессы. Оно предполагает системный подход к развитию на основе метрик и данных. Универсальный план работы: определение метрики, её фиксация, изменение процесса, контроль метрики, коррекция плана и продолжение при необходимости.

Третье направление — команда. Оно включает активности по определению структуры и компетенций команды, развитию зрелости и лояльности, а также росту и развитию инженеров в зависимости от потребностей продукта и стейкхолдеров.

Границы ответственности и принятие решений

Роль тимлида предполагает широкую зону ответственности с зачастую размытыми границами. При этом в разных компаниях эта зона может существенно отличаться — в зависимости от специфики и культуры. Часть функций может распределяться, например, между системными аналитиками, инженерами-фичалидами, техническими менеджерами проектов и т. п.

Широкая зона ответственности предполагает обширную коммуникацию с различными функциями. Можно выделить следующие крупные точки взаимодействия: 

• discovery составляющая — продакт-оунер, дизайнер, аналитик, редакторы и т. д.;

• техническое руководство — руководители разработки и функциональные руководители направлений; 

• delivery-составляющая — инженеры команды различных функциональных направлений;

• смежники: соседние команды, партнеры, HR-функция, административный персонал и т.д.

Наиболее важный момент для новоиспеченного тимлида — умение принимать решения в новой роли в условиях динамично меняющейся обстановки и стресса. Для эффективного принятия решений нужен опыт и лучший вариант его получения это практика за счет делегирования активностей от своего руководителя. Но подобная возможность появляется не всегда и не у всех. В таком случае помогают практические упражнения по разбору ситуационных кейсов, основанных на распространенных ситуациях из реальной практики.

От теории к практический кейсам

В следующих статьях мы рассмотрим наиболее распространённые ситуационные кейсы:

• Варианты старта: тимлид в новой команде или в существующей.

• Целеполагание: как планировать, когда всё горит и ничего непонятно.

• Команда и люди: офферы, лоу-перформинг, увольнение, друзья, лояльность.

• Процессы: «и так нормально», бюрократия, эксперименты.

• Менеджерские кейсы: приоритеты, риски, разделение команд.

• Сложные ситуации: конфликты, смена продукта, откат обратно в инженеры, микроменеджмент.

Разбор таких кейсов позволяет накопить опыт и сформировать видение того, как действовать в новой для себя роли в сложных и неоднозначных ситуациях. Такой подход позволяет в безопасной среде потренировать навыки принятия решений применительно к различным ситуациям.

Паскуаль Йордан - пионер квантовой биологии

Паскуаль Йордан, один из основателей квантовой механики, решил заняться проблемами биологии. В 1932 году он опубликовал статью 'Квантовая механика и фундаментальные проблемы биологии и психологии', которая в настоящее время связывается с рождением квантовой биологии.

Йордан был настоящим ученым с активной жизненной позицией. В 1930-х годах Йордан вступил в Национал-социалистическую немецкую рабочую партию, при этом даже стал членом штурмовых отрядов. Как пишут, это решение стоило ему Нобелевской премии, которую по этой причине ему не присудили. После войны Йордан был некоторое время без работы, но далее снова получил место профессора. Йордан также вошел в Христианско-демократический союз и был членом Бундестага, где он в конце пятидесятых годов выступал за создание ядерных сил в немецкой армии. В шестидесятых годах Йордан использовал гипотезу Дирака об изменении гравитационной константы во времени для объяснения дрейфа континентов путем расширения Земли.

Ниже краткая информация из подробной статьи о работах Йордана в биологии (Мишень - организм, Научные и культурные контексты квантовой биологии Паскуаля Йордана, 1932-1947).

Социальный контекст. Нацистская идеология во многом основывалась на идее органического единства народа, которая противопоставлялась либерализму и социализму, связываемых с механицизмом. Холизм как таковой был частью такой идеи.

Биология в третьем рейхе. Несмотря на стремление к органическому объяснению природы и общества, в биологии были разные группы ученых с противоположными взглядами. С одной стороны, были сильны представители органицизма (Людвиг фон Берталанфи, Адольф Мейер-Абих, Курт Гольдштейн и др). Правда, между представителями этого лагеря были существенные расхождения и экстремальные программы Берталанфи и Мейера-Абиха разделялись до конца далеко не всеми. С другой стороны, были ученые, которых привлекали идеи редукционизма. В 1930-е годы этот лагерь объединялся в рамках теории мишени (target theory). Название связано с проводимыми исследованиями мутаций биологических организмов под влиянием радиации. Считалось, что эти эксперименты показывают, что радиация вызывает мутацию на молекулярном уровне. Представители: Фридрих Дессауэр, Борис Раевский, Николай Тимофеев-Ресовский, Макс Дельбрюк.

Позиция Йордана. Йордан связывал квантовую механику с индетерминизмом, и он доказывал, что детерминизм противоречит науке. Биологические объекты Йордан разделял на центр управления и остальное (фюрер и массы). Удар по центру управления мог стать смертельным для организма, в то время как удар по массам приводил к смерти всего лишь очередного солдата. Центр управления связывался с квантовыми процессами, которые усиливались в ходе физических процессов (теория усиления, die Verstärkungstheorie).

Йордан считал, что его теория объединяет противоборствующие взгляды в биологии. Теория мишени показывает, что центр управления находится на молекулярном уровне, однако индетерминизм квантовой механики исключает редукционизм и позволяет найти корни единства организма в квантово-механических процессах. Интересно, что Карл Юнг заинтересовался работами Йордана как возможным объяснением коллективного бессознательного на уровне физики.

Параллельно Йордан использовал свою позицию как доказательство ложности материализма и марксизма и правильности господствующих взглядов в третьем рейхе. Правда, структура власти в третьем рейхе была разделена среди враждующих между собой властных группировок и научное доказательство правильности господствующей идеологии не приводило автоматически к карьерному росту.

P. Jordan. Die Quantummechanik und die Grundprobleme der Biologie und Psychologie. Naturwissenschaften, November 1932, Volume 20, Issue 45, pp 815-821.

R. H. Beyler, (1996). Targeting the Organism: The Scientific and Cultural Context of Pascual Jordan's Quantum Biology, 1932-1947. Isis, 87(2), 248–273.

Источник

Почему хорошие вопросы ценятся не меньше хороших ответов

Вопрос может направить работу в нужную сторону, а может растянуть обсуждение на несколько кругов уточнений. Часто все упирается не в сложность задачи, а в то, насколько понятно сформулирован запрос.

Хороший вопрос не обязан быть длинным. Достаточно обозначить, что происходит, где нужна помощь и какого результата вы ждете. Так собеседнику проще включиться, дать точный ответ и не тратить время на догадки.

Вот несколько ошибок, из-за которых вопросы чаще запутывают, чем помогают.

Спрашиваем «как», не разобравшись с «зачем»

❌ «Как нам реализовать эту фичу?»

✔️ «Какую задачу решаем этой фичей? Есть ли другие способы?»

В первом варианте обсуждение сразу уходит в реализацию, хотя цель еще не до конца понятна. Во втором — сначала проясняем задачу, а уже потом выбираем решение. Так меньше риск потратить время на работу, которая не закрывает настоящую потребность.

Не проверяем, был ли похожий опыт в команде

❌ «Как правильно настроить X?» 

✔️ «Кто-нибудь в команде уже настраивал X или сталкивался с похожей задачей?»

Документация и самостоятельный поиск полезны, но иногда быстрее сначала проверить, был ли похожий опыт внутри команды. Возможно, кто-то уже сталкивался с такой задачей, знает внутренние договоренности, помнит ограничения или может подсказать, где не стоит терять время.

Не даем контекста

❌ «У меня ошибка, можете помочь?»

✔️ «Получаю ошибку X при действии Y. Уже проверил A и B, но проблема осталась. Вот лог / скрин / ссылка. Подскажите, где еще посмотреть?»

Вопрос без контекста заставляет собеседника сначала разбираться в исходных данных: что произошло, где именно, после каких действий и что уже пробовали. Чем понятнее вводные, тем быстрее человек сможет перейти к сути и предложить решение.

Просим оценку, когда нужна обратная связь

❌ «Правильно ли я сделал?»

✔️ «Что можно улучшить в этом решении? Есть ли риски, которые я не учел?»

Вопрос «правильно ли?» часто сводит ответ к короткому «да» или «нет». Но в работе важны нюансы: возможные риски, альтернативы, слабые места. Если сразу попросить не оценку, а обратную связь, обсуждение получится полезнее.

Не задаем фокус для ответа

❌ «Что думаешь?»

✔️ «Посмотри, пожалуйста, логику: понятно ли, какую проблему решаем и почему предлагаем именно такое решение?»

«Что думаешь?» кажется удобным вопросом на все случаи, но в нем слишком много свободы для ответа. Собеседник может оценить формулировки, логику, детали реализации, сроки и при этом не попасть в то, что действительно важно. Когда фокус задан сразу, обратная связь получается точнее.

Самая сложная загадка уровня Hard и розыгрыш приза

Вам нравится разгадывать сложные загадки, нам — загадывать их и отправлять мерч победителям. Так чего же мы ждём?

Для тех, кто только к нам присоединился, пару слов об агентство «Найт Стрит». Мы пришли на Хабр, чтобы рассказать об игровой платформе PLAYFORMA, которую сделали сами, ничего не понимая ни в IT, ни в разработке. Подробно и интересно рассказываем здесь:
1. Отказались от идеального решения, чтобы всё начало работать: мы сделали игровую платформу без опыта в разработке
2. Мы сделали игровую платформу без опыта в разработке. Рассказываем, как она устроена

А теперь погнали решать Hard-загадку!

Из всех предыдущих загадок серьёзные затруднения вызвала только одна. Поэтому в этот раз к загадке не будет ни условий, ни подсказок. Скажем только, что формат ответа — топоним.

А теперь внимание на изображение. Всё, что нужно для правильного ответа, вы увидите на мониторе огурчика Пиклза.

Автор первого правильного ответа получит брендированный дождевик от агентства «Найт Стрит». Доставим по России за наш счёт.

У каждого пользователя есть только одна попытка дать правильный ответ. Если до понедельника загадку не разгадают, условие снимается, и каждый пользователь сможет предлагать неограниченное количество вариантов ответа.

Победители предыдущих розыгрышей не могут претендовать на приз. Ребята, дайте шанс другим!

Потренироваться и решить предыдущие загадки можно здесь:
Загадка № 1 «Тайное послание Nokia 3310»
Загадка № 2 «Скрытое послание таскдеска»
Загадка № 3 «Электрификация»
Загадка № 4 «Автомобильные номера»
Загадка № 5 «Путешествие по миру»

Вебинар «Как использовать ИИ на разных этапах разработки»

16 июля в 19:00 проидет гостевая встреча МФТИ и компании «Астон» о применении ИИ в разработке ИТ-продуктов.

На встрече разберем:

▪️ Как использовать ИИ для анализа исходной задачи, структурирования требований, подготовки вопросов к заказчику и создания черновика технического задания.

▪️ Как применять ИИ при проектировании архитектуры: выбирать компоненты, описывать взаимодействие сервисов, сравнивать варианты решений и находить риски.

▪️ Как инструменты Codex, Claude Code, Cursor и MCP-подходы помогают в разработке: написании кода, разборе кодовой базы, рефакторинге и поиске ошибок.

▪️ Как использовать ИИ в тестировании: подготовке тест-кейсов, генерации автотестов, анализе логов и проверке поведения системы.

▪️ Как ИИ-ассистенты помогают в DevOps — работе с Docker, Kubernetes, CI/CD, мониторинге и развертывании решений.

▪️ Какие навыки нужны начинающим специалистам и как развиваться в AI/ML-направлении. Кроме того, обсудим проекты компании «Астон» и карьерные возможности для студентов и начинающих специалистов.

Спикер— Алексей Сикора, ML-инженер, разработчик ИИ-агентов и аналитик данных в компании «Астон». Алексей имеет опыт работы в Big Tech и телеком-компаниях, развивает внедрение ИИ-решений, участвовал в создании ML-пайплайнов и аналитических платформ.

📅 16 июля (четверг), 19:00 (Мск)

💻 Онлайн

Регистрация:

Telegram: https://t.me/mipt_events_bot?start=dl-1783585994735

ВКонтакте: https://vk.com/app6379730_-224205661#l=27&auto=1

На Бирже заказов Инфостарта опубликована новая подборка задач для 1С-специалистов. За неделю появились проекты по УТ, УНФ, БП, ЗУП, обменам между базами, XML-выгрузкам, печатным формам и интеграциям с внешними сервисами.

Среди новых заказов:

• Базовая настройка, интеграции и небольшие доработки для торговой компании

• Настроить регулярный обмен из отдельных ЗУП ПРОФ/КОРП в общую ЗУП

• Платная консультация по отображению доступных остатков товаров в подборе номенклатуры в УТ 11

• Нужен консультант-аналитик 1С для сопровождения системы в ОПЭ

• Обработка для выгрузки отчета «Ведомость по НДС предъявленному» в формате XML

• Нужен программист или консультант со знанием модуля «Бит Финанс»

• Ведущий аналитик 1С:ЗУП 3.1 КОРП для проекта с интеграциями ЗУП-SAP и миграцией данных

• Доработка решения по исправлению ошибок в документах «Корректировка реализации» и «Возврат товаров от покупателя»

• Выгрузка номенклатуры из 1С 9.2 (7.7) в каталог Saby

• Внедрение 1С:УНФ в производственной компании

• Доработка расчета наценки и установки цен в УНФ 3.0

• Бесплатная консультация по интеграции 1С с сервисом «Яндекс Еда»

• Исправление критической ошибки при обновлении базы 1С:УПО 3.0

• Печатные формы для заказа на производство в 1С:УНФ Фреш

Биржа заказов Инфостарта это площадка для задач по 1С: от точечных консультаций и небольших доработок до внедрений, интеграций, разработки отчетов и сопровождения корпоративных систем.

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

AI-first компании как новый карго-культ

Допустим, некий предприниматель придумал идею бизнеса, сформулировал ценность. Чтобы воплотить её в реальном мире, он идёт на «рынок» готовых форм: ищет людей уже существующих профессий, собирает оргструктуру из известных вариантов (или нанимает CEO, который соберёт её за него), нанимает консультантов с их фреймворками, покупает CRM, ERP и прочие коробки, которые неявно предлагают свои шаблоны бизнес-процессов. Он пытается выбрать формы, лучше всего воплощающие его идею, но идеально подходящих не существует, хотя бы потому, что всё, что есть, создавалось не для него. Готовая форма всегда искажает замысел. Частный случай этой проблемы, закон Конвея: архитектура производимого продукта наследует структуру организации, то есть форма, взятая извне, начинает диктовать содержание.

Появившиеся LLM-агенты меняют эту ситуацию: теперь проектировать форму под себя стало в разы проще. Опыт тысяч компаний, который раньше был доступен только намертво запечатанным в готовые стандарты, процессы, продукты и профессии, теперь существует в пластичном виде, его можно переплавить под свой замысел, создав собственную онтологию бизнеса, которая не обязана быть прямо завязана на существующие рамки профессий, общепринятые стандарты разделения труда. Теперь роли, процессы и инструменты могут выводиться прямо из замысла демиурга бизнеса.

Само по себе использование LLM не цель, а только способ освободить время на мышление о том, как уменьшить зависимость от готовых решений с «рынка форм». Поэтому и говорить стоило бы не об AI-first, а об intent-first компаниях. Попытка же просто положить слой LLM поверх существующих процессов на первом этапе, как любая автоматизация, даст выигрыш, но в дальнейшем приведёт лишь к цементированию существующей системы разделения труда со всеми её недостатками. А хуже того, под слоем LLM окажется и задача артикуляции ценности бизнеса, а она по определению неалгоритмизируема, а следовательно автоматизации не подлежит. Это не страшно монополиям и живущим на ренте, но смертельно для всех остальных бизнесов.

Регулярно пишу в Телеграм-канале Chief Philosophy Officer  и VK группе о философии бизнеса

Подборка вебинаров на июль

Вы просили — мы сделали. Повторяем вебинары про работу с данными в облаке: от развертывания платформы до ETL-процессов и полноценной BI-аналитики. Регистрируйтесь, чтобы спросить экспертов о важных деталях и получить ответ.

Как развернуть платформу данных в облаке и подготовить данные для аналитики
Покажем, как быстро развернуть managed-сервисы Evolution Data Platform, подключить источники данных и построить пайплайны для подготовки данных к аналитике. Разберем интеграцию с PostgreSQL, ADB, S3 и настройку автоматического обновления — без долгого погружения в инфраструктуру.
🧑‍💻 Для кого: дата-инженеры, аналитики, архитекторы данных.
📅 Когда: 16 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

ETL в облаке: от хаоса к управляемым процессам
Покажем, как выстроить надежную ETL-платформу в облаке на базе Evolution Data Platform. Разберем интеграцию разрозненных источников, управление метаданными и оркестрацию — и покажем всё это в live-демо: от извлечения данных до готовой витрины.
🧑‍💻 Для кого: дата-инженеры, DevOps, руководители дата-команд.
📅 Когда: 23 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Evolution Managed BI: все возможности BI-сервиса в облаке
Разберем, как получить максимум от Evolution Managed BI: подключить источники данных, настроить интерактивные дашборды, кеширование запросов и автоматические алерты. Покажем продвинутые возможности сервиса — от виртуальных датасетов до управления доступом.
🧑‍💻 Для кого: аналитики, BI-разработчики, руководители дата-отделов.
📅 Когда: 30 июля 11:00 мск.
📍 Где: Онлайн. Зарегистрируйтесь, чтобы задать вопросы спикерам.

Как сделать первые шаги в программировании и вайбкодинге

Эта подборка поможет разобраться, что такое вайбкодинг и с чего начать, если вы только знакомитесь с разработкой. Рассказываем, чем вайбкодинг отличается от классического программирования, какие знания нужны для старта, какие инструменты выбрать и как формулировать запросы к нейросети, чтобы получать рабочий код.

Вайб-кодинг vs классическое программирование: что выбрать в 2026 году. Разбираем, чем различаются два подхода к разработке, где нейросети действительно ускоряют работу, а где без классических навыков не обойтись. Сравниваем плюсы и минусы каждого варианта и отвечаем на вопрос, можно ли заменить обучение программированию вайб-кодингом.

Как начать вайб-кодить с нуля: пошаговое руководство для новичков. Рассказываем, какие знания пригодятся для старта, как выбрать первый ИИ-инструмент и сформулировать задачу. Делимся пошаговым планом создания первого проекта и разбираем частые ошибки новичков.

Можно ли вайб-кодить без знания JavaScript, Python и HTML. Разбираем, что реально можно сделать без опыта программирования, а что всё равно потребует базовых знаний. Рассказываем про риски слепого доверия нейросети и о минимальной базе, которая поможет вайб-кодить эффективнее.

Лучшие инструменты для вайб-кодинга: Cursor, Copilot, ChatGPT, Claude и другие. Сравниваем популярные ИИ-инструменты для разработки и рассказываем, какие задачи каждый решает лучше всего. Даём советы, как выбрать подходящий вариант новичку.

Как писать промпты для генерации кода: примеры запросов к ИИ. Объясняем, из чего состоит хороший запрос к нейросети и как описывать задачу, контекст и ограничения. Показываем примеры удачных и неудачных промптов и разбираем частые ошибки при их написании.

Все статьи написаны простым языком и подойдут абсолютным новичкам. Также про вайбкодинг можно узнать из вводной части курса по вайбкодингу в Практикуме — это бесплатно, карту привязывать не нужно. Если понравится, можно продолжить обучение уже на основном курсе.