Да мне кажется, что это вы уникум, если на полном серьёзе считаете, что жизнь среднего человека настолько тяжела, а варианты слегка отвлечься настолько немногочисленны, что единственный возможный вариант не скатиться в бесконечный скролл -- это выбросить смартфон.
В моём представлении есть дни хуже, есть дни лучше, иногда хочется весь день лежать на диване и ничего не делать, иногда хочется поехать куда-нибудь подальше и ни о чём не думать, но если у тебя скроллинг занимает настолько много места в жизни, что хочется его жёстко ограничить -- это уже за гранью.
По сути вы сейчас назвали меня "киброргом" лишь потому, что я считаю, что досуг не ограничивается просмотром ленты. Мне всегда казалось, что это ровно наоборот, верный признак нёрда -- есть что-то одно ему интересное, а остального как бы не существует.
Ну, по этой логике какое-то дикое количество людей только и делают, что пытаются справиться с "тяжёлыми когнитивными нагрузками". Наверно, Цукерберг с Маском тоже по полдня скролят, или уже давно кнопочные телефоны купили.
Я не вижу ничего криминального в том, чтобы утром за чашкой чая почитать новости и хабр и иногда чего-то там откомментировать. От этой безобидной привычки очень далеко до ситуации, когда человек готов выбросить смартфон, ибо руки сами тянутся потратить любую свободную минуту на чтение непонятно чего.
Проблема не в том, что пресса и научпоп переехали в онлайн, проблема в том, что люди подсаживаются на алгоритмическую ленту, которая по определению выдаёт рандомные посты от рандомных людей. В этом и состоит её работа: подсовывать разное и новое, чтобы не дай бог не закончить скроллинг и не заняться другими делами.
Я даже близко не хочу заниматься морализаторством, но очевидно же, что речь идёт о нездоровом потреблении. Если бы автор писал, что не может покупать больше одной плитки шоколада за раз, потому что съест все без остановки, я бы отреагировал ровно так же. Дело же не в телефоне и не в каналах, а в том, что у людей проблемы с чувством меры.
Но откуда вообще берётся желание скроллить ленту? У меня огромный список из непрочитанных книг и непросмотренных фильмов, и всё это продукция топ-класса, а не какие-то рандомные посты от рандомных людей, которые завтра никто не вспомнит. Если у меня есть свободные 5 минут, я учу карточки со словами или читаю книжку (конечно, хорошо бы погружаться глубже, но как получается), но сама мысль залезть в какую-то вкладку со случайно наваленным барахлом даже в голову не приходит.
Это я даже не в порядке критики, просто иногда диву даёшься, как по-разному устроены люди. Для меня это как слот-машины: ровно такая же непостижимая история. Я знаю, что масса людей дёргают эти рычаги и смотрят на барабаны с фруктами, но понять не могу никак, ведь даже в Super Mario Bros. на порядок больше геймплея. Как-то ради интереса решил подёргать рычаг, пока не проиграю (небольшую) купюру из кармана, так вот это были едва ли не самые скучные 15 минут жизни.
Ну по моему опыту даже с описанными требованиями всё равно LLM не хуже. Грубо говоря, в умелых руках LLM явно добавляет производительности. Соответственно, хорший джун будет использовать LLM (нет ни одной причины не использовать). А далее вопрос в том, какую прибавочную стоимость он создаёт для вас, учитывая, что вы и без него можете использовать LLM. С моей точки зрения, человек, который создаёт прибавочную стоимость в таких условиях уже не совсем джун.
Вот я чего-то в последнее время хожу по похожим веткам и оставляю похожие комментарии. Вы со своим опытом, как бы мягче выразиться, далеко оторвались от земли и, быть может, позабыли, куда меньше-то. Сочетание "индусский код" не про LLM придумано, и явно не про хайлоад и многопоточность. То, чего вы хотите, возможно, совсем не космос, но совершенно за пределами средних талантов средних выпускников. Это уже всё специализация, знания, опыт.
Не, это чит :) Мидла и я умею. Представьте себе вот настоящего сферического выпускника в вакууме, для которого это ну чуть ли не первая профильная работа. С моей колокольни он по любым критериям уступит агенту. Да, конечно, выпускник под грамотным руководством может вырасти так, как агент не вырастет, но, может, у меня и нет такой цели. Может, у меня есть цель как раз отдать на аутсорс ровно те задачи, которые решать мидлу-сеньору и неинтересно. И вот эта ниша имхо с рынка труда вообще исчезает как класс.
Посмотрите на это с другой стороны. Проблемы с производительностью, случаи потери данных, время отклика, плохая архитектура -- это всё ответственность тимлида, ну или хотя бы мидла. Теперь представьте, что вы вот такой тимлид или мидл. Зачем вам вообще нужны джуниоры? Хотя бы в количестве одной штуки? Они пишут код плюс-минус не лучше Клода, точно так же косячат с архитектурой и производительностью, но работают гораздо медленее, очень многого в принципе не знают, требуют значительных усилий на babysitting ну и так далее. Можно обсуждать что там происходит на рынке глобально, но вот этой ниши, на мой взгляд, так просто теперь не существует. Ну разве что давать им задачи, где требуется ручной контроль (кнопки чтобы аккуратно расставлены были) и ручное же тестирование.
Ну так и здесь не Chat-GPT заявил, а OpenAI. Конечно, к ним априорного доверия меньше, но всё же не Пупкин. Короче говоря, если бы я был журналистом-новостником, пропустил бы. К какому-нибудь Трампу ещё меньше доверия, но всё, что он говорит, в ленты попадает.
Ну вы неоправданно задираете планку. Все слышали о том, что Перельман "вроде как" доказал гипотезу Пуанкаре ещё до того, как доказательства были более-менее верифицированы. На проверку доказательства теоремы Ферма тоже ушло немало времени, там даже ошибку нашли и не без труда исправили. Так что вполне себе инфоповод, по крайней мере, в русле традиции.
Мне кажется, что абсолютно все такие статьи пишутся людьми, которые сами ежедневно руками кодят, и все претензии можно свести к формуле "я пишу лучше, чем coding agent". С этой точки зрения всё понятно: есть вариант написать самому хорошо, либо, вероятно, с помощью агента побыстрее, но результат будет во всех отношениях хуже.
Если выйти на уровень менеджера или тимлида, то ситуация выглядит уже совсем иначе: я не пишу код, но под моим началом работают люди, которые пишут, а моя задача -- обеспечивать приемлемое качество и соответствие срокам. И вот при таком раскладе уже вовсе неочевидно, что агент справляется хуже среднего программиста. Фраза "индусский код" не про LLM придумана. Джуниор (и не только джуниор) тоже может неделю чего-то ваять и так ничего и не наваять.
Мне кажется, что вот таким фрустрирующим профессионалам стоит задуматься не о качестве агентов, а о качестве процессов. В небольшой компании достаточно иметь сильную команду, и на выходе явного шлака не получится. Но эта система не маштабируется: невозможно рассчитывать, что все вокруг талантливые, знающие, опытные и аккуратные. Но можно попытаться настроить конвейер так, что даже если на линии оказался не самый надёжный работник, сама система не позволит получить на выходе негодный продукт.
И ведь ничего концептуально нового тут нет: спецификации, code review, тестирование, метрики. Многое из этого мы не делали не потому, что мы не верим в подход, а потому что банально не хватает сил. Я доверяю Васе, шут с ним, с code review, Вася дичи не напишет. Если Петя сказал, что протестировал, не буду требовать автотестов в репозитории, чего уж там. А теперь это всё нагенерировать не очень обременительно, так что почему бы и нет.
В общем, для себя я сделал вывод, что надо полировать конвейер.
Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
В ООН порядка 200 стран, и безо всякого лампового социализма легко выбрать кучу такиих пар, где простолюдины первой страны завидовали бы простолюдинам второй. И ничего не меняется вообще, то есть эмпирически концепция не работает. Дальше уже можно рассужать, почему, но так или иначе, реальность такова.
Его очень трудно осмыслить, потому что автор ведёт себя так же, как и те, кого он критикует. Тут очень много соображений, которые подаются как данность (начиная от того, что никаким перераспределением денег и ББД проблему не решить и кончая тем, что к Кремниевой долине не читали Лакатоша и Фейерабенда), а если автор чего и пытается доказывать, то делает он это ссылкой на авторитет, как будто бы работа того или иного философа есть божественное откровение и истина в последней инстанции.
Очень много эмоций и необязательной критики тех, кто автору не нравится. Противоречия, которые уже подметили выше ("AI всех выкинет на улицу" а через пару абзацев "AI не может заменить людей"), а в конце всё равно какие-то несвежие идеи, типа давайте дадим больше контроля над технологиями людям а не корпорациям -- окей, но если технология меня заменит, а ББД всё равно "не работает", что радости с того, что технология в руках общества?.. Короче говоря, проблемы поднимаются понятные, но уровень дискуссии удручает.
Да, ситуация понятна, ну мы все живём "в процессе", и у меня нет твёрдого мнения по этому вопросу. Моя интуиция состоит в том, что концептуально правильно разделять этапы планирования и разработки, а каждая задача должна оставлять за собой некие осязаемые артефакты -- код, документацию, юнит-тесты. Разделение на планирование и код -- это такое же разделение, как на "багфикс", "рефакторинг", "новая функциональность". Вроде нет сомнений, что нехорошо в одном коммите совмещать багфикс и новое, но при этом превратить два предложения текста в три страницы кода через "магию" в голове -- как бы ок.
В принципе, тут же нет ничего нового: скажем, в TDD вы тоже по идее заранее пишете тесты (они же спеки по сути), а потом уже код. С другой стороны, многие классические рекомендации даются не потому, что они оптимальны, а потому что иначе нереалистично. Скажем, вы можете просить LLM делать себе код ревью хоть три раза в день, но коллега этого делать не будет.
Кроме того, разные этапы можно делать разными системами с разной ценой, если хочется сэкономить.
Признаться, я не читаю всё, что генерирует openspec. Я читаю хотя бы tasks.md (то есть чеклист) и общее описание design.md. Выгода (как мне кажется, на истину не претендую опять же) в том, что 1) после завершения работы только небольшая часть этого текста становится проектной документацией, вы получаете её бесплатно, и дальше при решении других задач LLM может читать документацию, а не лопатить сразу код (что опять же по идее должно экономить токены); 2) иногда в процессе работы LLM начинает автоматически жаловаться, что какой-то кусок кода не соответствует спецификации, а это сигнал -- надо перепроверить и исправить либо документ, либо код.
Глобально, помню, в какой-то книге было сказано, что если вы говорите, что не используете какую-то "методологию программирования", то вы просто не знаете, как она называется. Можно подходить к процессу по-разному, но надо отдавать себе отчёт в том, что конкретно происходит. Если у вас немного людей, и вы все на одной волне, может, и вправду незачем разжёвывать -- и так каждый понимает друг друга с полуслова. Но надо чётко осознавать особенности сетапа -- у кого-то так, у кого-то не так.
Скажем, мне комфортно думать в процессе письма, вот как сейчас. У меня есть коллега, который с ChatGPT общается голосом. Для меня это нонсенс, я не могу говорить и при этом думать. Но для него комфортно, что ж.
Я бы сказал, что это разумная критика, но она сама по себе настолько в общих чертах сформулирована, что непонятно, соглашаться или спорить. Дьявол в деталях.
С одной стороны, если я даю абзац текста подчинённому, и он пишет целую подсистему, я по сути уповаю на то, что он достаточно опытен, и у него в голове "логика, контекст и знание предметной области" совпадают с моими. На практике это поучается методика plug and pray, ну ок, небесспорно.
С другой стороны, "более подробными" по сравнению с чем? Очевидно, что английский текст не должен приближаться к Питону по объёму, но точно так же очевидно, что какие-то технические решения должны быть либо частью постановки задачи, либо запротоколированы уже после реализации, чтобы было понятно, что вот эта штука оптимизирует память, а не скорость, или наоборот, и так оно задумано.
Для меня очевидно, что три строчки текста из issue в качестве описания подсистемы явно мало. С другой стороны, конечно, надо избегать крайностей.
Ну я не вижу тут больших противоречий. В openspec описания полного устройства и не ожидается, всё по канонам agile. В идеале есть документ, который описывает общие принципы (используется такой-то фреймворк, такие-то архитектурные решения), и есть описание требуемой задачи, по сути github issue. А по мере закрытия задач растёт проектная документация.
Смотрите, даже если вы пишете небольшую функцию, которая у вас занимает 3 часа, всё равно вы отдельно её продумываете, и отдельно программируете, не так ли? И если что-то работает не так, у вас хотя бы в голове же есть картина -- проблема в постановке задачи или в реализации.
Соответственно, вы пишете спеку и по ней программируете задачу, потом следующую и так далее. Но на практике так никто не делает не потому, что это концептуально неправильно, а потому что нереально.
Но с появлением LLM это стало реально. Я сейчас почти все задачи для LLM прогоняю через OpenSpec, крому ну уж совсем мусорных на выброс. Я ему даю описание задачи (фактически github issue), дальше он генерирует несколько документов -- развёрнутое описание того, что надо сделать и чек-лист, он же "definition of done". Дальше запускается процесс, и если всё проходит хорошо, краткая выжимка этого всего (что конкретно сделано) становится частью документации проекта.
Ну вот за spec driven dev буду стоять - если бы было время и силы, в идеале разработка так бы и выглядела даже без всяких LLMs. Отделить планирование от кодирования - совершенно разумная цель, и очень хорошо, что её стало проще добиться.
Да мне кажется, что это вы уникум, если на полном серьёзе считаете, что жизнь среднего человека настолько тяжела, а варианты слегка отвлечься настолько немногочисленны, что единственный возможный вариант не скатиться в бесконечный скролл -- это выбросить смартфон.
В моём представлении есть дни хуже, есть дни лучше, иногда хочется весь день лежать на диване и ничего не делать, иногда хочется поехать куда-нибудь подальше и ни о чём не думать, но если у тебя скроллинг занимает настолько много места в жизни, что хочется его жёстко ограничить -- это уже за гранью.
По сути вы сейчас назвали меня "киброргом" лишь потому, что я считаю, что досуг не ограничивается просмотром ленты. Мне всегда казалось, что это ровно наоборот, верный признак нёрда -- есть что-то одно ему интересное, а остального как бы не существует.
Ну, по этой логике какое-то дикое количество людей только и делают, что пытаются справиться с "тяжёлыми когнитивными нагрузками". Наверно, Цукерберг с Маском тоже по полдня скролят, или уже давно кнопочные телефоны купили.
Я не вижу ничего криминального в том, чтобы утром за чашкой чая почитать новости и хабр и иногда чего-то там откомментировать. От этой безобидной привычки очень далеко до ситуации, когда человек готов выбросить смартфон, ибо руки сами тянутся потратить любую свободную минуту на чтение непонятно чего.
Проблема не в том, что пресса и научпоп переехали в онлайн, проблема в том, что люди подсаживаются на алгоритмическую ленту, которая по определению выдаёт рандомные посты от рандомных людей. В этом и состоит её работа: подсовывать разное и новое, чтобы не дай бог не закончить скроллинг и не заняться другими делами.
Я даже близко не хочу заниматься морализаторством, но очевидно же, что речь идёт о нездоровом потреблении. Если бы автор писал, что не может покупать больше одной плитки шоколада за раз, потому что съест все без остановки, я бы отреагировал ровно так же. Дело же не в телефоне и не в каналах, а в том, что у людей проблемы с чувством меры.
Но откуда вообще берётся желание скроллить ленту? У меня огромный список из непрочитанных книг и непросмотренных фильмов, и всё это продукция топ-класса, а не какие-то рандомные посты от рандомных людей, которые завтра никто не вспомнит. Если у меня есть свободные 5 минут, я учу карточки со словами или читаю книжку (конечно, хорошо бы погружаться глубже, но как получается), но сама мысль залезть в какую-то вкладку со случайно наваленным барахлом даже в голову не приходит.
Это я даже не в порядке критики, просто иногда диву даёшься, как по-разному устроены люди. Для меня это как слот-машины: ровно такая же непостижимая история. Я знаю, что масса людей дёргают эти рычаги и смотрят на барабаны с фруктами, но понять не могу никак, ведь даже в Super Mario Bros. на порядок больше геймплея. Как-то ради интереса решил подёргать рычаг, пока не проиграю (небольшую) купюру из кармана, так вот это были едва ли не самые скучные 15 минут жизни.
Из статьи:
Вот отсюда и вопрос.
Ну по моему опыту даже с описанными требованиями всё равно LLM не хуже. Грубо говоря, в умелых руках LLM явно добавляет производительности. Соответственно, хорший джун будет использовать LLM (нет ни одной причины не использовать). А далее вопрос в том, какую прибавочную стоимость он создаёт для вас, учитывая, что вы и без него можете использовать LLM. С моей точки зрения, человек, который создаёт прибавочную стоимость в таких условиях уже не совсем джун.
Вот я чего-то в последнее время хожу по похожим веткам и оставляю похожие комментарии. Вы со своим опытом, как бы мягче выразиться, далеко оторвались от земли и, быть может, позабыли, куда меньше-то. Сочетание "индусский код" не про LLM придумано, и явно не про хайлоад и многопоточность. То, чего вы хотите, возможно, совсем не космос, но совершенно за пределами средних талантов средних выпускников. Это уже всё специализация, знания, опыт.
Не, это чит :) Мидла и я умею. Представьте себе вот настоящего сферического выпускника в вакууме, для которого это ну чуть ли не первая профильная работа. С моей колокольни он по любым критериям уступит агенту. Да, конечно, выпускник под грамотным руководством может вырасти так, как агент не вырастет, но, может, у меня и нет такой цели. Может, у меня есть цель как раз отдать на аутсорс ровно те задачи, которые решать мидлу-сеньору и неинтересно. И вот эта ниша имхо с рынка труда вообще исчезает как класс.
Посмотрите на это с другой стороны. Проблемы с производительностью, случаи потери данных, время отклика, плохая архитектура -- это всё ответственность тимлида, ну или хотя бы мидла. Теперь представьте, что вы вот такой тимлид или мидл. Зачем вам вообще нужны джуниоры? Хотя бы в количестве одной штуки? Они пишут код плюс-минус не лучше Клода, точно так же косячат с архитектурой и производительностью, но работают гораздо медленее, очень многого в принципе не знают, требуют значительных усилий на babysitting ну и так далее. Можно обсуждать что там происходит на рынке глобально, но вот этой ниши, на мой взгляд, так просто теперь не существует. Ну разве что давать им задачи, где требуется ручной контроль (кнопки чтобы аккуратно расставлены были) и ручное же тестирование.
Ну так и здесь не Chat-GPT заявил, а OpenAI. Конечно, к ним априорного доверия меньше, но всё же не Пупкин. Короче говоря, если бы я был журналистом-новостником, пропустил бы. К какому-нибудь Трампу ещё меньше доверия, но всё, что он говорит, в ленты попадает.
Ну вы неоправданно задираете планку. Все слышали о том, что Перельман "вроде как" доказал гипотезу Пуанкаре ещё до того, как доказательства были более-менее верифицированы. На проверку доказательства теоремы Ферма тоже ушло немало времени, там даже ошибку нашли и не без труда исправили. Так что вполне себе инфоповод, по крайней мере, в русле традиции.
Мне кажется, что абсолютно все такие статьи пишутся людьми, которые сами ежедневно руками кодят, и все претензии можно свести к формуле "я пишу лучше, чем coding agent". С этой точки зрения всё понятно: есть вариант написать самому хорошо, либо, вероятно, с помощью агента побыстрее, но результат будет во всех отношениях хуже.
Если выйти на уровень менеджера или тимлида, то ситуация выглядит уже совсем иначе: я не пишу код, но под моим началом работают люди, которые пишут, а моя задача -- обеспечивать приемлемое качество и соответствие срокам. И вот при таком раскладе уже вовсе неочевидно, что агент справляется хуже среднего программиста. Фраза "индусский код" не про LLM придумана. Джуниор (и не только джуниор) тоже может неделю чего-то ваять и так ничего и не наваять.
Мне кажется, что вот таким фрустрирующим профессионалам стоит задуматься не о качестве агентов, а о качестве процессов. В небольшой компании достаточно иметь сильную команду, и на выходе явного шлака не получится. Но эта система не маштабируется: невозможно рассчитывать, что все вокруг талантливые, знающие, опытные и аккуратные. Но можно попытаться настроить конвейер так, что даже если на линии оказался не самый надёжный работник, сама система не позволит получить на выходе негодный продукт.
И ведь ничего концептуально нового тут нет: спецификации, code review, тестирование, метрики. Многое из этого мы не делали не потому, что мы не верим в подход, а потому что банально не хватает сил. Я доверяю Васе, шут с ним, с code review, Вася дичи не напишет. Если Петя сказал, что протестировал, не буду требовать автотестов в репозитории, чего уж там. А теперь это всё нагенерировать не очень обременительно, так что почему бы и нет.
В общем, для себя я сделал вывод, что надо полировать конвейер.
Автор этой статьи борется с какими-то просадками на наносекунды тут и там в то время как 95%+ софта пишется на на каком-нибудь Электроне. Всё, что описано в статье, совершенно разумно, но это уже какое-то выжимание последних капель, которое имеет смысл, если всё остальное сделано -- от алгоритмических оптимизаций до кастомных аллокаторов памяти.
В ООН порядка 200 стран, и безо всякого лампового социализма легко выбрать кучу такиих пар, где простолюдины первой страны завидовали бы простолюдинам второй. И ничего не меняется вообще, то есть эмпирически концепция не работает. Дальше уже можно рассужать, почему, но так или иначе, реальность такова.
Его очень трудно осмыслить, потому что автор ведёт себя так же, как и те, кого он критикует. Тут очень много соображений, которые подаются как данность (начиная от того, что никаким перераспределением денег и ББД проблему не решить и кончая тем, что к Кремниевой долине не читали Лакатоша и Фейерабенда), а если автор чего и пытается доказывать, то делает он это ссылкой на авторитет, как будто бы работа того или иного философа есть божественное откровение и истина в последней инстанции.
Очень много эмоций и необязательной критики тех, кто автору не нравится. Противоречия, которые уже подметили выше ("AI всех выкинет на улицу" а через пару абзацев "AI не может заменить людей"), а в конце всё равно какие-то несвежие идеи, типа давайте дадим больше контроля над технологиями людям а не корпорациям -- окей, но если технология меня заменит, а ББД всё равно "не работает", что радости с того, что технология в руках общества?.. Короче говоря, проблемы поднимаются понятные, но уровень дискуссии удручает.
Да, ситуация понятна, ну мы все живём "в процессе", и у меня нет твёрдого мнения по этому вопросу. Моя интуиция состоит в том, что концептуально правильно разделять этапы планирования и разработки, а каждая задача должна оставлять за собой некие осязаемые артефакты -- код, документацию, юнит-тесты. Разделение на планирование и код -- это такое же разделение, как на "багфикс", "рефакторинг", "новая функциональность". Вроде нет сомнений, что нехорошо в одном коммите совмещать багфикс и новое, но при этом превратить два предложения текста в три страницы кода через "магию" в голове -- как бы ок.
В принципе, тут же нет ничего нового: скажем, в TDD вы тоже по идее заранее пишете тесты (они же спеки по сути), а потом уже код. С другой стороны, многие классические рекомендации даются не потому, что они оптимальны, а потому что иначе нереалистично. Скажем, вы можете просить LLM делать себе код ревью хоть три раза в день, но коллега этого делать не будет.
Кроме того, разные этапы можно делать разными системами с разной ценой, если хочется сэкономить.
Признаться, я не читаю всё, что генерирует openspec. Я читаю хотя бы tasks.md (то есть чеклист) и общее описание design.md. Выгода (как мне кажется, на истину не претендую опять же) в том, что 1) после завершения работы только небольшая часть этого текста становится проектной документацией, вы получаете её бесплатно, и дальше при решении других задач LLM может читать документацию, а не лопатить сразу код (что опять же по идее должно экономить токены); 2) иногда в процессе работы LLM начинает автоматически жаловаться, что какой-то кусок кода не соответствует спецификации, а это сигнал -- надо перепроверить и исправить либо документ, либо код.
Глобально, помню, в какой-то книге было сказано, что если вы говорите, что не используете какую-то "методологию программирования", то вы просто не знаете, как она называется. Можно подходить к процессу по-разному, но надо отдавать себе отчёт в том, что конкретно происходит. Если у вас немного людей, и вы все на одной волне, может, и вправду незачем разжёвывать -- и так каждый понимает друг друга с полуслова. Но надо чётко осознавать особенности сетапа -- у кого-то так, у кого-то не так.
Скажем, мне комфортно думать в процессе письма, вот как сейчас. У меня есть коллега, который с ChatGPT общается голосом. Для меня это нонсенс, я не могу говорить и при этом думать. Но для него комфортно, что ж.
Я бы сказал, что это разумная критика, но она сама по себе настолько в общих чертах сформулирована, что непонятно, соглашаться или спорить. Дьявол в деталях.
С одной стороны, если я даю абзац текста подчинённому, и он пишет целую подсистему, я по сути уповаю на то, что он достаточно опытен, и у него в голове "логика, контекст и знание предметной области" совпадают с моими. На практике это поучается методика plug and pray, ну ок, небесспорно.
С другой стороны, "более подробными" по сравнению с чем? Очевидно, что английский текст не должен приближаться к Питону по объёму, но точно так же очевидно, что какие-то технические решения должны быть либо частью постановки задачи, либо запротоколированы уже после реализации, чтобы было понятно, что вот эта штука оптимизирует память, а не скорость, или наоборот, и так оно задумано.
Для меня очевидно, что три строчки текста из issue в качестве описания подсистемы явно мало. С другой стороны, конечно, надо избегать крайностей.
Ну я не вижу тут больших противоречий. В openspec описания полного устройства и не ожидается, всё по канонам agile. В идеале есть документ, который описывает общие принципы (используется такой-то фреймворк, такие-то архитектурные решения), и есть описание требуемой задачи, по сути github issue. А по мере закрытия задач растёт проектная документация.
Смотрите, даже если вы пишете небольшую функцию, которая у вас занимает 3 часа, всё равно вы отдельно её продумываете, и отдельно программируете, не так ли? И если что-то работает не так, у вас хотя бы в голове же есть картина -- проблема в постановке задачи или в реализации.
Соответственно, вы пишете спеку и по ней программируете задачу, потом следующую и так далее. Но на практике так никто не делает не потому, что это концептуально неправильно, а потому что нереально.
Но с появлением LLM это стало реально. Я сейчас почти все задачи для LLM прогоняю через OpenSpec, крому ну уж совсем мусорных на выброс. Я ему даю описание задачи (фактически github issue), дальше он генерирует несколько документов -- развёрнутое описание того, что надо сделать и чек-лист, он же "definition of done". Дальше запускается процесс, и если всё проходит хорошо, краткая выжимка этого всего (что конкретно сделано) становится частью документации проекта.
Ну вот за spec driven dev буду стоять - если бы было время и силы, в идеале разработка так бы и выглядела даже без всяких LLMs. Отделить планирование от кодирования - совершенно разумная цель, и очень хорошо, что её стало проще добиться.