Нейросети ещё не стали обязательным требованием у работодателей, но многие дата-сайентисты уже активно используют LLM: генерируют код в Cursor, пишут SQL-запросы в DataGrip и обращаются за советом к ChatGPT.

Генерация и сопровождение кода

Одно из самых популярных применений ИИ — работа с кодом: автодополнение, генерация фрагментов, объяснение логики, рефакторинг и создание тестов. Нейросеть может объяснить непонятный участок кода, перевести его на другой язык, продолжить строку или сгенерировать docstring.

Мой основной инструмент — GigaCode, ассистент на базе GigaChat. Он похож на GitHub Copilot: помогает дописывать код и ускорять рутину. Однако Copilot глубже интегрируется в IDE, а GigaCode требует отдельной настройки.

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

При работе с SQL полезны как универсальные ассистенты, так и специализированные решения. Например, DataGrip помогает генерировать и оптимизировать запросы, анализировать execution plan и рефакторить код. Однако важно понимать логику построения запроса — ИИ часто пропускает важные детали.

Написание документации

ИИ эффективно генерирует тексты: создаёт README, docstrings и краткие сводки переписок или требований от заказчика — удобно для прикрепления к тикетам в CRM.

Создание тест-кейсов

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

Написание простых сервисов

Современные LLM — ChatGPT, Claude, GigaChat, Qwen Chat, DeepSeek — подходят для прототипирования простых сервисов. Особенно полезны, если у дата-сайентиста недостаточно практического опыта в разработке.

Использование агентов

Агентные пайплайны позволяют LLM не просто отвечать, а выбирать действия, вызывать инструменты и передавать результат дальше. Такие системы часто строятся с помощью LangChain и LangGraph и превращаются в специализированных ИИ-ассистентов.

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

Не учитывают весь контекст

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

Предлагают нестандартные решения (не всегда лучшие)

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

Например, Copilot однажды предложил использовать else после цикла в Python. Конструкция технически верна, но редко используется и плохо читается — в продакшене её обычно избегают.

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

Выдают ошибки

Частая проблема — код работает, но логически неверен. ИИ может ошибиться в условии if, неправильно обработать API-ответ или вызвать неожиданное исключение.

Иногда модель фокусируется на части задачи, игнорируя общие условия. Например, добивается высокой метрики, но допускает target leakage — дублирование таргета в признаках. На тестах всё выглядит хорошо, но на проде модель мгновенно падает.

Вольно обращаются с источниками

В Data Science критично использовать достоверные данные. Однако ИИ может ссылаться на нерепрезентативные или недостоверные источники — например, выдавать фрагмент интернет-статьи как общий вывод исследования.

Копят недочёты

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

Декомпозировать задачи

Чем проще запрос, тем точнее отвечает ИИ. Многоэтапные задачи повышают риск ошибок. Лучше разбивать их на мелкие, однозначные шаги.

Челленджить ИИ в работе с данными

Не стоит принимать выводы ИИ на веру. Полезно задавать вопросы: Почему ты так думаешь? Откуда это взято? Зачем это нужно?

Математические и статистические методы проверки результатов по-прежнему необходимы — от них нельзя отказываться.

Проверять результаты одной LLM с помощью другой

Разные модели могут по-разному оценить один и тот же код. Использование второй LLM помогает избежать эффекта «стажёра», который считает, что раз код работает — значит, всё в порядке.

Валидировать результат вручную

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

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

Даже если LLM в 70% случаев работает корректно, это не гарантирует, что она не ошибётся в критичный момент. Пока ручная валидация обязательна.

Проверять воспроизводимость результата в чистом окружении

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

ИИ особенно подвержен этой проблеме — без чётких инструкций он может сгенерировать непереносимое решение.

Задавать ограничения

Ключевой навык — не только писать хорошие промпты, но и ограничивать результат. Например, в LangChain можно использовать системный промпт с дополнительным «мини-промптом», повышающим точность ответа.

• создаётся промпт и параметры,
• они отправляются в LLM,
• результат обрабатывается парсером, задающим фиксированную структуру.

Это делает ответы стабильнее. Альтернатива — with_structured_output() в LangChain, где схема результата описывается заранее (через Pydantic или JSON Schema). Тогда модель возвращает не текст, а структурированный объект — это снижает ошибки и упрощает интеграцию в код.

