В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.
Я вам по секрету скажу, что здесь оригинал. А там - перевод. Здесь лычка "перевод" потому что мне нужно как-то объяснить поисковикам, что контент на сайте вполне себе оригинальный, а не ворованный с хабра.
Люди как бы тоже не выдают одинаковый код, даже если решают ту же самую задачу.
Сравнивать код человека и код ИИ корректно. Сравнивать код и промпт - нет. Собственно, об этом у нас спор был.
И давайте начистоту. В инженерии нет термина "Практически всегда". Или совпадает или не совпадает. Или детерминированный результат или нет. Или мы можем гарантировать корректность результата или нет. "Практически всегда" - это однозначно "нет".
Если то, что сейчас по ошибке в названии содержит "интеллект", сможет себя эффективно улучшать, то мы вполне можем получить AGI за часы. Непознаваемый, за горизонтом событий. Но для этого ему нужно как минимум меняться со временем. То есть обучаться в процессе жизни, а не как сейчас.
В статье речь про текущее положение вещей. AGI - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "team lead" говорит о том, что он находится внутри команды.
Во вторых существует две крайности: не давать никому править свой код и придерживаться позиции "ну они же потратили время".
Ну потратили, дальше что? Да, компания заплатила за их время. И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид должен принимать решение исходя из того, насколько PR соответствует решению задачи в рамках архитектуры проекта. И всё. Ни потраченное время, ни личные предпочтения тут не должны играть роли. Это, конечно, утопия, но надо к этому стремиться.
Примерно лет 10 назад я работал в команде с одной девочкой. Очень продуктивная была. Так за примерно полгода работы она наворотила столько, что потом два года пришлось переписывать. Не потому, что я такой принципиальный. Просто по мере доработки различных частей системы я сталкивался с тем, что придётся сначала её код поправить, чтобы новая часть заработала. Я матерился, потому что у меня не было никакого желания переписывать этот код, но ничего поделать не мог.
Вот это - прожирание денег компании. Девочка сделала абы как, чтобы казаться полезной, а по итогу сожгла своё время и в два раза больше моего.
И я пожалел, что не был тем "Андреем", который вовремя заворачивает реквест и отправляет на доработку. Это сэкономило бы кучу времени и денег компании.
Я зашёл в ваш профиль, и увидел, что вы работаете тимлидом. Значит вы хорошо знаете на собственном опыте, где находится засада этой должности.
Для остальных: у тимлида нет никаких рычагов давления на "подчинённых". Да у него и нет фактически подчинённых. У него есть только ответственность за проект. Есть то же самое начальство, что и у всей команды. Есть спрос с него. Есть ответственность за проект, а полномочий нет. Только красивая лычка и возможность не принимать PR. Больше ничего. То есть проект пишет вся команда, а спрашивают с него.
Андрей прожирал ресурс компании, заставляя её оплачивать пустой труд
Ну всмысле прожирал ресурс? Он сам писал код, при этом находил время для ревью кода, объяснял что не так. Объяснял почему. Показывал как надо.
Я не буду исключать, что он мог где-то ошибаться или слишком ревностно относиться к кодовой базе. Но "прожирал ресурс" - это ну просто слишком.
Тут одно из двух: либо команда в принципе не способна самостоятельно работать, либо им это отбил текущий стиль управления.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Объективно стало лучше
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Насчёт того, как где принятно называть таблицы, это не истина в последней инстанции, а стандарты конкретного стека и команды/проекта.
Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.
А вот когда обычная сущность, лучше singular (единственное число)
Не лучше
Потому что если дальше у вас там будет какой нибудь DAO+ORM типа ActiveRecord, то и название класса будет не Customer допустим а Customers
Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.
Во многих других проектах вы будете страдать, занимаясь экранированием этого слова в запросах (а где забудете - получите баги), ибо оно ключевое зарезервированное во многих СУБД.
Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.
В производстве ПО должно быть по другому, потому что код и есть штучный товар. Если проводить аналогию, то код - чертёж, ПО - результат построения по чертежу. Само ПО ничего не стоит, потому что компилятор наштампует его в любом количестве, а вот код - это дорого, очень дорого. Потому что R&D, вот почему.
А ещё потому что код долгоживущий. И чем дольше код живёт, тем больше с него прибыль. И тем сложнее его дорабатывать. А дорабатывать надо, потому что "нужно очень быстро идти, чтобы оставаться на месте". Качество кода - это не прихоть, это суровая необходимость рыночных реалий. Бездумный код может обрушить весь бизнес под тяжестью техдолга. Это не какие-то страшилки, это случается регулярно.
Соглашусь полностью. И добавлю, что декларативные языки, хоть и дают детерминированный результат, но страдают от недетерминированности времени выполнения. Вот это самое "О большое". Именно поэтому существует EXPLAIN, который показывает, что и в каком порядке будет выполняться в конкретно этом случае.
А я соглашусь с тем, что компиляторы C++ пишут бредовый и неоптимальный машинный код, который невозможно поддерживать. Правда тут аж два нюанса. На плюсах разработка сильно проще и быстрее, чем на асме. Процессоры становились сложнее, команд больше а тонкости применения прямо лавиной хлынули, смывая призрачную надежду справиться с этим своей головой. Ассемблер Z80 это вообще не то же самое, что ассемблер x86-64 со всеми avx512 и уровнями кэша.
Второй нюанс в том, что C++ остался детерминированный. Он из одного и того же кода делает один и тот же машинный код. Его поведение полностью предсказуемо. Это снимает необходимость дорабатывать машкод руками.
Ну и статья как раз о том, что на самом деле наша индустрия никогда такого не переживала.
Давайте так. Чтоб уж справедливо было, сначала упомянем, что это разные места. "Don’t expect AGI within the next year" в оригинале это "Не ждите AGI в ближайший год". Без истерик. И да, изначально я писал на русском.
В том месте, где "И не говорите мне, что..." в английской версии выглядит как "But don't tell me...". Истерика на месте, всё в порядке.
Я вам по секрету скажу, что здесь оригинал. А там - перевод. Здесь лычка "перевод" потому что мне нужно как-то объяснить поисковикам, что контент на сайте вполне себе оригинальный, а не ворованный с хабра.
Сравнивать код человека и код ИИ корректно. Сравнивать код и промпт - нет. Собственно, об этом у нас спор был.
И давайте начистоту. В инженерии нет термина "Практически всегда". Или совпадает или не совпадает. Или детерминированный результат или нет. Или мы можем гарантировать корректность результата или нет. "Практически всегда" - это однозначно "нет".
Да, именно так. Но я тут не вижу противоречий.
Если то, что сейчас по ошибке в названии содержит "интеллект", сможет себя эффективно улучшать, то мы вполне можем получить AGI за часы. Непознаваемый, за горизонтом событий. Но для этого ему нужно как минимум меняться со временем. То есть обучаться в процессе жизни, а не как сейчас.
В статье речь про текущее положение вещей. AGI - неопределённое, но неотвратимое будущее. Да, статья скорее сделана с целью предупредить о последствиях применения ИИ, поэтому такая нарочито вызывающая. Но я всё равно не позволял себе определения "тупейший". Мои претензии к нему в другом.
Мне даже добавить нечего
Я давно знаю, что такое многопоточка. И успешно практикую. Её отличие недетерминированности промпта - это документированная неоднозначность. Причём только во времени выполнения. Всегда есть способ заставить многопоток работать тем способом, который задумывался, так как механизмы синхронизации никто не отменял. Для промптов таких технологий не существует.
Я могу повторить то, что написал в статье: промпт это не код. Даже не близко. Промпт - это ТЗ. Это совершенно разные вещи. Вопрос "в чём разница" смысла не имеет. Ну в детерминизме, например. Это тоже написано в статье. Код всегда выполняется одинаково, он однозначен. ТЗ и пропмт будут давать каждый раз разный результат. Вплоть до того, что у одного человека промпт сработает, а в другом заруинит проект. Один и тот же.
Называть документирование техникой программирования из прошлого я бы постеснялся. Это не техника программирования и не из прошлого.
Но тут уже проще найти сходства и отличия с промптом, потому что это одного уровня сущности. Ну например, промпт, как и ТЗ, пишется до разработки. Документация - по факту. И цели немножко разные, но и документация бывает немного разная. Например по установке, по пользованию, по АПИ.
Если ассемблер и код джава я могу назвать одним и тем же, но на разных уровнях абстрации, то промпт к этой вертикали вообще не относится. Он не гарантирует результат. Он не гарантирует однозначность. Да он вообще ничего не гарантирует, в отличие от кода на любом языке.
Номер статьи хороший, вы специально подбирали? )
Да
Как это не работал? Он проводил код-ревью, обучал, объяснял, показывал. Это всё обязанности тимлида.
Во-первых тимлид - это не руководящая должность. По определению. Если у вас были полномочия набирать и увольнять людей, значит вы были начальником отдела. Само определение "team lead" говорит о том, что он находится внутри команды.
Во вторых существует две крайности: не давать никому править свой код и придерживаться позиции "ну они же потратили время".
Ну потратили, дальше что? Да, компания заплатила за их время. И что теперь, тимлид обязан принять их PR? Просто за то, что были сожжены IRL токены?
Тимлид должен принимать решение исходя из того, насколько PR соответствует решению задачи в рамках архитектуры проекта. И всё. Ни потраченное время, ни личные предпочтения тут не должны играть роли. Это, конечно, утопия, но надо к этому стремиться.
Примерно лет 10 назад я работал в команде с одной девочкой. Очень продуктивная была. Так за примерно полгода работы она наворотила столько, что потом два года пришлось переписывать. Не потому, что я такой принципиальный. Просто по мере доработки различных частей системы я сталкивался с тем, что придётся сначала её код поправить, чтобы новая часть заработала. Я матерился, потому что у меня не было никакого желания переписывать этот код, но ничего поделать не мог.
Вот это - прожирание денег компании. Девочка сделала абы как, чтобы казаться полезной, а по итогу сожгла своё время и в два раза больше моего.
И я пожалел, что не был тем "Андреем", который вовремя заворачивает реквест и отправляет на доработку. Это сэкономило бы кучу времени и денег компании.
Я зашёл в ваш профиль, и увидел, что вы работаете тимлидом. Значит вы хорошо знаете на собственном опыте, где находится засада этой должности.
Для остальных: у тимлида нет никаких рычагов давления на "подчинённых". Да у него и нет фактически подчинённых. У него есть только ответственность за проект. Есть то же самое начальство, что и у всей команды. Есть спрос с него. Есть ответственность за проект, а полномочий нет. Только красивая лычка и возможность не принимать PR. Больше ничего. То есть проект пишет вся команда, а спрашивают с него.
Ну всмысле прожирал ресурс? Он сам писал код, при этом находил время для ревью кода, объяснял что не так. Объяснял почему. Показывал как надо.
Я не буду исключать, что он мог где-то ошибаться или слишком ревностно относиться к кодовой базе. Но "прожирал ресурс" - это ну просто слишком.
Что-то как-то вывод похож на ложную дихотомию. Неужели не допускаете промежуточных вариантов?
Я допускаю. Допускаю, что у наёмных сотрудников есть семья, ипотека, свои проблемы и радости. И работа у них далеко не в первых строках приоритетов. Они могут быть замечательными и честными людьми. Но ответьте на вопрос: а у них будет выше зарплата, если они начнут работать больше?
А если будут работать меньше, будет ли у них снижаться уровень стресса? А что им даёт устойчивость и поддержание низкой сложности проекта? Они будут меньше получать, если проект станет сложнее?
Собственники замотивированы в решениях, влияющих на долгосрок. Есть отдельная категория наёмных сотрудников, которые действительно думают о долгосрочных последствиях и очень ответственно относятся к работе. Но это скорее исключение.
А я понимаю Андрея и его цели. Думаю, что он хотел понятную и управляемую систему без накопленного технического долга. По крайней мере, вот эта фраза об этом говорит:
Да, он тормозил разработку, но у этого была причина - недопущение экспоненциального роста сложности системы. Да и 31% отклонённых PR я бы не назвал гейткипом.
Вы можете и не заметить дальнейшего ухудшения процессов, ориентируясь на PR. PR, как и строки кода, ни о чём не говорят. Сказать может лишь сложность выполнения новой неожиданной задачи. Только метрику такую ещё не придумали, чтобы измерять эффективность выполнения новых неожиданных задач. Потому что они новые и неожиданные.
Ух, как быстро меняются приоритеты...
Девять. Второй отсутствует.
Какого стека? Какого проекта? Какой ещё команды? Order - это термин из английского языка, обозначающий заказ. Упорядочивание тоже.
Не лучше
Не будет. В любой ORM можно сделать маппинг имени класса к таблице. Какие-то это автоматом делают, вроде EF, но всё равно можно руками поправить. Ну никто же не переносит напрямую имена таблиц из snake_case таблиц в языки с CamelCase стандартом. Таблица - "orders", класс "Order", репозиторий "Orders". Это стандарт индустрии, общепринятое соглашение.
Во первых, не во "многих" а в ANSI SQL 92. Во-вторых таблицы принято называть сущностью во множественном числе, никаких коллизий при этом не происходит. При этом не понятна аргументация в сторону английского языка. Order - это совершенно корректный и общепринятый термин для обозначения заказа. Точка.