Привет, меня зовут Арина, я фулстек‑разработчик.
Есть задачи, которые годами возвращаются в твою жизнь. Для меня такой задачей стало бронирование столиков.
Я делала её трижды, с одной и той же основой — Vue, — но с разными окружениями вокруг:

• в первый раз это был Vue + JavaScript,

• во второй — Vue + TypeScript,

• в третий — Vue + Nuxt, Nitro и Prisma.

Главное, что менялось, — не фреймворк, а мои приоритеты и вопросы, которые я задавала себе, когда садилась за код.

Акт 1: 2022. «Как сделать»

Главная боль: лишь бы оно не развалилось

В 2022‑м я не думала об архитектуре. Я думала о том, как бы не упали сокеты.
И, конечно, они упали.
Если нужно было сделать CustomInput, я не делала универсальный компонент — я делала 10 отдельных компонентов под каждый input.
Потом действительно посмотрела видео «Vue 3 фундаментальный курс от А до Я»,и кое‑что начало сходиться.
Для понимания сокетов пришлось достать свои материалы с курсов и перечитывать их снова и снова.

В голове крутились вопросы:

• как валидировать поле в формах,

• как сделать авторизацию,

• как сделать выпадающий список,

• нормально ли подключать стороннюю библиотеку на каждый сложный компонент.

Я не задавалась вопросом «как это будет выглядеть через месяц», а спорила с бэкендером о том, какой оптимальный API для бронирования.
И как же счастливо ты чувствуешь, когда это наконец работает, а ещё больше — когда это работает в проде!

Акт 2: 2024. «Как для других?»

Главная боль: боязнь стать «автором говнокода», который всё потом ругают

К 2024‑му я уже понимала, что v-model и v-bind можно писать с закрытыми глазами.
Но теперь меня больше напрягала перспектива, как за мной будут работать другие через месяц‑другой.
Я начала задавать задаваться вопросом: «Как сделать так, чтобы следующий программист собирал экран за 4 часа, а не 16?»

Я начала:

• выносить логику в сервисы и composables;

• создавать универсальные компоненты для ячеек, таблиц, списков, кнопок, чтобы не переписывать их на каждом экране;

• завязывать компоненты на дизайн‑систему;

• продумывать адаптив на уровне макетов и тикетов, а не только в коде.

Теперь я больше не думала: «как заставить это работать».
В 2024‑м я уже не собирала системы из кусков, а писала компоненты и сервисы так, чтобы их можно было переставлять и использовать повторно, а не переписывать каждый раз.

Акт 3: 2026. «Зачем и как быстро?»

Главная боль: как выкатить продукт без лишних месяцев работы

В 2026‑м я больше не спрашиваю: «как написать код?»
Я спрашиваю: «Какой минимальный набор решений нам нужен, чтобы выкатить рабочий продукт за выходные?» «Как делегировать рутину так, чтобы это не превратилось в технический долг?»

Мой новый инструмент — ИИ, но я не даю ему свободу.
Я сначала:

• проектирую архитектуру:

• какую модель данных мы будем хранить,

• какую связку фронт/бэк/база мы выбираем;

• фиксирую ограничения и конвенции;

• и только потом открываю Claude с запросом:
  «Вот схема БД, вот архитектура, вот дизайн‑система. Напиши мне CRUD API на Nitro с Prisma»,
  или
  «Напиши компонент модалки, который соблюдает наши стили и типы».

Он моментально выдаёт код, но форма решения напоминает то, как вставлял бы примеры в свой проект человек, который только что посмотрел пару статей и решил: «вот как делать».

• Втыкает Teleport вместо slot без особой причины;

• Прописывает цвета в Tailwind хардкодом в каждом компоненте, игнорируя переменные дизайн‑системы;

• Валит типы прямо в тело компонента, вместо types/;

• Ставит вторую библиотеку иконок, потому что «в примере так было».

Моя задача — не просто подписать код, а разобрать, что он сделал, и убрать шум.
Я не «дописываю вручную», я перестраиваю структуру, правлю архитектурные решения, привожу типы в порядок и проверяю, как это всё вписывается в существующую систему.
В 2026‑м я не просто «пишу буквы».
Я трачу энергию на формулирование вопросов, контроль решений и интеграцию, а не на рутину, которую можно делегировать.

Эпилог: как меняется мышление, а не код

За три итерации сценарий «бронирование столиков» превратился для меня в линейку роста:

• 2022: как сделать? - гугл, видео, «чтобы работало»;

• 2024: как для других? - архитектура, дизайн‑системы, DX, защита от говнокода;

• 2026: зачем и как быстро? - системное мышление, AI как инструмент, а не замена.

В 2026‑м я всё меньше времени сижу и вбиваю строки вручную.
Иногда я спрашиваю себя:

«А я уже превращаюсь в менеджера? Или в ленивого разработчика?»

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

Это не лень, а оптимизация своего времени.
Это не выгорание, а переход в другую фазу, где я хочу больше думать, чем механически втыкать div и v-model.

Мой тг-канал — пишу и про поиск работы в 2026, вопросах с собесов и про все что мне угодно