Андруша пишет код

docs driven development
Пока я готовлю видео, поделюсь ещё одной мыслёй.

Как я писал ранее, люди очень плохи в том, чтобы формулировать задачи. Зачастую нам просто лень, так как мы подразумеваем, что контекст задачи есть в голове и у других людей и поэтому его не надо уточнять. Но это не так. И это проявляется как на практике, где время по согласованию задачи растёт по экспоненте от количества людей, так и с нейронками.

Первое, что я увидел - это был архитект мод: режим в котором ты сначала заставляешь нейронку формулировать задачу, а потом заставляешь выполнять задачу, относительно этой формулировки. И это работает, но не так хорошо как хотелось бы. У меня ни разу не получалось сделать задачу полностью с помощью этого метода. Нейрока тупо забывала свои же инструкции.

Поэтому я выработал другой подход: docs driven development
1. Генерим какую-то документацию к библиотеке
2. Скармливаем документацию нейронке и говорим выполнить задачу по ней
3. Смотрим что она предлагает и активно спорим, если она что-то делает не так
4. В момент, когда мы понимаем, что нейронка делает как нам хочется, запрещаем ей решать задачу и говорим ей исправить документацию: нейронка должна описать почему она не поняла задачу только по доке и что нужно в этой документации исправить
5. Обрываем сессию и возвращаемся ко второму шагу.

Почему документация важна? Потому что я прихожу к тому, что с нейронками эффективно можно жить только в монорепе с кучей мелких библиотек. Увы, и никак иначе. И документация нужна для того, чтобы нейронки понимали как работают соседние модули.

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

Из минусов: я пока не уверен, что это прямо правильный путь. В интернете тупо 0 инфы о таком подходе. Как будто я первый кто до этого додумался. Но, главное что оно работает

www.tgoop.com/xavescor_code/256

728 viewsFeb 15 at 16:50

docs driven development
Пока я готовлю видео, поделюсь ещё одной мыслёй.

Как я писал ранее, люди очень плохи в том, чтобы формулировать задачи. Зачастую нам просто лень, так как мы подразумеваем, что контекст задачи есть в голове и у других людей и поэтому его не надо уточнять. Но это не так. И это проявляется как на практике, где время по согласованию задачи растёт по экспоненте от количества людей, так и с нейронками.

Первое, что я увидел - это был архитект мод: режим в котором ты сначала заставляешь нейронку формулировать задачу, а потом заставляешь выполнять задачу, относительно этой формулировки. И это работает, но не так хорошо как хотелось бы. У меня ни разу не получалось сделать задачу полностью с помощью этого метода. Нейрока тупо забывала свои же инструкции.

Поэтому я выработал другой подход: docs driven development
1. Генерим какую-то документацию к библиотеке
2. Скармливаем документацию нейронке и говорим выполнить задачу по ней
3. Смотрим что она предлагает и активно спорим, если она что-то делает не так
4. В момент, когда мы понимаем, что нейронка делает как нам хочется, запрещаем ей решать задачу и говорим ей исправить документацию: нейронка должна описать почему она не поняла задачу только по доке и что нужно в этой документации исправить
5. Обрываем сессию и возвращаемся ко второму шагу.

Почему документация важна? Потому что я прихожу к тому, что с нейронками эффективно можно жить только в монорепе с кучей мелких библиотек. Увы, и никак иначе. И документация нужна для того, чтобы нейронки понимали как работают соседние модули.

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

Из минусов: я пока не уверен, что это прямо правильный путь. В интернете тупо 0 инфы о таком подходе. Как будто я первый кто до этого додумался. Но, главное что оно работает

BY Андруша пишет код