AI-native positioning: owner, не user

1. После capstone слов почти столько же, сколько кода

После защиты проекта легко выдохнуть и решить, что дальше всё просто: написать пару громких строк про AI, вставить ссылку на GitHub и идти покорять рынок. И именно здесь многие случайно обесценивают собственный труд. Работодатель не видит ваши 30 часов вдумчивого ревью diff’ов — только одну-две фразы, по которым пытается понять, кто перед ним.

Если вы говорите «я работал с Claude Code», это звучит примерно как «я умею пользоваться клавиатурой». Технически правда, пользы собеседнику ноль. Инструмент сам по себе ничего не доказывает.

Хорошее позиционирование начинается не с красивого ярлыка, а с простого вопроса: что именно вы контролировали сами, когда работали с AI? Неясно — у собеседника появляется догадка: работу сделал инструмент, а вы были оператором кнопки Enter. Не тот образ.

Посмотрите, как по-разному могут звучать почти одинаковые по смыслу фразы:

Разница здесь не в пафосе, а в точности: первая называет инструмент, вторая смещает ответственность на AI, третья показывает модель работы — она и нужна.

Сильное карьерное позиционирование — это не «я знаю Claude Code», а «я умею отвечать за инженерный результат в AI-assisted workflow».

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

2. Ответственный разработчик — это тот, кто владеет решениями

Чтобы не зависать в абстракции, полезно зафиксировать простую мысль: ответственный разработчик — это человек, который владеет процессом принятия решений. Claude Code ищет по проекту, предлагает план, пишет черновой код, подсказывает тесты. Но если баг уехал в production, «ну это Claude так предложил» не спасёт.

В вашем курсовом опыте это уже было много раз. TASK_SPEC.md — вы формулировали goal, scope, non-goals и критерии приёмки. План по Commerce OS — вы решали, какой подход принять. Reviewer-agent возвращал findings — вы отделяли реальную проблему от ложного срабатывания. Migration plan для CashFlow Dashboard — вы отвечали за rollback thinking и за доказательство feature parity.

Это удобно разложить по этапам:

Вот это и есть engineering ownership: не «писал руками без AI», а «управлял всей цепочкой — от задачи до проверенного результата».

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

Если хотите совсем простой тест на зрелость позиционирования, задайте себе вопрос: могу ли я без Claude Code объяснить, что изменилось, почему и как я проверил результат? Да — есть ownership. «Claude там что-то проанализировал, и всё заработало» — позиционирование ещё не дозрело.

3. Фразу собирают инженерно, из готовых частей

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

Я использую Claude Code, чтобы ускорять исследование задач, черновую реализацию
и первичную проверку изменений, но сам отвечаю за постановку задачи, границы
изменений, чтение diff, тесты и финальное инженерное решение.

Эта фраза хороша тем, что в ней нет магии: за модным «AI-native» она не прячется и сразу отвечает на страх работодателя: «Вы управляете процессом или наблюдаете?» Управляете. И говорите это вслух.

Если хочется сделать формулировку чуть конкретнее, можно собрать её уже из ваших реальных эпизодов курса:

Я использую Claude Code как рабочий инструмент в инженерном цикле:
от task spec и исследования codebase до diff review, тестов и подготовки PR.
AI помогает ускорить исследование и черновую реализацию, но решения о scope,
verification и финальном результате принимаю я.

А если у вас особенно сильны артефакты из Workflow Kit, формулировка может звучать уже так:

Я не просто использую AI в разработке, а проектирую вокруг него управляемый workflow:
правила в CLAUDE.md, reviewer-agent с явным output contract, локальную проверку,
diff review и безопасные границы изменений.

Заметьте: здесь мы не говорим «построил автономную AI-команду» и не выдаём курсовой reviewer-agent за платформу уровня Staff Engineer. Берём реальный артефакт и называем на его уровне.

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

# Моя профессиональная позиция

Я использую Claude Code как инженерный инструмент, а не как замену пониманию кода.

Claude Code помогает мне ускорять:
- исследование задач;
- черновую реализацию;
- первичную проверку и документирование.

Я сам отвечаю за:
- постановку задачи;
- границы изменений;
- чтение diff;
- tests и verification;
- финальное решение.

