Психология разработки | Сергей Андреев

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

Забавный факт: если попробуете почитать вступление книги про ТРИЗ, вы обнаружите, что очень похожими словами описана наука.

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

Если есть какая-то научная проблема, мы просто запускаем 1000 учёных, которые тестируют разные гипотезы, и, может быть, у кого-то что-то найдётся.

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

Там даже было исследование: учёным предлагали проанализировать уже решённые задачи, но с которыми они раньше не сталкивались, и никто не мог предложить правильный ход мышления, который бы привёл к результату.

Ну и сам ТРИЗ, кстати, это тоже попытка найти и описать такой алгоритм. Кстати, рекомендую почитать, если ещё не знакомы. Всё ещё актуальное чтиво, которое вам может сильно зайти.

Ну а что касается метода научного тыка, я думаю, его не стоит недооценивать. Что тогда, что сейчас, в эпоху искусственного интеллекта.

Радуйтесь, что у нас появилась машина перебора. Всё равно в конечном итоге всё зависит от входных параметров, а, как показал тот же самый ТРИЗ, проблема не в том, чтобы решить задачу. Проблема в том, чтобы додуматься до абсолютно нелогичных этих самых параметров.

Ещё про триз:
- концепция идеального решения из ТРИЗ подходит и для программирования

Наверное, самая удивительная вещь в разработке это то, что наш код одновременно является как продуктом, так и рабочим местом.

При этом при разработке мы не можем не учитывать второе, иначе будет как в том меме про user experience vs design.

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

Это значит, что при изменении этих вводных мы должны получать разные программные решения для одних и тех же задач.

Что автоматически делает аксиомой невозможность получения каких-либо бест-практик в этой области и доказывает, что серебряной пули не существует для всех.

Есть знаменитый закон Конвея, согласно которому структура создаваемой системы будет копировать структуру коммуникаций организации, которая её разработала. (Опять же смотрим на прекрасную картинку про UX/UI.)

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

На компанию часто бывает сложно посмотреть как на парк с высоты птичьего полёта, поэтому эта часть часто ускользает.

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

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

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

По сути мы большую часть времени тратим на проектирование нежизнеспособных решений, потом на попытку их поддерживать, после этого пытаемся обкладывать их правилами, запретами, ограничениями (в случае парка, например, мы могли бы поставить забор: чего это народ топчет газон? Но в случае кода почему бы не добавить линтер, или бюрократии с согласованиями, или просто бегать и ругаться с коллегами, сетуя своим друзьям или интернету на глупых людей. Тут всё зависит от ваших полномочий.)

Где-то здесь уже хотелось бы получить какие-то практические советы. И что же с этим делать? Я бы даже мог попробовать их вам дать или сделать, например, курс (хе-хе).

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

Ну а хорошо это потому, что это и есть инженерная задача, а мы с вами как раз инженеры. На удивление, дисциплина разработки программного обеспечения сгенерировала тонны очень крутых и ценных подходов: DDD, SOLID, паттерны проектирования, микросервисный подход, модульные монолиты, Event Storming. Я уверен, вы можете добавить что-то своё, то, что вам нравится.

И это всё правда работает (да даже микросервисы, если учитывать структуру коммуникаций вашей компании). Это всё правда работает, если при проектировании опираться на оба аргумента функции: то, что наш код одновременно является как продуктом, так и рабочим местом.

А на этом у меня всё. Жду вас в комментариях.

AI замедляет разработку, именно коллективную, так как чем больше артефакт ты создал, тем сложнее его передать через потоки коммуникации, и сложность там растёт квадратично или даже сильнее

То есть пока результаты работы AI не выходят за рамки лично тебя, то перфоманс будет большой, как только речь заходит о командной разработке, это скорее влияет отрицательно

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

Ну и есть ещё вторая крутая цитата из времён классики: извини, у меня было мало времени, поэтому получилось длинно

Потому что чтобы сделать что-то простое и понятное, нужно больше времени, нежели чем на халтурную работу

И здесь с AI происходит, мне кажется, часто самообман, когда большой результат воспринимается как продуманная работа, а на деле люди над ней реально меньше думали, вот и получилось много

Агентам нужно строить scaffolding, нежели просто управлять контекстом и памятью.

По сути, это про смену фокуса: не пытаться удержать всё в голове агента, а постепенно выносить повторяемую работу в инструменты.

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

Я бы это назвал scaffolding.
По мере разработки проекта, точно так же, как при построении домов, вам нужны строительные леса.

Сейчас многие пытаются городить их из md-файлов, фокусируясь только на написании самого проекта.

Кстати, учитывая, что тот же Claude хранит все сессии и память локально, можно его же натравить на них:

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

Я на нескольких проектах попробовал, и временный тулинг действительно работает великолепно

🤔, а ведь и правда так

Всё-таки Claude Code + Obsidian это что-то с чем-то.

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

Организовал, разобрал, структурировал, при этом всё это слинковано.

Раньше у меня на такую работу ушло бы несколько лет.

По сути я сделал AI-only vault, где я контролирую только inbox.

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

По мере анализа встреч агент находит всё новые объекты, людей, темы, модули различных систем.

Это позволяет после первого прохода сделать второй, уже с новыми знаниями.

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

Ну и, конечно, ничего такого я бы не смог сделать, если бы до этого аккуратно и методично не сохранял всю информацию.

В общем, пушка бомба, буду дальше развивать.

А тебе помогает фоновый шум?
Я, например, заметил, что мне достаточно просто концентрироваться в кафе или на лекциях в больших залах в универе.

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

А если хочу поработать над чем-то, то включаю себе музыку.

Кстати, на маке можно включить фоновый шум 🤯

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

Мне кажется это хорошая идея

Я буквально сегодня так и сделал, у меня была заметка о том как я хотел чтобы выглядел дизайн моего блог


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


По итогу кстати лучшие варианты оказались у v0 и gemini.

Ну и gemini конечно не перестаёт меня удивлять, всё чаще начинаем пользоваться, это совершенно небо и земля по сравнению с тем что было раньше, сейчас очень круто

Даже подумываю отменить подписку на чат gpt и взять подписку google 🤔