Представлен открытый проект TUI Studio (Visual Terminal UI Designer), среды для визуального проектирования интерфейсов пользователя, работающих в текстовом терминале. Среда позволяет в интерактивном режиме наглядно формировать интерфейс, перетаскивая готовые блоки мышью, редактируя свойства в визуальном режиме и предпросматривая результат на лету. Сформированный макет интерфейса может быть экспортирован для использования во фреймворках Ink, BubbleTea, Blessed, Textual, OpenTUI и Tview.
Решение написано на TypeScript с использованием React, Vite, Zustand, Tailwind CSS и Lucide React. Код распространяется под лицензией MIT. Из особенностей разработки отмечается, что почти весь код TUI Studio написан ИИ‑ассистентом Claude.
В TUI Studio предоставляется более 20 готовых компонентов для формирования интерфейса (кнопки, меню, таблицы, списки, индикатор прогресса, диалоги, всплывающие подсказки и тому подобное) и поддерживается 8 тем оформления, а также светлый и тёмный режим, градиентные заливки, ASCII‑цвета и акцентные цвета. Имеется возможность отката изменений. Доступен интерфейс для создания своих компонентов. Проекты сохраняются в формате JSON.
«Оки» в переписке снижает тревожность у собеседника, выяснили в НИУ ВШЭ. Использование уменьшительной формы активирует у собеседника нейронные связи, связанные с безопасностью и комфортом. В цифровой среде, где отсутствуют мимика и интонация, уменьшительные формы сигнализируют о дружелюбии и отсутствии злых намерений у собеседника.
Если собеседник ответит вам «оки», у вас сразу активируются нейронные связи, связанные с безопасностью и комфортом. И наоборот. Разгадка простая: милые уменьшительные формы как бы говорят: «всё хорошо, ты в безопасности». Обычное «ок» сегодня воспринимается слишком холодно и агрессивно.
Теперь включён по умолчанию. Миллион токенов — это примерно 750 000 слов или несколько крупных кодовых баз целиком. На практике это означает, что агент дольше «помнит» контекст задачи без деградации качества на длинных сеансах.
Для большинства задач разница с предыдущими лимитами несущественна. Но если вы работаете с большими монорепозиториями или длинными аналитическими сессиями — почувствуете.
Три фичи, которые стоит знать
/btw — вопросы на ходу
Агент работает час, вы не прерываете его — просто пишете /btw что такое этот класс?. Он отвечает из копии контекста, основной поток не трогает. Работает через кеш — почти бесплатно.
Почему это важно
Раньше, если в середине часового сеанса агента нужно было что-то уточнить, вы открывали новый сеанс, пересоздавали весь контекст — и платили за это токены. Теперь Claude Code создаёт одноразовый снимок текущего состояния, отвечает на ваш вопрос и удаляет снимок. Основной агент ничего не знает и продолжает работу.
/loop — цикл до условия
Запускает команду повторно, пока не выполнится условие. Например: «запускай тесты и фикси ошибки, пока все не пройдут». Без вашего участия.
Agent Teams — параллельные агенты
Несколько агентов работают одновременно и общаются друг с другом. Один пишет код, другой ревьюит, третий пишет тесты. Реально полезно, когда задача не имеет чёткого финального состояния.
Практически: спросили «почему здесь используется этот паттерн», получили ответ, не потеряли прогресс.
Когда это реально нужно?
Агенты буквально пишут сообщения друг другу: делятся находками, оспаривают решения. Это не маркетинговая метафора — в логах видно переписку.
Хорошо работает на задачах, где нельзя заранее точно сформулировать условия выполнения. Например: «сделай этот модуль надёжным» — агент по архитектуре, агент по тестированию и агент по документации работают параллельно и синхронизируются.
Куда это всё движется
Claude Code последовательно поглощает функциональность внешних инструментов. Сначала взял на себя управление контекстом, потом — параллелизацию. Сейчас добавляет циклическое выполнение и внутренние коммуникации между агентами.
У меня ощущение, что через год-два это будет единственный инструмент, который нужен для большинства задач разработки. Или конкуренты успеют ответить — посмотрим. А вы что думаете?
Если материал был полезен, проголосуйте пожалуйста, чтобы дать мне возможность писать полноценные гайды и статьи :)
Неудобные вопросы про бэкап PostgreSQL: открытый разбор на вебинаре
Вокруг бэкапа PostgreSQL легко создать иллюзию, что все уже решено. Достаточно добавить в текст WAL, PITR, пару слов про консистентность и назвать агент «умным». Проблема в том, что в проде такие формулировки мало что гарантируют.
Можно ли вообще считать решение PostgreSQL-aware, если оно не живет внутри логики самой СУБД? Где проходит граница между нативными механизмами PostgreSQL и внешней платформой? Что происходит, если не доехал WAL-сегмент, не завершился post-script или восстанавливать нужно не весь инстанс, а один объект?
Из таких вопросов и вырос отдельный вебинар про PostgreSQL в Акуре, в формате открытого инженерного разбора: что здесь должна делать сама СУБД, что имеет смысл выносить во внешний слой, где начинаются реальные эксплуатационные проблемы и какие ограничения в таком подходе нельзя замалчивать.
План такой:
отдельно пройтись по WAL, PITR и консистентности;
обсудить, где файловый агент уместен, а где уже нет;
разобрать сценарии с ошибками pre/post-скриптов;
поговорить про восстановление в безопасную локацию и ручной recovery;
отдельно затронуть вопрос масштаба: почему на двух базах хватает shell-скриптов, а на пятидесяти уже начинается совсем другая жизнь.
26 марта 2026, 11:00 (МСК) Регистрация по ссылке. Приносите в комментарии вопросы, которые особенно хочется поднять в эфире.
Хаотичное использование ИИ часто даёт обратный эффект: вместо экономии времени — поверхностные требования, некорректные формулировки и риск утечки данных. 17 марта на бесплатном вебинаре «ИИ в работе бизнес-аналитика: как ускориться, не потеряв качество» разберём, как встраивать нейросети в работу, сохраняя экспертизу и критическое мышление.
О чём поговорим:
✔️ Почему аналитики «тонут» в ИИ и теряют время ✔️ Где нейросети действительно усиливают: на этапах discovery, работы с требованиями, анализа процессов и коммуникации со стейкхолдерами ✔️ Как встроить ИИ в свой процесс, чтобы он помогал, а не мешал ✔️ Где проходят границы: риски и зоны, куда инструменты лучше не запускать
В результате сможете не просто использовать ИИ время от времени, а выстроить для себя понятный регламент — где он ускоряет, а где контроль остаётся за вами.
📅 Дата: 17 марта ⏰ Время: 16:00-17:00 (Мск) 👨🎓 Спикер: Татькова Дарья — специалист в области разработки ПО.
Совершать опечатки в публикациях стало престижно — ошибки в сообщениях стали символом статуса и надёжности, пишет Business Insider. Причина — ИИ‑бум. Из‑за него идеальные тексты кажутся нейрослопом и неуважением к собеседнику. Тексты с ошибками, с маленькой буквы и странной пунктуацией — наоборот, говорят о том, что с вами общается живой человек, заинтересованный в диалоге. Фишку уже активно используют многие топ‑менеджеры — они специально пишут неидеально, потому что слишком вылизанный текст ассоциируется с использованием ИИ.
На конференции SNUG Silicon Valley 2026 встретил давнего приятеля, китайского американца, который последние десять лет работал в компаниях, занимающихся чипами для аппаратного ускорения искуственного интеллекта. На позиции инженера по верификации: SystemVerilog тестбенчи, UVM итд. Его мнение про область:
В области training никто не превзойдет NVidia.
В области inference слишком много компаний. Скоро произойдет лопание пузыря, примерно как с доткомами в 2000–2001 годы, и большинство из них вымрет.
Но парочка останется, как и лидеры типа Amazon и Google после дот‑ком пузыря. Они будут отличаться от NVidia тем что дешевле.
Особенно несладко придет компаниям, которые метались между тем на что нужно ставить — CNN, LLM, трансформеры, датацентры, автомобили, edge computing.
Его на работе нагибают на использование ИИ при писании кода — ведут учет потраченных токенов например. Он этого не любит и спросил меня, как к этому относятся у меня на работе.
Я ему сказал — у нас начальство относится рационально: «если вы находите в этом пользу — ок, если нет — не парьтесь». Тем более что на наших задачах ИИ плохо работает — у меня собственно была на эту статья и постер на конференции.
Товарищ сказал: «ну хорошо, если меня уволят за неиспользование ИИ, буду стучаться к вам».
Есть светодиодная лампа, у неё конденсаторы на входе при включении заряжаются так, что любые контакты обгорают — в вилках, в выключателях… а потом, в устоявшемся режиме, жрёт миллиампер 30-40 всего-навсего.
Поставлю на автопубликацию, на начало вечера пятницы, ибо.
Давайте подумаем, можно ли на основе электрета создать SSD для архивного хранения? Допустим, при записи бита затвор сильно нагревается и электрет плавится, а заодно поляризуется. Можно, скажем, после этого урезать осетра и дать транзистору остыть, не теряя заряд. Или, если у нас какой‑нибудь преднамеренно заложенный тиристорный эффект — превратить все транзисторы в печки, сохраняющие свой заряд одновременно, а охладить превозмоганием — в кипящий фреон окунуть и всё, прошили (только‑только от него в дихлофосах избавились, и тут я, лол). Или для плавления нужен суровый внешний подогрев от отдельного питания +12, который потом отключается или вовсе сменяется охлаждением (это уже какой‑то прямо твердотельный CD‑RW). Или зарядить общей пластиной сверху, расплавив и дав на неё пару киловольт (а транзисторы при этом защищены от пробоя при помощи временного закидывания всех «органов» на ноль), а потом разряжать выборочно, загоняя транзисторы «в режим печки». Нашёл только какой‑то патент 2002 года, номер Ru2297051c2, но там как‑то уныло всё. В кучу кони, люди, «скруглённые углы»…
Ну или с другой стороны — мой любимый кварцевый диск. Допустим, какой‑нибудь шибко дипольный оксид не разлагается до 1500, но хорошо плавится уже при 900. Размешиваем в расплавленном кварце эмульсию нанокапель этого оксида, остужаем до 1000, поляризуем и остужаем дальше. Теперь, если лазером расплавить, поляризация уйдёт. Вопросов только два — как прочитать и что мешает использовать обычный редкоземельный чугуний, который точно так же можно туда вплавить и потом намагнитить остывший диск могучим полем примерно как у ЯМР‑томографа (он же — МРТ), а размагнитить — выборочно, нагревая лазером. Там хотя бы примерно понятно, как читать потом — мы же получили магнитооптический диск, только очень большой, толстый, многослойный и стирается исключительно на заводе.
Сейчас делаем пилот сразу для нескольких заказчиков. Рабочее название — «Суперраспознавалка» :))
Основная задача: настроить TAPe-модель на датасет типа COCO под задачу detection. Вторая — дать клиентам возможность добавлять собственные классы к уже существующим. Ну и далее, при необходимости, полная адаптация модели под конкретного заказчика. Поскольку у нас есть Теория активного восприятия с ее методами, на выходе заказчик должен получить кратную эффективность и кратную экономию ресурсов.
Задача интересная, поэтому буду вести дневник разработки, а потом подготовлю подробную статью.
Некоторые проекты — NDA, когда буквально нельзя указывать точное название объектов, которые нужно детектировать. Поэтому не обессудьте. Ноу‑хау по‑прежнему не собираемся раскрывать. Только результаты и часть пути к этим результатам.
День 1. TAPe и YOLO
Закончили с базовой структурой для сегментации, то есть с тем, как за один «ход» получать необходимый набор патчей, чтобы дальше расчёты шли параллельно (и оттуда же быстро), что также немного подводит ближе к самой логике действий здесь. Сейчас за одно действие получается определить все точно‑неинтересные места, а также все возможно‑интересные места (то есть, где есть детали в целом).
Что интересно сейчас в самом подходе — это то, что благодаря TAPe получается избежать проблемы других сегментационных моделей — а именно:
Необходимость классификации буквально каждого пикселя (как поступают стандартные современные модели семантической сегментации);
Стандартные модели буквально классифицируют каждый пиксель (или каждый N‑ный пиксель, если сжимают разрешение) на отношение к тому или иному классу.
Необходимость проверять каждый шаг в какой‑то ограниченной сетке размером N на N (так делает конкретно YOLO)
YOLO обходит это использованием сил CNN, классифицируя только конечное количество патчей (зависит от версии YOLO, в первой их было 6400, что всё равно много). Методы TAPe же нам позволяют этого не делать, потому что единицы информации в TAPe (которые мы назвали T‑bit) несут в себе гораздо больше информации, чем бит. В данном случае — несут в себе нужную структуру для нахождения похожести — а значит для нахождения сегментов, в которых нужно что‑то классифицировать в целом. И даже здесь благодаря TAPe у нас есть преимущество: мы можем проводить классификацию на условном нулевом уровне, не уходя в глубину.
Используя даже простую версию такого подхода, мы уже можем приходить к такой сегментации на простых примерах (разные цвета показывают разные сегменты). Лавочка — один сегмент, урна — другой, всё остальное — разные неровности, которые также можем буквально отфильтровать, если не хотим проводить их классификацию их. То есть — объект находится условно одномоментно.
В конце 2025 года SpaceWeb запустил площадку VPS в Нидерландах — и за первый квартал ресурсы разобрали полностью. Спрос оказался выше любых прогнозов, поэтому SpaceWeb удвоил серверные мощности на площадке и выстроил процессы масштабирования.
Серверы работают на базе AMD EPYC 7702, начальная конфигурация — 2 ядра CPU, 1 ГБ RAM, 15 ГБ NVMe — и расширяется под нужды проекта.
ai_query() в StarRocks 4.1: вызываем LLM прямо из SQL. Разбор результатов тестов.
Зачем это нужно аналитику и как вписывается в архитектуру, я описал в своем Telegram-канале Selena (powered by StarRocks). Здесь — технические детали и результаты тестирования.
Архитектура StarRocks 4.x: два направления интеграции с языковыми моделями
На схеме два потока данных между языковой моделью и базой данных:
Синий (вверху) — LLM → База через MCP (4.0). Пользователь задаёт вопрос на обычном языке. Агент сам формулирует SQL-запрос, отправляет его в StarRocks через MCP-протокол и возвращает ответ. Об этом я также подробно писал в нашем сообществе.
Зелёный (внизу) — База → LLM через ai_query() (4.1). Аналитик пишет SELECT с вызовом ai_query(). StarRocks на каждом сервере кластера отправляет запрос к языковой модели и возвращает её ответ как обычную текстовую колонку.
В версии 4.0 появилось первое направление, в 4.1 — второе. Полный цикл.
Что такое ai_query()
Функция принимает два аргумента: текстовый промпт и JSON с параметрами модели. Возвращает текстовую колонку — результат можно фильтровать, группировать и соединять с другими таблицами.
Обязательные параметры: model (название модели) и api_key (ключ доступа). Дополнительно можно указать адрес сервера модели, температуру, максимальную длину ответа и таймаут.
Функция работает с любым сервисом, совместимым с протоколом OpenAI: это и сам OpenAI, и локальные модели через Ollama, и DeepSeek, и vLLM.
Как тестировали:
Функция планируется к релизу в версии 4.1. Когда пришло время её проверить, привычный способ — развернуть готовый образ в Docker — не сработал. В образе обнаружился небольшой баг: функция была скомпилирована и лежала внутри сервера, но сервер о ней не знал. Исправление заняло одну строку в исходном коде. Но чтобы её применить, пришлось собирать BE из исходников.
Среда тестирования: виртуальная машина (8 CPU, 32 ГБ RAM), StarRocks 4.1.0-rc01 (собранный из исходников), языковая модель Ollama gemma3:1b (работает локально на процессоре). Тестовые данные — шесть отзывов о товарах.
Тест 1. Анализ тональности
Задача: определить, позитивный отзыв или негативный.
(SQL код по каждому тестированию я напишу в комментариях)
Вывод: четыре из шести точных.
Модель на один миллиард параметров делает бинарную классификацию — не различает нейтральные отзывы. Я, кстати, попробовал и с большими параметрами и с меньшим квантованием, насколько смог выдержать мой сервер, результат локальных моделей в этой задаче не очень.
Время: ~три секунды на шесть строк.
Не тот объем данных, чтобы экстраполировать на большие продакшн системы, но я тестировал не производительность, а работоспособность.
Тест 2. Суммаризация
Задача: сжать отзыв в одно предложение. Вывод: адекватные резюме на русском языке. Длину ответа стоит контролировать параметром max_tokens. Время: ~одна секунда на строку.
Тест 3. Извлечение характеристик
Задача: вытащить из текста ключевые свойства товара. Вывод: характеристики извлекаются Время: ~1 секунда на строку.
Тест 4. Классификация
Задача: определить категорию товара по тексту отзыва. Вывод: категории определены верно. MacBook, монитор, наушники — «Электроника», мышь — «Периферия». Время: ~0.5 секунды на строку.
Тест 5. Перевод
Задача: перевести отзыв с русского на английский. Вывод: качественный перевод даже на модели в один миллиард параметров. Время: ~1 секунда на строку.
Ограничения:
Нельзя задать роль модели (нет системного промпта) — только сообщение от пользователя
Нет повторных попыток при ошибке — если сервис модели вернул ошибку, это сразу ошибка SQL-запроса
Кеш хранится на каждом сервере отдельно и теряется при перезапуске
Итого:
ai_query() — простая обёртка над протоколом языковых моделей с кешем и дедупликацией. Не революция, но именно такие простые интеграции оказываются самыми полезными.
Антарктическую площадку на Беллинсгаузене ставим на паузу до доп. согласований
Запуск площадки RUVDS в Антарктиде задерживается — мы вынуждены временно остановить работу оборудования на станции Беллинсгаузен.
Перенос сроков не связан ни с «железом», ни с каналом связи. Сервер, питание, связь/сеть — всё это было и остаётся рабочим. Вопрос в организационном моменте.
Что случилось:
Оборудование несколько месяцев «гонялось» в тестовом режиме (стабильность, связь, удалённое администрирование, «а что если…» сценарии в условиях станции).
Только после того, как тесты показали, что решение можно эксплуатировать, мы открыли публичный доступ и дали всем желающим возможность попробовать VM в Антарктиде.
Уже после запуска открытой эксплуатации мы получили предписание: для дальнейшей работы требуется дополнительное согласование со стороны регулирующих структур, отдельно — по вопросам потенциального воздействия нашего проекта на окружающую среду.
Варианта «просто продолжать как было» у нас нет: площадку нужно остановить до завершения согласований и отдельного уведомления о возможности возобновления эксплуатации.
Что это значит для пользователей, которые успели взять VM:
VM на этой площадке будут оставаться недоступными до тех пор, пока весь процесс согласований не завершится.
Всем, кто оформлял антарктический VM, мы отправим отдельное уведомление с дальнейшими вариантами (например, перенос/компенсация/опции касательно данных — в зависимости от сценария и того, что технически успеем корректно осуществить).
Приносим искренние извинения за смещение сроков: понимаем, что многие пришли именно за «сервером в Антарктиде», и нам самим досадно сворачивать публичную часть проекта в момент, когда она уже заработала. Но выполнение всех требований площадки и регуляторов — это приоритет. Мы хотим быть на все 100% уверены в соблюдении всех процедур, чтобы предоставить вам тот уровень сервиса, который вы привыкли получать.
Будем информировать вас о поступлении новых сведений по статусу проекта: обновим пост и напишем отдельно.
Ориентироваться по звёздам можно даже в центре столицы, если знать самые яркие навигационные ориентиры – Большой ковш и Малую медведицу. Об этом Агентству городских новостей «Москва» рассказали в пресс-службе Московского физико-технического института (МФТИ).
«Ночью главным компасом служит Полярная звезда, которая всегда указывает на север. Вопреки стереотипу, эта звезда далеко не самая яркая на нашем небе, и ее сложно увидеть невооруженным глазом в условиях городской засветки. Зато хорошо виден известный астеризм из семи ярких звезд – Большой ковш (часть Большой медведицы). Мысленно проведите линию через две крайние звезды – «стенки» ковша (Дубхе и Мерак) – и продолжите ее вверх на пять таких же отрезков. Тогда вы упрётесь в тусклую звезду в Малой медведице. Это и есть Полярная звезда. Таким образом, даже если сама цель не видна, направление на север будет найдено точно», – рассказали в пресс-службе.
Собеседник агентства отметил, что днем и в сумеречное время можно ориентироваться на Солнце.
«Ориентация на Солнце – самый простой и надёжный способ понять, где находится какая сторона света. Оно встаёт на востоке и садится на западе. В полдень в летний период Солнце указывает приблизительное направление на юг, а зимой – на север», – добавили в пресс-службе МФТИ.
PostgreSQL в Docker: запуск, настройка, типичные ошибки
Устанавливать PostgreSQL напрямую в систему — значит разбираться с зависимостями, версиями и мусором, который остается после удаления. В контейнере база поднимается за секунды, одинаково работает на любой машине в команде и легко пересоздается под новый проект.
В новой статье на сайте Рег.облака разобрали полный путь: от установки Docker на Ubuntu 24.04 до работы с томами, своим postgresql.conf и настройки локали. Отдельно собрали типичные ошибки и объяснили, как их чинить.
ИИ — помощник, или враг разработчика? Мысли на тему. Часть 2
Сейчас время нейросетей. Не надо излишне обольщаться на тему их возможностей — они владеют (по крайней мере пока), только той информацией, которая использовалась при обучении, плюс, имеют возможность «подглядывать» в поиск и различные внешние источники с помощью MCP-серверов. Всё.
Но даже это снова очень серьёзный рывок вперёд. Вместо необходимости искать и анализировать информацию из нескольких источников мы сразу получаем готовое решение. Да, ещё с погрешностями и необходимостью ручных правок и проверок, но это уже качественно другой уровень разработки.
Вместо ручного написания алгоритмов или их комбинирования из готовых частей на первое место выходит навык промптинга — умения сформулировать свой запрос в виде, достаточно полном и понятном для нейросети.
Меняется ли что-то для разработчиков? Безусловно. Снова. Нам снова надо менять свой подход к разработке. Так же, как мы меняли его 30 лет назад, 20, 10... И будем менять опять ещё лет через 10. Это естественный процесс.
Надо ли забывать синтаксис и особенности низкоуровневой разработки? Нет. Как минимум, ещё несколько лет необходимо будет выверять за LLM код так же, как мы выверяем его за новичками. Но, давайте будем честными, машинные коды и Ассемблер многие уже забыли, а то и не знали. А создавать программы им это не мешает. Так же как сейчас есть специалисты, активно использующие машинные коды и Ассемблер в работе.
Рынок не схлопнется. К нему добавится ещё один слой. Кто-то из разработчиков будет и дальше по старому писать код в областях, новых для ИИ, где у него нет наработанной «базы ответов». А кто-то переключится на написание промптов, в разы повысив скорость решения прикладных задач.
5 бесплатных уроков марта для мобильных разработчиков
12 марта 20:00 >>Профессиональные модульные тесты в Android: как тесты улучшают код Открытый вебинар курса «Android-разработчик. Продвинутый уровень» Урок о том, как писать в Android осмысленные модульные тесты для ViewModel, репозиториев и бизнес-логики, чтобы они не маскировали проблемы, а реально улучшали архитектуру и поддержку кода. Записаться на урок
18 марта 20:00 >> Пишем простой проигрыватель на SwiftUI Открытый вебинар курса «IOS-разработчик» Соберете на SwiftUI простой медиапроигрыватель с интерактивным интерфейсом, освоите работу с локальными аудио- и видеофайлами в iOS и наметите путь к интеграции внешних сервисов. Записаться на урок
19 марта 20:00 >> Современная архитектура приложения и внедрение зависимостей Открытый вебинар курса «Android-разработчик. Продвинутый уровень» Разберемся, как выстроить Android-приложение на основе чистой архитектуры, связать слои через MVVM и настроить внедрение зависимостей с помощью Koin без лишней магии. Записаться на урок
23 марта 20:00 >> Навигация Pro-уровня в SwiftUI: как строить масштабируемые iOS-приложения без хаоса в переходах Открытый вебинар курса «IOS-разработчик. Продвинутый уровень» Как в SwiftUI проектировать навигацию без архитектурного хаоса: отделять переходы от интерфейса, управлять deep link и модальными экранами, строить масштабируемую структуру приложения. Записаться на урок
25 марта 20:00 >> Как писать Flutter-код так, чтобы ИИ правильно его дописывал Открытый вебинар курса «Flutter-разработчик» Поймете, почему искусственный интеллект ошибается при генерации Flutter-кода, и освоите приёмы, которые улучшат подсказки, повысят читаемость проекта и ускорят дальнейшую разработку. Записаться на урок
Еще больше бесплатных уроков от преподавателей курсов по всем ИТ-направлениям можно посмотреть в календаре мероприятий.
ИИ — помощник или враг разработчика? Мысли на тему. Часть 1
Привет, это снова Саша Кузнецов, ведущий инженер-программист в Контуре. 🙌
Я из тех «ископаемых», которые начинали программировать ещё во времена, когда в качестве IDE выступал обычный текстовый редактор, а для хранения информации о синтаксисе команд использовались собственные записи в тетради. Я в то время учился в школе и на уроках учитель давала нам информацию о синтаксисе команд с распечаток. Если в тетради была ошибка — ты делал ошибку в коде и не мог понять, что идёт не так. Роль интернета играла городская библиотека (в местной книг про IT практически не было), «пинг» до которой был несколько часов только на дорогу, а ещё — скорость работы «поисковой системы» по бумажным книгам оставляла желать лучшего.
Потом я поступил в университет и «произошла магия» — там были IDE с подсветкой синтаксиса команд, подсказками, появляющимися по нажатию F1, и более-менее вменяемыми сообщениями об ошибках.
Это было круто! Просто зная название команды можно было получить описание её синтаксиса, а не хранить в голове информацию обо всех возможных комбинациях! Реальный прирост производительности сейчас по памяти сложно замерить, но скорость непосредственно набора команд выросла в разы. С решением задач в целом ситуация улучшилась не сильно — основным источником информации оставались бумажные книги. Разве что «пинг» существенно сократился — читальный зал находился в том же корпусе, в котором шли занятия. По сути, в момент этого скачка необходимость знания точного синтаксиса команд заменилась на необходимость знать только название команды.
Потом магия произошла снова — на кафедре появился интернет и что-то похожее на поиск. Это был ещё далеко не современный интернет с мощными поисковыми системами, но и совсем древние его версии я не застал. Но, главное, уже можно было найти информацию за рамками того, что было включено в поиск разработчиками IDE, или лежало в читальном зале. Речь шла уже не о синтаксисе команд, а о способах решения задач. Но не всегда. Это было время, когда в интернете ещё надо было суметь найти готовый код для редких видов сортировки массива, а за написание алгоритма БПФ (Быстрого Преобразования Фурье) заказчики на фрилансерских форумах были готовы выложить $500. И, тем не менее, это снова был качественный скачок — можно было быстро найти информацию по конкретной проблеме, не перекапывая кучу книг, в которых, возможно, могло быть «что-то близкое по теме». Скорость решения задач снова выросла, и снова значительно. Всё больше и больше задач стало переходить в категорию шаблонных. На этом этапе на первое место начал выходить навык «гугления». Основы синтаксиса остались необходимой базой, но умение правильно забить вопрос в поисковую строку стал определять очень и очень многое.
Новый скачок произошёл с развитием разработческих форумов по типу Stack Overflow. С момента их основания огромное число пользователей задавало вопросы и получало на них ответы. Можно было не просто что-то найти, но дать описание проблемы и получить решение, часто с примерами рабочего кода. А ещё к этому моменту существенно выросли как возможности поисковых систем, так и объём проиндексированной информации в них. Плюс, достаточно много книг перевели в цифровой формат. В результате стало возможным указывать не конкретное название нужного алгоритма или ключевые слова, а давать описание проблемы и получать подборку страниц с нужными ответами. В том числе на Stack Overflow и другие похожие форумы.
Теперь можно было нормально искать решение более-менее широко известных проблем по их примерному описанию и сразу получать примеры рабочего кода. Существенный рывок, значительно сокративший время на простые, рутинные задачи, и, одновременно, подаривший куче студентов возможность гуглить практически готовые лабораторные работы.
Фактически, именно в этот момент программирование стало общедоступным. А на первое место вышел навык комбинирования — умения собрать решение из похожих кусков кода, найденных в интернете.
В одном проекте я изучал касдевы (глубинные интервью) с клиентами компании. Результаты получились любопытные. Около 70% покупателей сказали, что для них важен внешний вид продукта, и только 55% отметили цену как ключевой фактор. Казалось бы, ничего необычного — люди любят красивое. Но есть нюанс: речь идёт о B2B-рынке, о товарах для бизнеса.
То есть решение принимают предприниматели, менеджеры, руководители. Люди, которые вроде бы должны мыслить рационально: считать экономику, сравнивать характеристики, выбирать по цене и срокам. Но даже здесь визуальное восприятие продукта оказывается важнее стоимости.
На первый взгляд это может выглядеть странно. Но на самом деле это очень логично. Бизнес — это не абстрактная машина, которая принимает решения по формуле. Решения всё равно принимают люди. И у людей работают те же когнитивные механики, что и в обычной жизни.
Именно поэтому брендинг в B2B сильно недооценён. Многие компании уверены, что «у нас же бизнес-клиенты, им не до красоты». Поэтому сайты делают по принципу «лишь бы был», каталоги выглядят как техническая документация, а визуальная часть коммуникации воспринимается как второстепенная. Главное — цена, характеристики и сроки.
Но реальность работает немного иначе. Когда потенциальный клиент заходит на сайт, смотрит каталог или листает карточки товаров, он за доли секунды формирует ощущение о компании. Насколько она современная, аккуратная, профессиональная. И очень часто это ощущение возникает не из текста и цифр, а из визуальной целостности бренда.
Здесь включается простая когнитивная эвристика, которой люди пользуются постоянно: «красивая компания = качественный продукт». Если бренд выглядит аккуратно, продуманно и эстетично, мозг автоматически достраивает картину: значит, и продукт сделан так же внимательно. Если же всё выглядит хаотично и устаревше, появляется обратное ощущение — даже если сам продукт объективно хороший.
Поэтому в B2B красота — это не украшение. Это один из факторов доверия. И иногда именно он тихо, без лишнего шума, повышает конверсию сильнее, чем очередное снижение цены.
![Изображение дерева [Электронный ресурс] / Сгенерировано нейросетью Алиса. — 2026. — Дата генерации: 13.03.2026.](https://habrastorage.org/r/w1560/getpro/habr/upload_files/619/7d8/5ca/6197d85ca3a980826da09a1f1f027c61.jpeg "Изображение дерева [Электронный ресурс] / Сгенерировано нейросетью Алиса. — 2026. — Дата генерации: 13.03.2026.")
