Имена IT-инструментов почти всегда оказываются чьей-то шуткой, отсылкой или опечаткой.
Часто они зарождаются через причудливые казусы или оказываются чей-то ошибкой.
➡️ Листай карусель, чтобы узнать как появились названия, которые ты произносишь каждый рабочий день.
Часто они зарождаются через причудливые казусы или оказываются чей-то ошибкой.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥3❤1💩1
Шутки шутками, но в реальном AI-продукте этот вопрос очень быстро перестаёт быть мемом.
В продакшене начинаются взрослые развлечения:
— модель уверенно врёт, но очень убедительно;
— RAG почему-то достаёт не те документы;
— агент делает 7 лишних вызовов туда, куда не просили;
— бюджет на токены улетает в стратосферу;
— бизнес спрашивает: “а сколько стоит один запрос?”;
— а вы такие: “смотря какой agent…”
И вот именно поэтому AI-агентов нужно проектировать инженерно.
Не через вайб “напиши мне промпт, брат”, а через нормальную архитектуру: логику агента, базу знаний, RAG, метрики качества, логи, трассировку и расчёт экономики.
На курсе «Разработка и проектирование AI-агентов на базе LLM» разбираем, как делать инженерно: с архитектурой, базой знаний, метриками качества, логами, трассировкой и расчётом экономики.
Первый поток уже оценил модули на 10/10 💗
А начать можно через бесплатное демо: первые 7 уроков, формат тренажёра, доступ к LLM, создание проекта, Git и базовая конфигурация агента.
В продакшене начинаются взрослые развлечения:
— модель уверенно врёт, но очень убедительно;
— RAG почему-то достаёт не те документы;
— агент делает 7 лишних вызовов туда, куда не просили;
— бюджет на токены улетает в стратосферу;
— бизнес спрашивает: “а сколько стоит один запрос?”;
— а вы такие: “смотря какой agent…”
И вот именно поэтому AI-агентов нужно проектировать инженерно.
Не через вайб “напиши мне промпт, брат”, а через нормальную архитектуру: логику агента, базу знаний, RAG, метрики качества, логи, трассировку и расчёт экономики.
На курсе «Разработка и проектирование AI-агентов на базе LLM» разбираем, как делать инженерно: с архитектурой, базой знаний, метриками качества, логами, трассировкой и расчётом экономики.
Первый поток уже оценил модули на 10/10 💗
А начать можно через бесплатное демо: первые 7 уроков, формат тренажёра, доступ к LLM, создание проекта, Git и базовая конфигурация агента.
😁3🔥2
ИнженеркаТех - это не завод курсов.
Мы не хотели делать обучение в формате: «вот вам пачка лекций, дальше как-нибудь сами». Нам хотелось собрать пространство, где взрослый занятый специалист может учиться без гонки в жестком графике, а как ему самому удобно: после работы, ночью, в выходные, быстро, медленно, рывками — как получается.
🤖 Как появился Ду-Ду?
Но важный момент: Ду-Ду не пишет наши курсы вместо людей.
Контент в ИнженеркеТех создают реальные авторы-практики: инженеры, тестировщики, аналитики, разработчики, тимлиды — люди с живым опытом, рабочими кейсами и пониманием, как всё устроено не в сферическом вакууме, а в реальном проекте.
Даже этот пост пишет реальный человек, а вот картинки мы сгенерировали, но по авторскому ТЗ 😁
Наш Ду-Ду обучен на базе знаний конкретного курса, который создаёт преподаватель. Он не подменяет автора, не генерирует обучение «из воздуха» и не превращает курс в AI-слоп.
Он помогает студенту лучше усваивать авторский материал: объясняет сложные темы проще, разбирает задачи, подсказывает, где искать ошибку, и поддерживает в моменты, когда ты сидишь перед экраном и думаешь: «ну всё, я всё сломал».
Для нас это и есть нормальный формат: не просто доступ к материалам, а живой продукт с практикой, обновлениями, поддержкой, симуляторами, понятными объяснениями и инструментами, которые помогают дойти до результата. А Ду-Ду — часть этой системы. Не автор вместо человека. А напарник, который помогает учиться на человеческом авторском контенте.
Этим постом мы запускаем рубрику «ИнженеркаТех изнутри».
Будем рассказывать, как у нас рождаются курсы, зачем нужны нулевые группы, как мы выбираем авторов-практиков, почему в ядре команды всего 5 человек и как за красивой карточкой курса иногда прячется маленький ночной аврал.
Заглядывай в демо-доступы и посмотри, как всё устроено.
Если вам интересен такой лайф-формат про нашу внутреннюю кухню — ставьте сердечко или огонёк ❤️🔥🔥
Мы не хотели делать обучение в формате: «вот вам пачка лекций, дальше как-нибудь сами». Нам хотелось собрать пространство, где взрослый занятый специалист может учиться без гонки в жестком графике, а как ему самому удобно: после работы, ночью, в выходные, быстро, медленно, рывками — как получается.
Он появился у нас ещё 2 года назад - когда AI-агенты в обучении не были привычной историей, а слово «агент» ещё не пытались приклеить к каждому второму сервису. Мы придумали его не для того, чтобы заменить преподавателя или автора. А потому что люди учатся по-разному.
Кто-то садится за задачи вечером после работы. Кто-то — в выходные. Кто-то открывает тренажёр в 02:47, когда живой преподаватель имеет полное человеческое право спать.
А вопрос всё равно есть.
Ошибка в коде всё равно бесит.
И хочется не ждать утра, а разобраться сейчас — не оставаясь один на один с проблемой.
Так появился Ду-Ду.
А имя пришло из французской традиции: у многих детей есть игрушка-проводник, которую называют doudou. Нам понравилась эта идея — маленький спутник, который рядом, когда нужно чуть больше уверенности.
Но важный момент: Ду-Ду не пишет наши курсы вместо людей.
Контент в ИнженеркеТех создают реальные авторы-практики: инженеры, тестировщики, аналитики, разработчики, тимлиды — люди с живым опытом, рабочими кейсами и пониманием, как всё устроено не в сферическом вакууме, а в реальном проекте.
Даже этот пост пишет реальный человек, а вот картинки мы сгенерировали, но по авторскому ТЗ 😁
Наш Ду-Ду обучен на базе знаний конкретного курса, который создаёт преподаватель. Он не подменяет автора, не генерирует обучение «из воздуха» и не превращает курс в AI-слоп.
Он помогает студенту лучше усваивать авторский материал: объясняет сложные темы проще, разбирает задачи, подсказывает, где искать ошибку, и поддерживает в моменты, когда ты сидишь перед экраном и думаешь: «ну всё, я всё сломал».
Для нас это и есть нормальный формат: не просто доступ к материалам, а живой продукт с практикой, обновлениями, поддержкой, симуляторами, понятными объяснениями и инструментами, которые помогают дойти до результата. А Ду-Ду — часть этой системы. Не автор вместо человека. А напарник, который помогает учиться на человеческом авторском контенте.
Этим постом мы запускаем рубрику «ИнженеркаТех изнутри».
Будем рассказывать, как у нас рождаются курсы, зачем нужны нулевые группы, как мы выбираем авторов-практиков, почему в ядре команды всего 5 человек и как за красивой карточкой курса иногда прячется маленький ночной аврал.
Заглядывай в демо-доступы и посмотри, как всё устроено.
Если вам интересен такой лайф-формат про нашу внутреннюю кухню — ставьте сердечко или огонёк ❤️🔥🔥
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
❤🔥5🔥4💩1
🤩Расписание ИнженеркаТех Плюс на июнь!
В этом месяце оба воркшопа ведёт Павел Балаханов, Tech Lead QA в VK Cloud.
👉3 июня в 19.00 по мск. Ревью автотестов с помощью ИИ: поиск слабых мест, антипаттернов и рисков сопровождения.
Когда тестов уже сотни, глаз цепляет не всё. Разберём, где ИИ реально помогает на ревью, а где подсказывает уверенную чушь.
👉24 июня в 19.00 по мск. Тестирование нестабильности, галлюцинаций и рискованных сценариев в ИИ.
Как тестировать систему, у которой ответ каждый раз чуть-чуть другой. Поговорим про воспроизводимость, ловлю галлюцинаций, регрессии в промптах и сценарии.
Доступ открыт всем нашим студентам, ссылки появятся в личном кабинете в плейлисте июня.
В этом месяце оба воркшопа ведёт Павел Балаханов, Tech Lead QA в VK Cloud.
👉3 июня в 19.00 по мск. Ревью автотестов с помощью ИИ: поиск слабых мест, антипаттернов и рисков сопровождения.
Когда тестов уже сотни, глаз цепляет не всё. Разберём, где ИИ реально помогает на ревью, а где подсказывает уверенную чушь.
👉24 июня в 19.00 по мск. Тестирование нестабильности, галлюцинаций и рискованных сценариев в ИИ.
Как тестировать систему, у которой ответ каждый раз чуть-чуть другой. Поговорим про воспроизводимость, ловлю галлюцинаций, регрессии в промптах и сценарии.
Доступ открыт всем нашим студентам, ссылки появятся в личном кабинете в плейлисте июня.
🔥2
Media is too big
VIEW IN TELEGRAM
Куда катится Modern Data Stack?
В ролике Павел Рословец, Principle Data Engineer NXP Semiconductors рассказывает про свой опыт обновления Dagster и причем тут агрессивная коммерциализация opensource.
Согласны? Голосуйте через эмодзи: 🔥 - да, 👻 - нет.
В ролике Павел Рословец, Principle Data Engineer NXP Semiconductors рассказывает про свой опыт обновления Dagster и причем тут агрессивная коммерциализация opensource.
Согласны? Голосуйте через эмодзи: 🔥 - да, 👻 - нет.
🤷♀4🔥3👻1
Уже завтра (3 июня в 19.00 по мск) вебинар с Павлом Балахановым, Tech Lead QA в VK Cloud.
👉Ревью автотестов с помощью ИИ: поиск слабых мест, антипаттернов и рисков сопровождения.
Вебинар доступен студентам ИнженеркаТех в личном кабинете.
Хотите присоединиться к июньским ивентам и иметь доступ к прошлым плейлистам и задачнику? Сделать это можно тут
👉Ревью автотестов с помощью ИИ: поиск слабых мест, антипаттернов и рисков сопровождения.
Вебинар доступен студентам ИнженеркаТех в личном кабинете.
Хотите присоединиться к июньским ивентам и иметь доступ к прошлым плейлистам и задачнику? Сделать это можно тут
🔥2
Media is too big
VIEW IN TELEGRAM
Паша Балахонов напоминает, что сегодня, 3 июня в 19.00 по мск, закрытый вебинар для наших студентов по теме "Ревью автотестов с помощью ИИ: поиск слабых мест, антипаттернов и рисков сопровождения."
Ссылка, чтобы присоединиться, доступна в личном кабинете:)
Ссылка, чтобы присоединиться, доступна в личном кабинете:)
🔥2
В 1961 году в MIT стоял один компьютер на весь институт, а за ним по очереди работали десятки исследователей. Так могла начаться любая из наших историй, которые мы рассказываем в проекте Legacy (короткие ролики про историю IT). Только вот штука, придуманная в 61-м, до сих пор с нами, и потихоньку превращается в атавизм.
Мы сделали серию о том, как индустрия дошла от первого пароля до passkey. Первая часть уже на канале, заходите смотреть 👇
В следующих частях расскажем про первую утечку, первый хеш и массового червя. И при чём тут Uber.
Мы сделали серию о том, как индустрия дошла от первого пароля до passkey. Первая часть уже на канале, заходите смотреть 👇
В следующих частях расскажем про первую утечку, первый хеш и массового червя. И при чём тут Uber.
🔥3❤🔥1
DuckLake
Чтобы поправить одну строку в parquet, обычно приходится переписывать файл целиком. В 2026 году это всё ещё повседневность большинства озёр данных: сам по себе parquet не умеет ни UPDATE, ни ROLLBACK, а пайплайн, упавший на середине записи, может оставить в озере недописанные файлы и несогласованное состояние.
Поэтому появились Iceberg и Delta Lake. Они добавляют поверх parquet транзакционный слой, но за это платишь: метаданные размазаны по множеству служебных файлов на S3, и в эксплуатации часто появляется ещё и отдельный каталог, за которым нужно следить.
Команда DuckDB предложила другой путь и выпустила DuckLake. Данные так и лежат в parquet, а все метаданные живут в обычной реляционной базе, хоть в SQLite, хоть в PostgreSQL. Подключается всё одной командой ATTACH:
Каждая закоммиченная транзакция создаёт снапшот, поэтому из коробки получаешь UPDATE, MERGE, ACID и time travel. Даже после DELETE без WHERE данные возвращаются одним запросом к прошлой версии таблицы:
Вместо номера версии можно указать время, AT (TIMESTAMP => '2026-03-24 23:08:34'), DuckLake сам найдёт подходящий снапшот.
Формат молодой, первая стабильная версия вышла весной 2026, и в крупных продакшен-озёрах чаще выбирают более зрелый и широко поддерживаемый Iceberg. Но если пайплайн уже построен на DuckDB и parquet, DuckLake добавляет транзакции и версионирование почти без переделок.
Cпецификация и документация лежат на ducklake.select.
Чтобы поправить одну строку в parquet, обычно приходится переписывать файл целиком. В 2026 году это всё ещё повседневность большинства озёр данных: сам по себе parquet не умеет ни UPDATE, ни ROLLBACK, а пайплайн, упавший на середине записи, может оставить в озере недописанные файлы и несогласованное состояние.
Поэтому появились Iceberg и Delta Lake. Они добавляют поверх parquet транзакционный слой, но за это платишь: метаданные размазаны по множеству служебных файлов на S3, и в эксплуатации часто появляется ещё и отдельный каталог, за которым нужно следить.
Команда DuckDB предложила другой путь и выпустила DuckLake. Данные так и лежат в parquet, а все метаданные живут в обычной реляционной базе, хоть в SQLite, хоть в PostgreSQL. Подключается всё одной командой ATTACH:
INSTALL ducklake;
ATTACH 'ducklake:sqlite:metadata.sqlite' AS lake (DATA_PATH 'data/');
Каждая закоммиченная транзакция создаёт снапшот, поэтому из коробки получаешь UPDATE, MERGE, ACID и time travel. Даже после DELETE без WHERE данные возвращаются одним запросом к прошлой версии таблицы:
SELECT * FROM my_table AT (VERSION => 5);
Вместо номера версии можно указать время, AT (TIMESTAMP => '2026-03-24 23:08:34'), DuckLake сам найдёт подходящий снапшот.
Формат молодой, первая стабильная версия вышла весной 2026, и в крупных продакшен-озёрах чаще выбирают более зрелый и широко поддерживаемый Iceberg. Но если пайплайн уже построен на DuckDB и parquet, DuckLake добавляет транзакции и версионирование почти без переделок.
Cпецификация и документация лежат на ducklake.select.
❤🔥5🔥3
Всем привет! Выпустили вторую часть из нашей серии видео "От первого пароля до Passkey". В прошлой части мы рассказали, как и почему в 61 году придумали первый пароль. А в этой мы расскажем как произошла первая в мире утечка.
В следующих частях будет про первый хеш, массового червя и при чём тут Uber.
Заходите смотреть 👇
В следующих частях будет про первый хеш, массового червя и при чём тут Uber.
Заходите смотреть 👇
🔥4
Как наш первый факап привёл к появлению собственной IDE
Это новый выпуск рубрики «ИнженеркаТех изнутри» — здесь мы рассказываем не только о том, что у нас получилось, но и о решениях, которые сначала казались отличными, а потом оказались… не очень.
Почти два года назад мы начали делать первые тренажёры.
Тогда мы представляли их как интерактивные текстовые курсы: с персонажами, сюжетом, рабочими ситуациями и практическими заданиями. Не просто сухая лекция, а история, в которую студент постепенно погружается: знакомится с героями, получает задачи, принимает решения, где-то радуется, где-то переживает и идёт дальше по сценарию.
В голове всё выглядело очень живо. Мы написали тексты, собрали первый вариант, открыли его и поняли:
получилась какая-то ерунда на палке
Ну хорошо, скажем мягче — всё выглядело очень постно, но прикольно. Так мы нащупали свой формат.
Да, там были персонажи. Да, были шутки, история и практические задания. Но по сути человек всё равно просто сидел и читал текст. А потом должен был уйти из страницы курса, отдельно развернуть окружение, открыть редактор, перенести туда код, установить зависимости, что-нибудь сломать и потратить половину вечера не на обучение, а на борьбу с настройками. И тогда стало понятно: одного хорошего текста недостаточно. Чтобы тренажёр действительно стал тренажёром, практика должна происходить прямо внутри него.
В одном окне.
Студент открывает платформу с компьютера, планшета или телефона, читает задачу, пишет код, запускает его, получает результат, видит ошибку и тут же пытается её исправить.
И вот в этот момент у нас наконец сложилась картинка продукта, который мы действительно хотели делать - учебная среда, где сюжет, теория, практика, проверка решения и помощь Ду-Ду находятся в одном месте.
Первый рабочий прототип появился при активной помощи AI еще почти 2 года назад. Тогда это позволяло быстро проверять идеи и не тратить недели на то, что могло вообще не прижиться. Но чем сложнее становилась наша первая IDE, тем очевиднее было: одного вайбкодинга недостаточно.
Когда в продукте появляются разные языки, проекты из нескольких файлов, запуск тестов, зависимости, изолированное окружение и десятки учебных сценариев, нужно понимать архитектуру. Иначе одна небольшая правка легко ломает то, что уже работало.
Пришлось глубоко погружаться в React, переписывать части системы вручную, продумывать интерфейс вместе с дизайнером и отдельно решать вопрос безопасного запуска кода.
Сейчас код в IDE выполняется в изолированном окружении на базе Judge0. Мы дорабатывали его под свои задачи: сначала для Playwright, затем добавляли другие сценарии, языки, запуск отдельных файлов и более сложных проектов.
Параллельно развивался и Ду-Ду. Теперь он может помогать не только с отдельным фрагментом кода, но и разбираться в структуре проекта, анализировать файлы и объяснять, где могла появиться ошибка.
Но самое важное — IDE развивается не вокруг технологий ради технологий. Мы смотрим, как студенты проходят задания, где застревают, чего им не хватает и что мешает сосредоточиться на практике. А потом докручиваем платформу под реальные сценарии обучения.
Главный вывод этой истории простой:
вайбкодинг — отличный способ быстро собрать прототип и проверить идею. Но чтобы превратить прототип в настоящий продукт, всё равно нужны инженерные знания, понимание архитектуры и готовность разбираться в нюансах.
AI помогает двигаться быстрее. Но инженерное мышление он не заменяет.
Это новый выпуск рубрики «ИнженеркаТех изнутри» — здесь мы рассказываем не только о том, что у нас получилось, но и о решениях, которые сначала казались отличными, а потом оказались… не очень.
Почти два года назад мы начали делать первые тренажёры.
Тогда мы представляли их как интерактивные текстовые курсы: с персонажами, сюжетом, рабочими ситуациями и практическими заданиями. Не просто сухая лекция, а история, в которую студент постепенно погружается: знакомится с героями, получает задачи, принимает решения, где-то радуется, где-то переживает и идёт дальше по сценарию.
В голове всё выглядело очень живо. Мы написали тексты, собрали первый вариант, открыли его и поняли:
получилась какая-то ерунда на палке
Ну хорошо, скажем мягче — всё выглядело очень постно, но прикольно. Так мы нащупали свой формат.
Да, там были персонажи. Да, были шутки, история и практические задания. Но по сути человек всё равно просто сидел и читал текст. А потом должен был уйти из страницы курса, отдельно развернуть окружение, открыть редактор, перенести туда код, установить зависимости, что-нибудь сломать и потратить половину вечера не на обучение, а на борьбу с настройками. И тогда стало понятно: одного хорошего текста недостаточно. Чтобы тренажёр действительно стал тренажёром, практика должна происходить прямо внутри него.
В одном окне.
Студент открывает платформу с компьютера, планшета или телефона, читает задачу, пишет код, запускает его, получает результат, видит ошибку и тут же пытается её исправить.
И вот в этот момент у нас наконец сложилась картинка продукта, который мы действительно хотели делать - учебная среда, где сюжет, теория, практика, проверка решения и помощь Ду-Ду находятся в одном месте.
Так появилась идея собственной IDE. Которую мы до сих пор бесконечно допиливаем нашими молитвами 🫠
Первый рабочий прототип появился при активной помощи AI еще почти 2 года назад. Тогда это позволяло быстро проверять идеи и не тратить недели на то, что могло вообще не прижиться. Но чем сложнее становилась наша первая IDE, тем очевиднее было: одного вайбкодинга недостаточно.
Когда в продукте появляются разные языки, проекты из нескольких файлов, запуск тестов, зависимости, изолированное окружение и десятки учебных сценариев, нужно понимать архитектуру. Иначе одна небольшая правка легко ломает то, что уже работало.
Пришлось глубоко погружаться в React, переписывать части системы вручную, продумывать интерфейс вместе с дизайнером и отдельно решать вопрос безопасного запуска кода.
Сейчас код в IDE выполняется в изолированном окружении на базе Judge0. Мы дорабатывали его под свои задачи: сначала для Playwright, затем добавляли другие сценарии, языки, запуск отдельных файлов и более сложных проектов.
Параллельно развивался и Ду-Ду. Теперь он может помогать не только с отдельным фрагментом кода, но и разбираться в структуре проекта, анализировать файлы и объяснять, где могла появиться ошибка.
Но самое важное — IDE развивается не вокруг технологий ради технологий. Мы смотрим, как студенты проходят задания, где застревают, чего им не хватает и что мешает сосредоточиться на практике. А потом докручиваем платформу под реальные сценарии обучения.
Главный вывод этой истории простой:
вайбкодинг — отличный способ быстро собрать прототип и проверить идею. Но чтобы превратить прототип в настоящий продукт, всё равно нужны инженерные знания, понимание архитектуры и готовность разбираться в нюансах.
AI помогает двигаться быстрее. Но инженерное мышление он не заменяет.
❤🔥6👏4🔥2