Почему джунам лучше выполнять задачи самостоятельно

Пока нет вакансий, где использование ИИ — обязательное требование. Это полезный навык, но войти в Data Science можно и без него.

ИИ может замедлить обучение джунов. Представим двух начинающих специалистов:

• Первый изучает документацию, ищет решения на Stack Overflow, консультируется с мидлом. Через неделю сдаёт рабочий и частично проверенный код.
• Второй использует ИИ и сдаёт задачу за два дня. Но код не соответствует ТЗ, а сам джун плохо понимает, что написал. Задачу приходится переделывать — итоговый срок оказывается больше.

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

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

Нейросети ещё не стали обязательным пунктом в требованиях работодателей, но на практике многие дата-сайентисты уже используют LLM в работе: генерируют код в Cursor, пишут SQL-запросы в DataGrip и спрашивают совета у ChatGPT.

Хабр, привет! Меня зовут Вячеслав Демин, я больше пяти лет работаю в сфере Data Science. Сейчас я руководитель направления аналитики данных в Сбере и эксперт на курсе«Специалист по Data Science»в Яндекс Практикуме. Начинал с этого же курса в 2020 году, после чего работал в сфере страхования и нефтехимии.

В этом материале я расскажу, для каких задач в Data Science использую ИИ и почему полагаться на него на 100% всё ещё не стоит.

Для каких задач в Data Science используют нейросети

Генерация и сопровождение кода

Самое популярное направление применения ИИ в разработке — работа с кодом: автодополнение, генерация фрагментов, объяснение логики, рефакторинг и генерация тестов. Нейросеть легко объяснит работу непонятной секции кода, переведёт фрагмент с одного языка на другой, продолжит начатую строку или построит за разработчика docstring — описание функции, класса или элемента.

Мой главный инструмент для этих задач — GigaCode, ассистент для написания кода на базе GigaChat. По пользовательскому сценарию он близок к GitHub Copilot: помогает дописывать код, объяснять фрагменты и ускорять рутинные действия. Разница в том, что Copilot обычно глубже встраивается в привычный IDE-стек через расширения, а GigaCode требует отдельного подключения и настройки.

Есть приложения, такие как Cursor, в которых можно настраивать промпты для написания кода. Это полноценная среда, где можно задавать инструкции и контекст для генерации кода (например, описывать стиль, требования или задачу). Такие инструменты работают с контекстом проекта — анализируют открытые файлы и релевантные части кода. Теоретически можно даже дать им задачу на рефакторинг всего проекта, хотя на практике такой запрос потребует поэтапного контроля и ревью.

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

Для SQL-задач можно использовать как универсальные ИИ-ассистенты, так и специализированные инструменты. Например, DataGrip удобен для работы с запросами, рефакторинга и анализа плана выполнения, а платформы вроде Microsoft Fabric дополняют работу ИИ-функциями на уровне аналитической среды. Мне особенно нравится DataGrip с его возможностями рефакторинга запросов, то есть оптимизации уже написанного кода. А ещё он позволяет посмотреть execution plan и понять, как СУБД будет выполнять запрос, без дополнительных запросов и ручной проверки.

Написание документации

ИИ отлично проявляет себя в работе с текстами. Например, генерирует базовые файлы для проекта — README и docstrings для всех функций.

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

Создание тест-кейсов

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

Написание простых сервисов

Современные LLM, такие как ChatGPT, Claude, Алиса AI, GigaChat, Qwen Chat или DeepSeek, подходят для быстрых решений небольших задач, например прототипирования простых сервисов. Особенно полезно, если знания дата-сайентиста в этой области теоретические и ему недостаёт практики.

Использование агентов

Отдельный класс решений — агентные пайплайны, в которых LLM не просто отвечает на запрос, а выбирает следующий шаг, вызывает инструменты и передаёт результат дальше по цепочке. Чаще всего их создают с нуля с помощью LangChain и LangGraph — получаются готовые ИИ-ассистенты под любую задачу.

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

Почему нейросетям нельзя доверять на 100%

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

Не учитывают весь контекст

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

Предлагают нестандартные решения (не всегда лучшие)

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

Пример из моего опыта: однажды в фрагменте кода на Python Copilot предложил мне результат с условиемelseна выход из цикла. Такая конструкция технически корректна, но используется редко и часто плохо читается, поэтому в продакшен-коде её обычно избегают.

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

