Стоит ли это создавать? Вопрос важнее, чем «Можем ли мы?»

Стоит ли это создавать? Главный вопрос разработчика в эпоху AI

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

От «Можем ли мы?» к «Стоит ли?»

За двадцать лет в разработке я поняла одну вещь: технологии меняются, но важные вопросы остаются. Когда-то «Можем ли мы это построить?» был сложным вопросом. Время, бюджет, сложность — эти ограничения заставляли нас тщательно выбирать, что создавать. Но сегодня, с инструментами вроде Lovable, Bolt, Replit и Claude Code, ответ почти всегда «да». Ирония в том, что эта лёгкость породила новую проблему: мы перестали задумываться, стоит ли что-то создавать.

Вот типичный сценарий: вы пишете скрипт для автоматизации отчёта за 15 минут. Потом коллега просит добавить пару фич. Через месяц этот скрипт — критическая часть рабочего процесса, и вы — его единственный мейнтейнер. Звучит знакомо? Добро пожаловать в реальность, где поддержка кода занимает больше времени, чем его создание.

Почему «Стоит ли это создавать?» — ваш новый компас

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

# Пример: AI-генератор отчётов, который вы написали за вечер
import openai

def generate_report(data):
    # Используем AI для создания текста отчёта
    prompt = f"Создай краткий отчёт на основе данных: {data}"
    response = openai.ChatCompletion.create(
        model="gpt-4",
        messages=[{"role": "user", "content": prompt}]
    )
    return response.choices[0].message.content

# Через месяц: поддержка этого кода требует обновления API, обработки ошибок, тестов
# Вы потратили 2 часа на написание, но уже 10 часов на поддержку

Проблема не в том, что мы создаём слишком много. Проблема в том, что мы создаём, не задаваясь вопросом: «А должно ли это вообще существовать?». Когда все используют одни и те же модели и инструменты, код перестаёт быть отличием. Настоящее преимущество — понимание клиента, умение убрать лишнее и решить настоящую проблему.

Как не утонуть в поддержке и строить осмысленно

Вот несколько практических советов, которые помогут вам не попасть в ловушку бесконечного мейнтейна:

• Перед созданием спросите себя: «Решает ли это проблему, которая действительно существует? Или я просто доказываю, что могу это сделать?»
• Оцените стоимость поддержки: Сколько времени вы готовы тратить на обновления, исправления багов и совместимость с новыми версиями зависимостей?
• Ищите неочевидные решения: Может быть, проблема решается без кода — изменением процесса или обучением коллег?
• Устанавливайте границы для pet-проектов: Если проект не приносит пользы никому, кроме вас, будьте готовы, что он останется только вашим.

# Пример: вместо создания нового инструмента — используйте существующий
# Плохо: написать свой парсер логов (потом его нужно поддерживать)
# Хорошо: использовать grep и awk, которые уже есть в системе
import subprocess

def parse_logs(log_file):
    # Используем встроенные утилиты, а не пишем свой парсер
    result = subprocess.run(['grep', 'ERROR', log_file], capture_output=True, text=True)
    return result.stdout.splitlines()

# Такой подход не требует обновлений и работает десятилетиями

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

Практический вывод: что делать прямо сейчас

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