Это внутренняя BI-система, разработанная индивидуально под задачи клиента. В графическом интерфейсе можно формировать простые витрины и создавать визуализации. SQL нужен только на этапе подготовки сложных витрин — когда требуются сложные расчетные метрики. Хороший пример — неаддитивные метрики вроде DAU/MAU: их нельзя получить простым суммированием дневных значений, потому что один и тот же пользователь посчитается несколько раз. В таких случаях аналитик пишет один раз кастомный SQL и фиксирует логику в семантическом слое. Дальше SQL знать уже не нужно: семантический слой собирает запросы по параметрам поверх этой готовой логики.
Цель любой автоматизации — предоставить более быстрое, качественное и выгодное решение бизнес-задачи. Мы искренне считаем, что в решении подобных задач ИИ является следующим шагом после “классической автоматизации”. Только выполнив все шаги “классической автоматизации”, можно получить надежное и безопасное решение на основе ИИ.
Что касается “фасада в виде MCP” — это не совсем так. Агент решает недетерминированные задачи: самостоятельно изучает структуру датасетов, выбирает нужные данные и строит визуализации/дает инсайты по данным. MCP здесь используется в целях интеграции с другими ИИ-клиентами и по некоторым инфраструктурным соображениям.
По-хорошему разработка архитектуры в любом случае нужна. А на чем можно сэкономить и делегировать аишке, чтобы потом не дорабатывать LLM clean up инженером - уже под вопросом. Мы пришли к выводу, что чем больше "похожесть" решения целевого стека с исходным, тем проще, например, контроллеры nestjs отлично перегоняются через аишку в контроллеры спринга.
В первом случае код достаточно абстрактен, и поскольку действительно нет типов в js, то тут или уточнять промпт или руками править.
по второму - абстрактный код был взят для примера, но, так и быть, давайте пофантазируем, возможно, при получении обьектов из корзины они вычищаются, или, может быть, при создании заказа на событии ОРМ.
На собеседовании мы стараемся подобрать человека, у которого был бы достаточный опыт и знания, чтобы справляться с текущими задачами и проектами, требующими разработчика. Чаще всего нужны крепкие миддлы, которые возьмут на себя поддержку и разработку проектов. Реже мы ищем сеньоров — для решения вопросов архитектуры, выбора технологий и улучшения процессов. Иногда мы берём джуниоров «на вырост», если на собеседовании становится понятно, что у человека, несмотря на пробелы в знаниях, есть потенциал.
В переписывании легаси-кода нет ничего плохого: мы сами переписали и улучшили множество проектов, которые переходили к нам на поддержку. Но если кандидат с порога начинает ругать существующий код и пытаться всё переписать, игнорируя озвученные сроки и мешая рабочим процессам, то, скорее всего, эффективное сотрудничество не сложится. К сожалению, у нас уже были случаи, когда в такой ситуации приходилось расставаться.
Что касается напористости и экспертизы — мы, безусловно, приветствуем высокий уровень знаний и вовлечённость. Однако в силу нашей специфики команда не может состоять только из лидов и сеньоров. Кто-то должен терпеливо выполнять и рутинную работу — и это тоже очень ценно.
Речь не про доверительное общение, а про базовое уважение к тому, в чью команду вы планируете идти работать, только и всего. Да, конечно список субъективный — в самом начале статьи написано, что он основан на опыте)
Это внутренняя BI-система, разработанная индивидуально под задачи клиента. В графическом интерфейсе можно формировать простые витрины и создавать визуализации. SQL нужен только на этапе подготовки сложных витрин — когда требуются сложные расчетные метрики. Хороший пример — неаддитивные метрики вроде DAU/MAU: их нельзя получить простым суммированием дневных значений, потому что один и тот же пользователь посчитается несколько раз. В таких случаях аналитик пишет один раз кастомный SQL и фиксирует логику в семантическом слое. Дальше SQL знать уже не нужно: семантический слой собирает запросы по параметрам поверх этой готовой логики.
Цель любой автоматизации — предоставить более быстрое, качественное и выгодное решение бизнес-задачи. Мы искренне считаем, что в решении подобных задач ИИ является следующим шагом после “классической автоматизации”. Только выполнив все шаги “классической автоматизации”, можно получить надежное и безопасное решение на основе ИИ.
Что касается “фасада в виде MCP” — это не совсем так. Агент решает недетерминированные задачи: самостоятельно изучает структуру датасетов, выбирает нужные данные и строит визуализации/дает инсайты по данным. MCP здесь используется в целях интеграции с другими ИИ-клиентами и по некоторым инфраструктурным соображениям.
По-хорошему разработка архитектуры в любом случае нужна. А на чем можно сэкономить и делегировать аишке, чтобы потом не дорабатывать LLM clean up инженером - уже под вопросом. Мы пришли к выводу, что чем больше "похожесть" решения целевого стека с исходным, тем проще, например, контроллеры nestjs отлично перегоняются через аишку в контроллеры спринга.
В первом случае код достаточно абстрактен, и поскольку действительно нет типов в js, то тут или уточнять промпт или руками править.
по второму - абстрактный код был взят для примера, но, так и быть, давайте пофантазируем, возможно, при получении обьектов из корзины они вычищаются, или, может быть, при создании заказа на событии ОРМ.
На собеседовании мы стараемся подобрать человека, у которого был бы достаточный опыт и знания, чтобы справляться с текущими задачами и проектами, требующими разработчика. Чаще всего нужны крепкие миддлы, которые возьмут на себя поддержку и разработку проектов. Реже мы ищем сеньоров — для решения вопросов архитектуры, выбора технологий и улучшения процессов. Иногда мы берём джуниоров «на вырост», если на собеседовании становится понятно, что у человека, несмотря на пробелы в знаниях, есть потенциал.
В переписывании легаси-кода нет ничего плохого: мы сами переписали и улучшили множество проектов, которые переходили к нам на поддержку. Но если кандидат с порога начинает ругать существующий код и пытаться всё переписать, игнорируя озвученные сроки и мешая рабочим процессам, то, скорее всего, эффективное сотрудничество не сложится. К сожалению, у нас уже были случаи, когда в такой ситуации приходилось расставаться.
Что касается напористости и экспертизы — мы, безусловно, приветствуем высокий уровень знаний и вовлечённость. Однако в силу нашей специфики команда не может состоять только из лидов и сеньоров. Кто-то должен терпеливо выполнять и рутинную работу — и это тоже очень ценно.
Речь не про доверительное общение, а про базовое уважение к тому, в чью команду вы планируете идти работать, только и всего. Да, конечно список субъективный — в самом начале статьи написано, что он основан на опыте)
Мы работаем в заказной разработке, у нее есть особенности в плане процессов.
Для нас важно, чтобы человек изначально понимал, что ему предстоит работа над проектами, а не развитие продукта.