Выдают ошибки

Частая проблема: код вроде бы работает, но логически неверен.

При генерации на Python ИИ может неправильно проставить условие в строчкуif, добавить что-то лишнее, некорректно считать список свойств из другого сервиса через API или вызвать исключение, которого не было в инструкции.

Другой вариант: когда ИИ фокусируется на конкретной части запроса, игнорируя прочие условия задачи. Допустим, твоя метрика — 0,7, а нужно, чтобы была 0,95. Нейросеть выдаёт все 0,98, но на деле ломает код: в одном из признаков дублирует таргет (target leakage), из-за чего всё работает на тестах, но на раз-два заваливается на проде.

Вольно обращаются с источниками

Если мы говорим о Data Science, нейросети допускают ещё одну непростительную для нас ошибку — могут ссылаться на недостоверные или нерепрезентативные источники, используя данные без подтверждения статзначимости или научного объяснения. Например, в ответ на общий запрос «расскажи мне об исследованиях в этой области» модель может выдать тебе за общие выводы информацию из маленького абзаца в материале. Причём материалом может быть даже не исследование, а просто статья в интернете.

Копят недочёты

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

Как работать с нейросетями без потери качества результата

Чтобы избежать типовых ловушек в работе с ИИ, важно соблюдать несколько полезных привычек.

Декомпозировать задачи

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

Челленджить ИИ в работе с данными

Проверяя статистику и выводы ИИ, не стоит принимать его ответы на веру. Лучше обратить его внимание на неочевидные моменты и спросить: почему ты так думаешь? Зачем это нужно? А откуда ты это взял?

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

Проверять результаты работы одной LLM с помощью другой

При работе с кодом логично использовать разные модели. LLM может быть менее критична к решениям, построенным по знакомым ей паттернам. Чтобы избавиться от эффекта стажёра («я постарался, и теперь код работает, а значит, всё хорошо»), логично обращаться к другой модели, чтобы она оценила работу более критично.

Валидировать результат вручную

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

Кроме того, разработчик должен в любом случае понимать значение каждой строчки сгенерированного кода. Допустим, результат выглядит и работает корректно, но что если в нём используются специфические библиотеки или функции, которые не заработают на другой машине? А если он просто не оптимален?

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

Проверять воспроизводимость результата в чистом окружении

Любой код нужно проверять на нескольких устройствах. Обычно мы отправляем проект через Git — в GitHub, GitLab, Bitbucket и другие сервисы. Если в проекте нет requirements, тестов или другой конфигурации, которая позволяет воспроизвести окружение на другом устройстве, это почти гарантированно приведёт к проблемам. В таком случае код может не запуститься на соседнем ноутбуке.

Особенно это критично при работе с ИИ: без чётких инструкций и настроек он может сгенерировать решение, которое невозможно корректно воспроизвести в другой среде.

Задавать ограничения

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

Например, в LangChain есть удобный формализованный подход. Ты задаёшь системный промпт и можешь дополнить его «мини-промптом», который повышает вероятность корректного ответа.

Как это обычно устроено:

• создаётся промпт и параметры,
• всё это отправляется в LLM,
• на выходе результат обрабатывает парсер.

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

Альтернативный способ получить предсказуемый ответ — использовать встроенный структурный вывод в LangChain черезwith_structured_output(). В этом подходе мы не просто просим модель «ответить в JSON», а заранее описываем ожидаемую схему результата — например, через Pydantic-модель или JSON Schema. После этого LangChain оборачивает вызов модели так, чтобы на выходе мы получали не произвольный текст, а объект с заранее известными полями и типами. Это снижает количество ошибок парсинга, упрощает последующую обработку результата в коде и делает поведение LLM стабильнее в продакшен-сценариях.

Почему джунам лучше выполнять задачи самостоятельно

Я пока не видел ни одной вакансии, где знание и использование ИИ было бы обязательным требованием. Это точно полезный навык, но попасть в Data Science можно и без него.

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

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

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

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

Резюмирую: Copilot и другие инструменты ускоряют работу, но не заменяют мышление. ИИ — это помощник, которому нужно поручать простые задачи, внимательно направлять и проверять результаты. И помнить: ответственность за результат работы LLM всегда остаётся на человеке.

P.S. А теперь скажите, где тут настоящий скриншот :-)