Да, выглядит очень просто — в этом как раз и сила. Позже из этого черновика собирают рабочий NARRATIVE_MAP.md, а из него — резюме, профиль GitHub и ответы на интервью. Не нужно заново изобретать «кто я как инженер»: есть база, которую сокращают, расширяют и адаптируют.

Есть ещё один полезный практический критерий: фразу можно произнести вслух без желания извиниться или приукрасить её словом «вообще-то» — значит, она, скорее всего, здорова. Стало неловко от «я построил AI-платформу корпоративного уровня», хотя делали учебный reviewer-agent с read-only policy, — хороший сигнал остановиться и вернуть речь к фактам.

4. Уровень истории = масштаб доказательств

На этом месте обычно возникает очень человеческое желание: звучать как можно старше и серьёзнее. И вот тут важно вовремя не начать косплей senior-разработчика, если сильнейшие артефакты пока на другом уровне.

Полезное правило здесь простое: уровень истории должен совпадать с масштабом доказательств. Где-то главный сигнал — довести небольшой scope до результата. Где-то — пройти весь issue-to-PR цикл с tests, review и docs. Где-то — спроектировать сам workflow, guardrails и работу с риском. Разница не в громкости слов, а в уровне ownership.

Самая частая ошибка — выбрать narrative «на вырост»: один MVP и один reviewer-agent, но назову себя AI Workflow Architect. У работодателя это обычно вызывает не восхищение, а осторожность. Сильный capstone, понятный workflow, хорошие проверки и честное понимание границ — уже отличный старт. Подробно различать Junior, Middle и Senior имеет смысл, когда на руках собранные артефакты.

5. Три крайности, которые бьют по доверию

Когда человек впервые пытается рассказать о своей AI-assisted работе, его часто бросает в одну из трёх крайностей, и все три бьют по доверию.

Первая — спрятать AI совсем, будто его не было. Собеседник всё равно начнёт задавать вопросы. Выяснится, что AI использовался, но вы это маскировали, — появится недосказанность. Сильнее честно: «Да, использовал Claude Code. Вот на каких этапах, вот что проверял сам, вот где оставалась моя ответственность».

Вторая — почти всё отдать AI, как будто человек только присутствовал при процессе. «AI писал код за меня» действует на доверие как «тесты я не запускал, но сердцем чувствую, что всё зелёное». Может, имели в виду «AI помогал с черновой реализацией», но прозвучало иначе.

И, наконец, раздувание масштаба. Это любимая ловушка фраз вроде «построил production-ready AI platform», когда на руках аккуратный учебный capstone. Учебный capstone не недостаток, не маскируйте его под энтерпрайз. Назовите честно: demo-ready проект, reproducible setup, controlled AI workflow, tests, README, verification trail. Такой язык вызывает уважение чаще, чем чужой присвоенный масштаб.

Удобно держать рядом с собой маленькую таблицу анти-позиционирования:

И здесь появляется ещё один важный принцип: одна и та же профессиональная позиция должна звучать одинаково на всех поверхностях. В самопрезентации, в GitHub profile README, в разговоре на интервью вы не должны каждый раз быть новым человеком. Тут «Junior developer with disciplined AI workflow», там «AI architect», а в третьем месте «я вообще просто пробовал инструмент» — собеседник сразу чувствует разнобой.

Поэтому полезно держать маленькую опорную заметку с тремя вещами: кем себя называете, за что отвечаете и чего сознательно не заявляете:

# Заметка о позиционировании

Мой профессиональный фокус:
AI-assisted разработка с инженерной ответственностью за spec, diff, tests и final decision.

Я не заявляю:
production scale, team leadership и migration ownership там, где у меня учебный или solo-формат.

Мои сильные стороны:
disciplined workflow, reproducible artifacts, honest verification.

Это ещё не резюме и не профиль, а внутренняя калибровка — чтобы в любой формулировке вы звучали как один и тот же человек, понимающий уровень, доказательства и зону роста.

И вот когда такая внутренняя опора появляется, AI-native developer перестаёт быть наклейкой. Это короткое описание поведения: вы используете AI как усилитель workflow, но не отдаёте ему ни понимание задачи, ни проверку результата, ни право последнего решения. Это и делает вас профессионально убедительным.