Спасибо, за поддержку! Я признаю, что текст действительно получился довольно размытый и мне явно стоит подучиться писать технические статьи и конструктивная критика для этого очень важна. А пример с Моне забавный и ярко иллюстрирует предвзятость как реально существующее явление.
Прежде чем диагностировать "безгамотность", стоило дочитать до расшифровки. MWP в тексте раскрывается как minimal wowable product. Но замечание по читаемости принимаю — убрал эту аббревиатуру.
Интересно, статья получила уже три минуса за то что «текст похож на сгенерированный» при том, что единственный вклад ллм — проверка орфографии и пунктуации перед первой публикацией. Теперь живу с мыслью что не прошел обратный тест Тьюринга.
Это классный вопрос и действительно с определением есть проблемы. В данный момент я смотрю является ли прошлая сущность корректируемой и если да, то проверяю может ли фраза рассматриваться как коррекция. Кроме того, каждое действие имеет свой идентификатор, который можно указать если хочется скорректировать что-то конкретное. Плюс может работать поиск по тексту, когда запрос явно классифицируется как коррекция.
И нет, это не реклама канала. К своему стыду, я не успеваю его вести, хотя казалось бы накопил кучу всего. Но пока это съедает слишком много времени. Вот когда возобновлю, тогда и буду рекламировать.
О, я кажется тупанул и не оставил ссылку на сам сайт, поправлю текст ) Если что — вот https://planitforme.ru/ Там можно посмотреть демо и оставить заявку, но т.к. пока каждый работающий аккаунт увеличивает расходы, я довольно медленно их одобряю.
Нет, это уже совсем не скрам. Это мини-команда, которая end-to-end отвечает за ввереную часть продукта. Может состоять из одного человека, в реале я думаю более вероятно 1-3.
Да конечно это всё метафора и человеческая организация это не что-то детерминированное что должно всегда выдавать нужные характеристики в нужных условиях. Но процессы усложнять можно по разному — добавлять людей, слои менеджемента, как если мы хотим масштабировать стройку. А можно "уплотнять" компетенции и ответственность, что безусловно более рискованно, но в идеальном мире может отлично работать.
А почему не показательный? Raptor 3 нельзя было сделать без информации от Raptor 1/2 и возможно новых технологических и дизайнерских решений. И то, что первая часть исследовательская и экспериментальная — как раз показательно. На примере — кажется, что лет через 5 использование ИИ на всех этапах SDLC будет гораздо более целостным, чем это сейчас, когда организации двигаются на ощупь, исследуют риски и осваивают рокетджамп находят баланс между повышением производительности и безопасностью деплоев.
Формат поста не позволяет вставить две картинки — вставлю тут ещё одну картинку из статьи. Наглядный пример инженерной эволюции. На фотке — ракетные двигатели Raptor, от первой до третьей (актуальная) версии. С процессами бы так!
Рекомендую почитать оригинал статьи ) traditional enterprise таки тоже внедрял ИИ, просто методом эволюции. И тоже получили кратный прирост. Понятно, что есть эффект наблюдателя и это не значимая статистическая выборка. Но сейчас любые исследования ценны, т.к. практики только формируются.
Про когнитивную емкость (в оригинале "cognitive bandwidth") — на мой взгляд, очевидно верный концепт. Когда ты джун и понимаешь какие-то базовые вещи, ты используешь 100% своих знаний. Когда ты сеньор, понимаешь как устроен CAS, что такое CRDT, можешь спроектировать систему, написать простенький ML алгоритм, оценить UX и сделать ещё бог знает что на нескольких языках, но по какой-то причине пишешь очередной CRUD или event loop — ты используешь 1-5% знанией (в момент решения конкретной задачи). Чтобы использовать больше как раз нужен кто-то/что-то способный быстро следовать за мыслью, чтобы не пришлось тратить время тупо на набивку текста.
Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
FROM users
SELECT email, age ;
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь. Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например. Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
Видимо придирка к «распределение… описывается», я бы сказал «данные распределены вдоль прямой», но я ни разу не переводчик. Ну и в целом «алгоритмы данных предполагают» звучит довольно необычно :-)
Спасибо, за поддержку! Я признаю, что текст действительно получился довольно размытый и мне явно стоит подучиться писать технические статьи и конструктивная критика для этого очень важна.
А пример с Моне забавный и ярко иллюстрирует предвзятость как реально существующее явление.
Прежде чем диагностировать "безгамотность", стоило дочитать до расшифровки. MWP в тексте раскрывается как minimal wowable product. Но замечание по читаемости принимаю — убрал эту аббревиатуру.
Интересно, статья получила уже три минуса за то что «текст похож на сгенерированный» при том, что единственный вклад ллм — проверка орфографии и пунктуации перед первой публикацией. Теперь живу с мыслью что не прошел обратный тест Тьюринга.
Кстати, тоже отличная трактовка
Это я решил со смыслами поиграть. Проиграл, получается.
Это классный вопрос и действительно с определением есть проблемы. В данный момент я смотрю является ли прошлая сущность корректируемой и если да, то проверяю может ли фраза рассматриваться как коррекция. Кроме того, каждое действие имеет свой идентификатор, который можно указать если хочется скорректировать что-то конкретное. Плюс может работать поиск по тексту, когда запрос явно классифицируется как коррекция.
И нет, это не реклама канала. К своему стыду, я не успеваю его вести, хотя казалось бы накопил кучу всего. Но пока это съедает слишком много времени. Вот когда возобновлю, тогда и буду рекламировать.
О, я кажется тупанул и не оставил ссылку на сам сайт, поправлю текст ) Если что — вот https://planitforme.ru/ Там можно посмотреть демо и оставить заявку, но т.к. пока каждый работающий аккаунт увеличивает расходы, я довольно медленно их одобряю.
Нет, это уже совсем не скрам. Это мини-команда, которая end-to-end отвечает за ввереную часть продукта. Может состоять из одного человека, в реале я думаю более вероятно 1-3.
Да конечно это всё метафора и человеческая организация это не что-то детерминированное что должно всегда выдавать нужные характеристики в нужных условиях. Но процессы усложнять можно по разному — добавлять людей, слои менеджемента, как если мы хотим масштабировать стройку. А можно "уплотнять" компетенции и ответственность, что безусловно более рискованно, но в идеальном мире может отлично работать.
А почему не показательный? Raptor 3 нельзя было сделать без информации от Raptor 1/2 и возможно новых технологических и дизайнерских решений. И то, что первая часть исследовательская и экспериментальная — как раз показательно. На примере — кажется, что лет через 5 использование ИИ на всех этапах SDLC будет гораздо более целостным, чем это сейчас, когда организации двигаются на ощупь, исследуют риски и
осваивают рокетджампнаходят баланс между повышением производительности и безопасностью деплоев.Формат поста не позволяет вставить две картинки — вставлю тут ещё одну картинку из статьи. Наглядный пример инженерной эволюции. На фотке — ракетные двигатели Raptor, от первой до третьей (актуальная) версии. С процессами бы так!
Рекомендую почитать оригинал статьи ) traditional enterprise таки тоже внедрял ИИ, просто методом эволюции. И тоже получили кратный прирост. Понятно, что есть эффект наблюдателя и это не значимая статистическая выборка. Но сейчас любые исследования ценны, т.к. практики только формируются.
Про когнитивную емкость (в оригинале "cognitive bandwidth") — на мой взгляд, очевидно верный концепт. Когда ты джун и понимаешь какие-то базовые вещи, ты используешь 100% своих знаний. Когда ты сеньор, понимаешь как устроен CAS, что такое CRDT, можешь спроектировать систему, написать простенький ML алгоритм, оценить UX и сделать ещё бог знает что на нескольких языках, но по какой-то причине пишешь очередной CRUD или event loop — ты используешь 1-5% знанией (в момент решения конкретной задачи). Чтобы использовать больше как раз нужен кто-то/что-то способный быстро следовать за мыслью, чтобы не пришлось тратить время тупо на набивку текста.
Прощу прощения за долгий ответ, но вот только дошли руки. Я думаю, что возможность иметь адаптированное отображения для кода — это прекрасно и мы точно к этому придём. Причём было бы прикольно иметь различные срезы — для SRE, DBA, инженеров по безопасности, продактов и бизнес и системных аналитиков. Это чуть более высокий уровень чем тот, про который вы пишите, но кажется такие представления могли бы решить много проблем. Довольно часто из кода можно восстановить изначальную постановку задачи и то, каким именно образом она была решения. А имея всё это, можно записать решение в более подходящем для восприятия виде. Я уверен, что так и будет.
Но ведь тоже касается и написания. Если мне нужно решить задачу и у меня есть алгоритм, которым я хочу решить эту задачу, то кажется самое простое что я могу сделать — это описать ограничения задачи и сам алгоритм. На русском/английском используя математические термины или термины предметной области — это не важно. Если есть модель, которая хорошо воспринимает естественные и формальные языки, то так ли важно в какой именно код она преобразует написанное мной? Важно чтобы она смогла передать мне все условия и ограничения своего решения, но ведь для этого даже не обязательно показывать сгенерированный код. Достаточно описать это в лаконичной понятной форме, как это делает Wolfram M.
Таким образом, мой тезис про то, что читать важнее чем писать, он скорее про то, что сейчас следует ориентироваться на то, что человек не будет писать код. Точно также как мы сейчас редко пишем на низкоуровневых языках, написание кода на высокоуровневых языках станет нишевой историей. Потому что написание кода на любом языке — это снижение уровня абстракции, приземление на конкретный синтаксис, паттерны и библиотеки. Думаю это функцию вполне по силам делегировать моделям и сконцентрироваться на задаче "что делать", а не "как записать" то, реализацию чего уже придумали.
--
Не знаю, ответил ли я на исходный вопрос, но в любом случае, спасибо за него, навёл на мысли )
Спасибо за развернутый ответ, сейчас мне стало понятнее и я попробую ответить.
Для описанного вами автокомплита я бы предпочел
Но создатели SQL как раз приоритизировали понимание запроса человеком и исходный вариант гораздо ближе к человеческому "select email and age from users where ... " что, я полагаю, явилось причиной появления языка в том виде, в котором мы его знаем теперь.
Размышление на эту тему подталкивает меня к тому, что понятность с точки зрения IDE и понятность для человека имеют большую дистанцию чем, скажем, понятность для модели и для человека. Для человека критично важно видеть итоговые структуры, которые возникают на выходе программы и желательно иметь максимально простой способ понять почему именно возникают именно такие структуры. Думаю, это и предопределило декларативность практически всех языков преобразования данных. В той же JSONata в простейших случаях мы сразу описываем ту структуру которую ждем на выходе.
Мой тезис в том, что удобство чтения кода должно быть поставлено намного выше удобства его написания. При этом, конечно, по возможности надо способствовать корректному написанию. В этом смысле, как только в branchline вызреют сложные типы данных (json schema вполне может быть использована для их задания), то программа на нём будет проверять корректность ещё на этапе анализа. И автокомплит по типам будет поддержан в LSP. Но до полноценной поддержки типов надо дожить )
Не совсем понял. А что такое autocomplete friendly для языка? Если рассматривать отдельно от легкой воспринимаемости для моделей, то для меня это что-то типа настроек для монако. Но тогда во-первых, на базовом уровне автокомплит есть и работает в плейграунде, а во-вторых, не понятно как это может стереть грань. И я не уверен, что такую цель нужно ставить именно перед языком, а не перед его редактором, например.
Но, возможно, я как-то не так понял что вы имели в виду, буду признателен за уточнение.
О, не знал о таком проекте, выглядит очень круто, спасибо за наводку!
Спасибо :-)
Ниша узкая, это правда. Но например, если мы непременно хотим иметь возможность менять скрипт на лету и при этом иметь нечто более специализированное чем python, то у нас не так много опций — JSONiq, JSONata, JOLT, JSLT и ещё что-то редкое. У всего этого есть минусы, а если мы добавим полноценную отладку и экзотику типа вывода контрактов, то я даже не знаю подходящих альтернатив.
Но Branchline — это прежде всего эксперимент в рамках другого эксперимента. По-настоящем, как мне кажется, его можно раскрыть только если будет реализация платформы.
В любом случае спасибо за труд!