25 вопросов AI-разработчику перед стартом проекта
Практический чек-лист для интервью с AI-разработчиком до договора
Readiness scoring, pass criteria, data checks, integration risk и ownership after launch
Как статья поддерживает broad landing page через long-tail procurement checklist intent
вопросы AI-разработчику перед наймом, AI vendor selection Armenia и production AI checklist
$ interview ai_developer --before-contract
> questions: 25
> score: outcome / data / integration / risk / ownership
> output: audit / prototype / production-readyНанимать AI-разработчика до ясного проекта рискованно: разговор быстро уходит в модели, инструменты и демо, хотя компания ещё не проверила workflow, данные, интеграции и границы риска.
Широкий commercial intent остаётся за страницей AI-специалист в Армении. Эта статья уже: она даёт практический чек-лист для команды, которая хочет поговорить с AI-разработчиком, AI-студией или подрядчиком до договора.
Когда использовать чек-лист
Используйте чек-лист перед платным discovery, прототипом, RAG-системой, AI-автоматизацией, AI-агентом, LLM workflow или внутренним AI-инструментом. Он полезен, когда бизнес-проблема понятна, но ещё не превращена в delivery brief.
Вопросы нужны не для красивого итогового балла. Они должны рано показать неизвестные:
- неясный business outcome;
- нет доступа к данным;
- скрыта работа по интеграциям;
- непонятно, как проверять качество;
- нет human review boundary;
- слабый ownership после запуска.
Если подрядчик не может спокойно обсудить эти темы, проект не готов к production commitment.
Критерии и шкала
Оцените каждый ответ от 0 до 3.
| Балл | Значение | Практическая трактовка |
|---|---|---|
| 0 | Неизвестно | Ответа нет или он спекулятивный |
| 1 | Частично | Тема понятна, но доказательств мало |
| 2 | Достаточно для старта | Ответ подходит для discovery или prototype |
| 3 | Production-ready | Есть owner, данные, проверки и failure handling |
Цель не в том, чтобы все вопросы получили 3. Первый аудит может начинаться с множества 1 и 2. Но production build не должен стартовать, если критические вопросы про данные, права, ошибки и ownership остаются на 0.
25 вопросов
| Область | Вопрос | Сигнал прохождения |
|---|---|---|
| Business outcome | 1. Какую бизнес-задачу или решение должна улучшить AI-система? | Назван workflow, а не просто feature |
| Business outcome | 2. Кто будет пользоваться результатом каждую неделю? | Названа реальная роль или команда |
| Business outcome | 3. Что будет считаться провалом внедрения? | Команда умеет назвать unacceptable errors |
| Business outcome | 4. Какой smallest useful release? | Scope меньше финального видения |
| Данные | 5. Какие документы, CRM-записи, сообщения, файлы или API нужны? | Видны источники и владельцы |
| Данные | 6. Кто имеет право доступа к этим данным? | Permissions заданы явно |
| Данные | 7. Как часто данные меняются? | Update path не игнорируется |
| Данные | 8. Какие данные нельзя отправлять в модель или сторонний API? | Названы sensitive fields |
| AI behavior | 9. Модель должна отвечать, классифицировать, писать draft, искать, маршрутизировать или запускать действия? | Поведение конкретное |
| AI behavior | 10. Нужен RAG, fine-tuning, rules, n8n или обычный код? | Подрядчик умеет сравнить варианты |
| AI behavior | 11. Какими examples проверять качество результата? | Есть evaluation examples |
| AI behavior | 12. Что происходит при низкой confidence? | Fallback определён |
| Интеграции | 13. Какие системы должны читать данные из AI-слоя? | Inputs mapped |
| Интеграции | 14. В какие системы AI-слой может писать? | Write permissions контролируются |
| Интеграции | 15. Webhooks, CRM fields, spreadsheets, queues или APIs уже описаны? | Integration contracts есть или запланированы |
| Интеграции | 16. Какие latency, rate limits или uptime constraints важны? | Operational constraints обсуждаются |
| Human review | 17. Какие решения требуют human approval? | Approval gates названы |
| Human review | 18. Кто проверяет drafts, exceptions и edge cases? | Review принадлежит роли |
| Human review | 19. Что логировать для audit и debugging? | Logs входят в design |
| Risk | 20. Главные privacy, security и compliance risks? | Есть risk register |
| Risk | 21. Как обрабатывать prompt injection, плохие source data или hallucination? | Failure modes конкретные |
| Risk | 22. Какой rollback или ручной процесс есть при сбое AI? | Manual fallback сохранён |
| Delivery | 23. Какие артефакты будут переданы кроме demo? | Названы repo, docs, tests и deployment notes |
| Delivery | 24. Кто владеет maintenance после запуска? | Ownership не размыт |
| Delivery | 25. Что нужно audit перед расширением scope? | Следующий review gate явный |
Как заполнить
Сначала пройдите чек-лист внутри команды. Затем используйте тот же файл на звонках с подрядчиками. Сильный AI-разработчик должен уточнять чек-лист, а не обходить его.
Для каждого вопроса запишите:
- текущий ответ;
- evidence или missing input;
- score от 0 до 3;
- owner;
- next action.
Так sales-разговор превращается в delivery-разговор. Команда меньше рискует принять polished prototype за production-ready систему.
Как интерпретировать результат
Суммарный балл даёт только грубый сигнал. Важнее распределение.
| Результат | Что это значит | Следующий шаг |
|---|---|---|
| Много 0 в business outcome | Команда не готова покупать разработку | Провести короткий AI-аудит |
| Много 0 в data и permissions | Проект может сломаться до проверки AI quality | Описать sources, access и privacy rules |
| Слабые integration answers | Demo может не соединиться с real operations | Сделать integration brief |
| Слабые evaluation answers | Качество будут обсуждать по впечатлениям | Собрать evaluation set |
| Слабые ownership answers | Система может остаться без сопровождения | Задать support, logs и handoff |
Для production AI проекта особенно важны вопросы 6, 8, 12, 14, 17, 19, 20, 21, 22 и 24. Они контролируют риски вокруг данных, write actions, failure handling и ownership.
Скачиваемый шаблон чек-листа
Используйте этот Markdown-чек-лист как оригинальный proof artifact.
| # | Вопрос | Текущий ответ | Балл 0-3 | Evidence | Owner | Next action |
|---|---|---|---|---|---|---|
| 1 | Какую бизнес-задачу или решение должна улучшить AI-система? | |||||
| 2 | Кто будет пользоваться результатом каждую неделю? | |||||
| 3 | Что будет считаться провалом внедрения? | |||||
| 4 | Какой smallest useful release? | |||||
| 5 | Какие документы, CRM-записи, сообщения, файлы или API нужны? |
Полный Markdown-файл доступен как project asset: чек-лист вопросов AI-разработчику.
Что делать после проверки
Если чек-лист показывает неясный scope, начните с аудита. Если workflow понятен, но данные грязные, начните с data и integration mapping. Если workflow, данные, permissions и review gates уже понятны, можно scopeить prototype или first production-safe release.
Для broader service context используйте страницу AI-специалист в Армении. Для proof смотрите кейсы. Для соседних procurement criteria сравните материалы про выбор AI-разработчика, фрилансера или AI-студию и критерии AI-специалиста.
Проверено и обновлено
Проверено 2026-07-08 по контент-плану aicoding.am, существующим service pages, публичному proof layer кейсов и текущему локальному article cluster. Статья не использует self-awarded rankings и оставляет broad local AI intent за dedicated landing page.
Где это применимо
AI developer interview, procurement review и first production-safe scope
Материал полезен, когда компании в Армении нужно проверить AI-разработчика до договора на AI-автоматизацию, RAG, agent, LLM workflow или internal tool project.
- Founders готовят первый vendor conversation.
- Operations-команды превращают AI-идею в scorable project brief.
- Компании хотят checklist вместо широких обещаний AI capability.
project_readiness = outcome_clarity
+ data_access
+ integration_contracts
+ evaluation_cases
+ ownership_after_launch;
if (score.data == 0 || score.permissions == 0) require("discovery_audit");
if (writes_to_live_systems) require("human_approval_gate");