🎯 Не в цель, а рядом

Я заметил, что Cursor AI показывает хорошие результаты не потому, что он слушает, что хочет человек, а скорее догадывается, что человеку хотелось бы.

Это вообще-то не тот навык, который машина могла бы сформировать только на основе документации и анализа ответов stackoverflow.

Я подозреваю, что важная часть современных AI — это анализ профиля пользователя, обучение каким-то основам интерпретации, может философии. Те этим надо прямо заниматься.

В посте одного из авторов я прочитал, что в Cursor работают ребята с хорошим фундаментальным образованием, в том числе в области философии.

В большей части результаты такой работы Cursor AI довольно хорошие.

Однако, я заметил и минусы.

Вот когда ты точно знаешь что тебе нужно, когда нужна работа "пинцетом и скальпелем" — тут эта общая неточность срабатывает не так хорошо.

Чем формулировать, описывать и корректировать — легче пойти и самому поправить.

Это еще одна ниша, где без оператора никуда.

Часто программисты не пишут тестов и вот почему

Сколько тестов нужно, чтобы протестировать простую web форму на React из 5 инпутов, и 2-х кнопок?

Примерный ответ: 80+ тестов.

Для этого надо написать и определить сетапы (начальные установки для каждого для каждого кейса). Замокать внешние зависимости или эмулировать их поведение — чтобы реальный код внешних элементов и react хуков не вызывался и не усложнял и не замедлял тестирование.

Тестирование даже в состоявшимся проекте это скучная и рутинная операция. Там где можно, люди, конечно, стараются этого избежать.

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

Теперь у каждого из вас есть свой собственный ассистент-тестировщик. Пусть пишет!

Требуйте 100% тестирования кода в ваших проектах!

Прежде всего требуйте от себя. Заставляйте себя. Делайте ревью. Учитесь.

Даже плохой тест это всегда лучше его отсутствия.

Госпаде, благослави AI!

Дизайн кода (Часть 1)

AI сделай мне форму с 5 полями, 2 кнопками и чтобы работало так и вот так.

— Слушаюсь и повинуюсь!

1️⃣ AI вообще пофиг на ваши человеческие предпочтения, он делает то, что вы просите и генерирует огромную форму с кучей кода, которая, возможно, работает.

Как убедится, что это все не сломается на следующем запросе?

Надо (хотя бы) написать тесты и зафиксировать поведение.

Тест кейс получается таким монструозным, что никто и никогда не сможет его прочитать и понять и модифицировать.

Это полностью слепая зона, где что-то делать сможет только AI и это будет вне вашего контроля. Читай — код на выброс.

Если идти таким "слепым путем", и ничего не понимать в своем проекте, то пусть AI сразу пишет на Ассемблере — зачем лишние прослойки в виде промежуточных языков программирования?

Ведь единственная причина почему мы просим AI писать код на понятных нам языках — это желание удерживать контроль над кодом и иметь возможность его модифицировать человеком.

Дизайн кода (Часть 2)

Я подозреваю, что большая часть программистов, которые бы делали для вас, для меня или кого угодно web проект остановились бы на 1 шаге, сгенерировали работоспособное решение и получили бы свое денежное вознаграждение и попрощались с этой задачей.

Но это не наш путь.

2️⃣ Первая мысль, которая приходит в голову — отделить функционал от видимой части. Разделить огромный массив кода хотя бы на 2 части.

Таким образом в процессе тестирования мы сможем отдельно тестировать функции и отдельно проверят более простую View часть.

Мы сможем обеспечить большое количество моков (заглушек) и процесс тестирования станет намного проще; И чтение и понимание и будущая поддержка.

А еще функции из огромного компонента мы сможем растащить по утилитам, кастомным хукам (по сути — тоже функциям) и мы получим уже уровень качества решения на порядок выше чем предыдущий.

Однако, как вы видите на картинке мы все еще вынуждены оперировать огромным массивом параметров и прокидывать между компонентами.

Дизайн кода (Часть 3)

Атомарность, декомпозиция, сокращение контекста.

Чем меньше элемент / компонент, тем проще им управлять, контролировать, тестировать, развивать.

3️⃣ На третьей итерации мы разбиваем форму на инпуты. Теперь каждый инпут это микро компонент со своими зависимостями, валидациями, локализацией, кастомным поведением.

Больше не надо прокидывать никаких параметров. Инпут может получить все нужное из контекста формы или других хуков.

При таком уровне декомпозиции мы разбиваем все на атомы-компоненты.

Тестирование малых компонент становится простым и дешевым.

Тестирование более крупных компонент основано на моках более мелких компонент.

Начиная с самого низа, поднимаясь наверх мы просто мокаем уже протестированные компоненты.

Так на каждом уровне мы можем сфокусировать именно на том, что важно именно для нужного уровня.

Чтение и понимание кода в каждом файле становится занятием элементарным. Поддержка и развитие достигают максимальной простоты.

Так мы приручаем AI монстра.

AI и Промптинг

Весь твиттер, реддит, сайты крупных ИТ компаний пестрит правилами и рекомендациями о том, как правильно писать запросы (Промпты) для AI.

Пиши запрос вот так — и твои результаты будут, как у самого крутого профессионала!

Мой опыт показывает обратное. Промптинг совершенно не важен. Пропускайте мимо этот бред и не обращайте внимание.

Нет волшебной строчки, которая заставит AI делать то, что она не делала и до этого.

В работе с AI, как и прежде, важно сесть и начать работать над конкретным проектом и конкретной задачей.

Важен не промпт, а ваша отсиженная 🍑, сгорбленная спина, количество опыта и умение сфокусироваться на задаче и не сдаться, когда вы уже 3 дня не вставали из-за компа, и сон плохой — потому что очень хочется допилить фичу, а мысли и идеи в голове не дают нормально уснуть.

Работать надо, ребята, а не искать заветную кнопку или промпт.

Хочешь результат? Будь готов собрать волю в кулак, стиснуть зубы и заставить себя хорошенько потрудиться.

Понимаю. Непопулярное мнение.