«Гид по выживанию prompt engineer»: семь опор в эпоху, когда код генерируют модели

На Dev.to опубликована статья, в которой автор развивает мысль, знакомую многим, кто уже «живёт» с генеративным ИИ: Cursor в этом рассказе фигурирует как усилитель, но не замена выверенного мышления. Во вступлении автор описывает сценарий: разработчик тратит около 45 минут на цепочку промптов, чтобы получить rate limiter; код выглядит рабочим, тесты проходят, а вопрос о race condition при параллельных запросах остаётся за кадром, пока его специально не поднимают. Дальше он проводит границу между быстрой генерацией и глубокой проработкой и связывает 2026 год с тем, как для карьеры инженера всё заметнее ценится не скорость набора строк, а качество рассуждений рядом с моделями (источник; дата доступа: 2026-05-11 UTC).

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

От систем до этики: семь столпов как в первоисточнике

На Dev.to автор раскладывает семь глав по отдельным разделам: у каждого свой заголовок и связка между «что это значит на практике» и «как наращивать навык». Ниже — сжатый конспект по смыслу для русскоязычного читателя, без добавления между строк того, что в посте явно не сказано:

1. Systems thinking («видеть всю доску»): нагрузка, отказоустойчивость, экономика изменений; в примерах — цепочки вроде связи авторизации и платежного контура, кэш, failure modes. Среди ориентиров в тексте — Google SRE, блог Netflix, репозиторий System Design Primer на GitHub.

2. Problem framing: тезис, что модель сильнее как «машина ответов», слабее как «машина вопросов»; перевод бизнес-формулировок в техзадачу и разбор того, что на самом деле нужно, вместо ярлыка вроде «нам просто нужен dashboard». Практика «одно предложение задачи перед промптом», 5 Whys, работа рядом с продактом; как отметка методологии упомянут Shape Up из Basecamp.

3. Debugging deeply: случайные 500 в проде, разница между разбором стектрейсов и «пролистыванием» логов, гипотезы перед правками; сначала отладка без ИИ и пошаговый «журнал отладки». Книга Debugging (David Agans, debugging.com).

4. Technical communication: сроки миграций, RFC, менторство без «сломать» человека; как ориентир для развития навыка назван StaffEng.

5. Code review & quality judgment: код от ИИ может выглядеть корректным, но требует человека как «волка качества» по безопасности, абстракции и поддерживаемости; упомянут OWASP Top 10, чеклисты по ошибкам, краевым случаям, производительности и тестам, материалы Google eng-practices.

6. Learning how to learn: парадокс удобных подсказок LLM и интуиции, которая нарабатывается там, где задача даётся «в бою»; примеры про React и reconciliation, про индексы в БД; приём объяснять, чтобы понять (Фейнман); книга A Mind for Numbers (Barbara Oakley).

7. Ethical reasoning & judgment: у генеративных систем нет человеческой этики по умолчанию; автор поднимает риск оптимизации «без тормозов»; в примерной зоне — filter bubble, сбор данных; практический ряд включает Ethical OS Toolkit, вопрос «who gets hurt?» и рекомендацию Radical Candor (Kim Scott).

К этому в оригинале добавлены таблица самооценки Skills Matrix (Beginner / Intermediate / Expert) для всех семи блоков и 30-Day Challenge с недельным планом, включая пункт полного дня разработки без ИИ во вторую неделю и ревью чужого ИИ-кода на четвёртую. Заключение снова сводится к перечню в духе: мыслить системами, формулировать проблемы, отлаживать, объяснять, судить о качестве, учиться и этически аргументировать.

Навигация по ссылкам внизу той же страницы Dev.to

В блоке «для дальнейшего чтения» внизу того же поста на Dev.to перечислены ссылки платформы, в том числе материалы того же автора про vibe coding в продакшене и соседние тексты про роль prompt engineer и сравнение ИИ- и не-ИИ-разработки одного проекта. Эти URL не задают содержание пересказа выше: их можно использовать как список для продолжения чтения там же.

Источники

• Mamoor Ahmad — The Prompt Engineer's Survival Guide: Skills That AI Can't Replace. Dev.to: Dev.to (дата доступа: 2026-05-11 UTC). Дата публикации записи по индексу ленты: 2026-05-11T16:41:22Z (11 мая 2026 г., 16:41 UTC). Оценочное время чтения: 8 минут; в связанном с объектом записи счётчике зафиксированы 3 публичных реакции и 3 комментария (текст комментариев в доступном к просмотру снимке страницы не воспроизводился).