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

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

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

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

## TL;DR

TypeSpec  умеет генерировать спецификации в форматах OpenAPI v3.0.0, Protobuf, JSON Schema.

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