Вайб-СТО
👁 2.1K↗ 21💬 7
Ну что друзья, еще одно важное изменение в сознании.
Каждый из нас, будучи программистом, может и должен вырасти в вайб-СТО.
И это не прикол, а реальный роудмап. Сейчас объясню.
ИИ все лучше и лучше начинает писать код и постепенно вытесняет low-level разработку.
Однако, чтобы ИИ писал не полную дичь, а что-то полезное, надо четко ставить задачу.
А для этого надо научиться стратегическому планированию, ведь именно в этом и заключается главная задача СТО.
То есть это уже не про синтаксис.
Это про стратегию, архитектуру, понимание системы и финальную цель.
Про мышление, а не механическую реализацию.
Кто такой вайб-СТО?
Я тут немного накидал тезисов:
- Не просто пишет код, а мысленно проектирует продукт.
- Не просто формулирует фичу, а понимает бизнес-контекст.
- Не просто кидает промты в Cursor, а направляет ИИ так, как архитектор ведёт стройку.
И нет, для этого не обязательно иметь должность СТО.
Это состояние. Подход. Ответственность за продукт.
Можно оставаться соло-разработчиком, но мыслить как вайб-СТО.
Еще немного уточнений. Посмотрите, как обычно разработчики работают сейчас:
Получают задачу → пишут код → спотыкаются → уточняют → снова пишут → снова меняют.
Всё живое, всё в процессе, всё реактивно.
Но теперь, с AI, можно делать иначе. Сначала чётко сформулировать систему, продумать зависимости, предусмотреть ошибки. Сделать дизайн мышлением, а не только руками.
И потом уже отдавать на реализацию - хоть боту, хоть себе.
Ставишь задачу своим AI-сотрудникам и после выполнения ревьюешь работу 🙂
Короче, вайб-СТО.
Все это звучит как новая ветка в развитии программиста в эпоху нейронок. И это похоже на план.
PS: Пока писал этот пост подумал, что надо попробовать TDD подход, как будто тут ему самое место.
61/100
Telegram | Youtube
13
Комментарии · 7
- @shaurgonTDD нет, потому что тесты тебе система не напишет на пустой код. А вот после - легко
- @MANDR1Kнапишет
- @kirill_s_gavrПробовал уже? Как промт писал?
- @MANDR1Kу меня достаточно сложный юай есть в одном проекте, я логику отделял от рендерилки, формально есть класс отвечающий за нормализацию, другой за менеджинг чекбоксов айтемов и вложенных чилдренов (вложенных много раз), то есть задача в частом проходе по дереву элементов и разными манипуляциями,затем уже адаптер под юай с подписками на изменение состояний чтобы уведомлять реакт об изменениях. и вот такая штука хорошо себя чувствует в плане юнит тестирования, базовые сценарии можно по ходу покрывать через агента и не переживать при рефакторинге или изменений требований по ходу поддержки элементов. затем все пришедшие баги со стендов можно сперва через этого же агента попросить поймать в тестах, убедиться что воспроизводиться, и затем уже обновить код и убедиться что старые тесты не упали, а новый прошел писал об этом в канале своем пару постов, можно поискать по ключевым словам tdd
- @kirill_s_gavrСорри, я может немного не уловил, но кажется ты в целом про тестирование написал, а не конкретно про TDD) Я хочу попробовать написать код через тестирование, типа сначала написать тесты и потом под эти тесты написать код
- @MANDR1K
- @MANDR1Kво фронте обычно все очень связано и надо приложить много усилий чтобы сделать глупые компоненты с отделенной логикой от юай после этого можно бл писать через тдд, когда тебе не нужно поднимать или эмулировать браузер, мириться с жизненным циклом компонентов, бороться с каким-нибудь rtl