Как наш первый факап привёл к появлению собственной IDE
Это новый выпуск рубрики «ИнженеркаТех изнутри» — здесь мы рассказываем не только о том, что у нас получилось, но и о решениях, которые сначала казались отличными, а потом оказались… не очень.
Почти два года назад мы начали делать первые тренажёры.
Тогда мы представляли их как интерактивные текстовые курсы: с персонажами, сюжетом, рабочими ситуациями и практическими заданиями. Не просто сухая лекция, а история, в которую студент постепенно погружается: знакомится с героями, получает задачи, принимает решения, где-то радуется, где-то переживает и идёт дальше по сценарию.
В голове всё выглядело очень живо. Мы написали тексты, собрали первый вариант, открыли его и поняли:
получилась какая-то ерунда на палке
Ну хорошо, скажем мягче — всё выглядело очень постно, но прикольно. Так мы нащупали свой формат.
Да, там были персонажи. Да, были шутки, история и практические задания. Но по сути человек всё равно просто сидел и читал текст. А потом должен был уйти из страницы курса, отдельно развернуть окружение, открыть редактор, перенести туда код, установить зависимости, что-нибудь сломать и потратить половину вечера не на обучение, а на борьбу с настройками. И тогда стало понятно: одного хорошего текста недостаточно. Чтобы тренажёр действительно стал тренажёром, практика должна происходить прямо внутри него.
В одном окне.
Студент открывает платформу с компьютера, планшета или телефона, читает задачу, пишет код, запускает его, получает результат, видит ошибку и тут же пытается её исправить.
И вот в этот момент у нас наконец сложилась картинка продукта, который мы действительно хотели делать - учебная среда, где сюжет, теория, практика, проверка решения и помощь Ду-Ду находятся в одном месте.
Так появилась идея собственной IDE. Которую мы до сих пор бесконечно допиливаем нашими молитвами 🫠
Первый рабочий прототип появился при активной помощи AI еще почти 2 года назад. Тогда это позволяло быстро проверять идеи и не тратить недели на то, что могло вообще не прижиться. Но чем сложнее становилась наша первая IDE, тем очевиднее было: одного вайбкодинга недостаточно.
Когда в продукте появляются разные языки, проекты из нескольких файлов, запуск тестов, зависимости, изолированное окружение и десятки учебных сценариев, нужно понимать архитектуру. Иначе одна небольшая правка легко ломает то, что уже работало.
Пришлось глубоко погружаться в React, переписывать части системы вручную, продумывать интерфейс вместе с дизайнером и отдельно решать вопрос безопасного запуска кода.
Сейчас код в IDE выполняется в изолированном окружении на базе Judge0. Мы дорабатывали его под свои задачи: сначала для Playwright, затем добавляли другие сценарии, языки, запуск отдельных файлов и более сложных проектов.
Параллельно развивался и Ду-Ду. Теперь он может помогать не только с отдельным фрагментом кода, но и разбираться в структуре проекта, анализировать файлы и объяснять, где могла появиться ошибка.
Но самое важное — IDE развивается не вокруг технологий ради технологий. Мы смотрим, как студенты проходят задания, где застревают, чего им не хватает и что мешает сосредоточиться на практике. А потом докручиваем платформу под реальные сценарии обучения.
Главный вывод этой истории простой:
вайбкодинг — отличный способ быстро собрать прототип и проверить идею. Но чтобы превратить прототип в настоящий продукт, всё равно нужны инженерные знания, понимание архитектуры и готовность разбираться в нюансах.
AI помогает двигаться быстрее. Но инженерное мышление он не заменяет.
