Генеративный ИИ — в каком-то смысле действительно джун, потому что его код нельзя взять и с ходу выкатить в продакшн.
Ну, это потому, что пока делаются только локальные запросы. Кто-нибудь пробовал попросить генеративную модель спроектировать целую систему? И, кстати, здесь надо будет потом каким-то образом получить экспериментальные данные, чтобы другая модель мола бы понять, что в решении первой модели было не так и сконструировать новое решение.
Гораздо труднее смастерить базу кода, которая ещё много лет будет пригодна для того, чтобы с ней работали, изменяли её и рассуждали о ней отдельные люди, целые команды и будущие поколения команд.
Есть ли примеры многолетнего использования кодовой базы? Я бы с интересом поработал бы в компании, где такая кодовая база есть. (Другой вопрос, что меня там никто не ждёт. Но это — совсем другой вопрос.)))
Искусственный интеллект не собирается выполнять рефакторинг или подбирать для вас интеллектуальные абстракции. Чем важнее, сложнее или осмысленнее этот фрагмент кода, тем менее вероятно, что вы получите от ИИ годный артефакт.
Может быть, это — следующий шаг в развитии ИИ? Ситуацию, которая сложилась сейчас, можно описать как обучение с подкреплением, когда генеративные модели получают пользовательский отклик. Как только этот этап будет пройден, будет Вам и рефакторинг, и интеллектуальные абстракции.
Если кто-то утверждает, что он хорошо разбирается в системе, которую он разрабатывает и с которой работает, то либо это очень маленькая система, либо (что более вероятно) ему не хватает знаний понять, что именно он не знает.
Здесь упускает из виду то, что значительная часть контор разрабатывают, по сути, одни и те же системы, и, уж точно, в большинстве, решают одни те же задачи. Если, однажды, ИИ "увидит" некий общий каркас, сможет формализовать его и предложит программную реализацию, то...
Всё это свидетельствует о глубоком непонимании того, чем, собственно, занимаются разработчики.
А вот это уже очень интересно: насколько хорошо сами разработчики понимают, чем они занимаются? Надеюсь, далее это будет подробно расшифровано. Или... в действительности у нас, как всегда, всё совсем не так, как на самом деле?!?
Для меня концепция сеньора в основном не завязана на способности писать код. Для сеньора скорее важно умение понимать, поддерживать, объяснять и управлять большим корпусом ПО в продакшне на протяжении долгого времени, а также способность трансформировать потребности бизнеса в технические решения.
Похоже, это мало кто понимает. Всегда должны быть такие люди. О когда их нет, то... приходится всюду ходить на "костылях".
Возможно, более практичная дорожка в ИТ — это хороший программистский буткемп, оттачивающий практические навыки решения задач и работы с современным инструментарием. В любом случае вы не столько учитесь, «как делать конкретную работу», сколько «изучаете основы, чтобы понимать и использовать инструменты, которыми нужно пользоваться, чтобы изучить работу».
Было бы интересно посмотреть на то, если бы у университетах действительно учили бы именно умению писать код: начиная с программирования как такового, до системного уровня, когда на всё смотрят с архитектурной точки зрения. Когда диплом об окончании обучения означал бы, что программист ничего не будет делать "на коленке", а все участники процесса разговаривали бы всегда на одном и том же языке.
Чтобы каждый знал, что при разработке системы нужно сделать первое, второе, третье. Не пропуская этапов, зная и умея составлять документацию, и т.д. и т.п.
Всегда обращал внимание на разницу между понятием сложности и понятием трудности. Всегда говорят о сложности, но почти никогда — о трудности. Как будь-то это синонимы. Трудность означает затраты энергии, в том числе, и интеллектуальной. Сложность? Трудно сказать... Хороший код требует учёта различных аспектов. Наверное, этим и сложен.
Простите! А можно задать вопрос человеку, который сильно отстал от жизни? Вы не подскажите, std::array — это STL? А где можно ознакомиться с современным состоянием вопроса? И в каких компиляторах это реализовано?
Проблема в том что не существует универсального способа.
Универсальный способ существует и он коротко обрисован здесь мною. Решение известно. Но никто не торопится это решение воплощать.
. Так как постройка такого монстра очень трудозатратное мероприятие и оно зависит от множества фактов:
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
Самое главное я не встречал готовых решение который выдавали бы хоть какой-то приемлемый результат пусть и с плясками.
Боюсь, таких решений нет. Хотя, я подозреваю, что в отдельных компаниях имеются внутренние системы, которые в чём-то близки к задуманному.
Почему авторы подобных статей (с хорошим внутренним посылом) не любят разбирать конкретные примеры? Статья завершается там, где должен возникнуть рабочий пример.
Лично для меня важная "зацепка" для понимания истинного положения вещей находится вот здесь:
Стекозависимость -— разработанная дизайн система на ангуляре не будет работать на вью или реакте, так как созданные части не будут подходить. Как следствие, вы становитесь заложниками того, на чем у вас создана система. Высока вероятность того, что вам рано или поздно придется переписывать все, даже если будут просто серьезные изменения между версиями того стека, который вы выбрали
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Интересно посмотреть на это в плане разработки программного обеспечения.
Сначала мы задаём самые общие контуры будущей системы: отвечаем на вопрос, для чего предназначена данная система, что она делает. Это — концептуальный уровень — уровень, на котором нами проясняется общая композиция.
Затем, строится логический уровень системы, где вдоль каждого контура выстраивается общая логика работы приложения. Здесь мы отвечаем на вопрос, как должна быть организована система, как она функционирует.
И уже в самом конце, когда два предыдущих этапа уже пройдены (здесь у нас строгая логическая последовательностью этапов! нельзя что-то пропустить, что-то перескочить, зайти с чёрного входа), наступает этап реализации системы, когда каждая процедура логического уровня приобретает плоть и кровь в виде конкретного программного кода, готового сорваться в бег. Это — физический уровень системы.
Случается такое, что задача, переданная в разработку, прилетает в середине спринта (тогда она имеет риск прийти к тестировщику на анализ уже выполненной).
Довольно любопытно прочитать такой бойкий концентрат.
Но какой из этого может быть вывод?
Наерное, лучше всего будет с самого начала иметь некий общий для разных сторон документ, в котором всё расписывается "от печки", начиная с базовых понятий, продолжая методологией разработки и завершая принципами реализации. Это как отчёт о НИР. Каждый этап работы над проектом — раздел отчёта. И все всё будет ясно на каждом этапе.
Увы. Но любой предмет может быть использован "непредметным" способом. Это может привести к проблемам в безопасности. Это может привести к неожиданным эффектам.
Беда современных инструкций — это куцее изложение того, что "для того, чтобы сделать то-то и то-то, надо сделать то-то". Нет вводного раздела с описанием того, а что это за предмет, что в принципе с ним можно сделать. Надо же понимать, что ты делаешь! Мы должны знать, чего ожидать в случае, если мы (случайно или намеренно) произведём определённую последовательность действий.
Если мы встретились с собственной ошибкой, то, разве не интересно узнать, в чём она состоит?
Ну, это потому, что пока делаются только локальные запросы. Кто-нибудь пробовал попросить генеративную модель спроектировать целую систему? И, кстати, здесь надо будет потом каким-то образом получить экспериментальные данные, чтобы другая модель мола бы понять, что в решении первой модели было не так и сконструировать новое решение.
Такое впечатление, что в реальности, довольно часто генерируют много кода, которому невозможно доверять. И без всякого ИИ, разумеется.
Есть ли примеры многолетнего использования кодовой базы? Я бы с интересом поработал бы в компании, где такая кодовая база есть. (Другой вопрос, что меня там никто не ждёт. Но это — совсем другой вопрос.)))
Может быть, это — следующий шаг в развитии ИИ? Ситуацию, которая сложилась сейчас, можно описать как обучение с подкреплением, когда генеративные модели получают пользовательский отклик. Как только этот этап будет пройден, будет Вам и рефакторинг, и интеллектуальные абстракции.
Здесь упускает из виду то, что значительная часть контор разрабатывают, по сути, одни и те же системы, и, уж точно, в большинстве, решают одни те же задачи. Если, однажды, ИИ "увидит" некий общий каркас, сможет формализовать его и предложит программную реализацию, то...
А вот это уже очень интересно: насколько хорошо сами разработчики понимают, чем они занимаются? Надеюсь, далее это будет подробно расшифровано. Или... в действительности у нас, как всегда, всё совсем не так, как на самом деле?!?
Похоже, это мало кто понимает. Всегда должны быть такие люди. О когда их нет, то... приходится всюду ходить на "костылях".
Было бы интересно посмотреть на то, если бы у университетах действительно учили бы именно умению писать код: начиная с программирования как такового, до системного уровня, когда на всё смотрят с архитектурной точки зрения. Когда диплом об окончании обучения означал бы, что программист ничего не будет делать "на коленке", а все участники процесса разговаривали бы всегда на одном и том же языке.
Чтобы каждый знал, что при разработке системы нужно сделать первое, второе, третье. Не пропуская этапов, зная и умея составлять документацию, и т.д. и т.п.
Всегда обращал внимание на разницу между понятием сложности и понятием трудности. Всегда говорят о сложности, но почти никогда — о трудности. Как будь-то это синонимы. Трудность означает затраты энергии, в том числе, и интеллектуальной. Сложность? Трудно сказать... Хороший код требует учёта различных аспектов. Наверное, этим и сложен.
Простите! А можно задать вопрос человеку, который сильно отстал от жизни? Вы не подскажите, std::array — это STL? А где можно ознакомиться с современным состоянием вопроса? И в каких компиляторах это реализовано?
Универсальный способ существует и он коротко обрисован здесь мною. Решение известно. Но никто не торопится это решение воплощать.
Наверное, то, что Вы сказали, суть одна из причин того, что описанное мною до сих пор не сделано. Я подчеркнул в Вашем высказывании ключевое слово "монстр". В действительности, декомпозиция задачи построения сложной системы посредством использования различных языков, суть разделение на относительно простые подзадачи и должно приводить к ускорению разработки.
Боюсь, таких решений нет. Хотя, я подозреваю, что в отдельных компаниях имеются внутренние системы, которые в чём-то близки к задуманному.
Почему авторы подобных статей (с хорошим внутренним посылом) не любят разбирать конкретные примеры? Статья завершается там, где должен возникнуть рабочий пример.
Лично для меня важная "зацепка" для понимания истинного положения вещей находится вот здесь:
Сказанное Вами совершенно справедливо. Как только мы что-то выбираем, мы становимся заложниками того, чем пользуемся. Но! Какой из этого вывод? А то, что нужен какой-то специализированный язык для создания таких систем ("движок") и набор трансляторов на различные платформы и стеки.
Строго говоря, здесь нужно три языка:
Язык, на котором создаётся сама дизайн-система.
Язык, на котором описываются пользовательские интерфейсы. Дизайн-система имеет дело с проектами на таком языке.
Язык конечной реализации, на который транслируются описания на языке №2.
Паразительно то, что всё это давно и хорошо известно в Computer Science. Существует понятие T-диаграммы, имеется метод раскрутки компиляторов и т.д. и т.п.
Интересно посмотреть на это в плане разработки программного обеспечения.
Сначала мы задаём самые общие контуры будущей системы: отвечаем на вопрос, для чего предназначена данная система, что она делает. Это — концептуальный уровень — уровень, на котором нами проясняется общая композиция.
Затем, строится логический уровень системы, где вдоль каждого контура выстраивается общая логика работы приложения. Здесь мы отвечаем на вопрос, как должна быть организована система, как она функционирует.
И уже в самом конце, когда два предыдущих этапа уже пройдены (здесь у нас строгая логическая последовательностью этапов! нельзя что-то пропустить, что-то перескочить, зайти с чёрного входа), наступает этап реализации системы, когда каждая процедура логического уровня приобретает плоть и кровь в виде конкретного программного кода, готового сорваться в бег. Это — физический уровень системы.
Таково идеальное программирование. Наверное...
Это как?
Странно. От заказчика следовало бы ожидать ответа на вопрос "Что ВАМ нужно?" Для чего нужен сайт? Почему нужно начинать с дизайна?
Довольно любопытно прочитать такой бойкий концентрат.
Но какой из этого может быть вывод?
Наерное, лучше всего будет с самого начала иметь некий общий для разных сторон документ, в котором всё расписывается "от печки", начиная с базовых понятий, продолжая методологией разработки и завершая принципами реализации. Это как отчёт о НИР. Каждый этап работы над проектом — раздел отчёта. И все всё будет ясно на каждом этапе.
Увы. Но любой предмет может быть использован "непредметным" способом. Это может привести к проблемам в безопасности. Это может привести к неожиданным эффектам.
Беда современных инструкций — это куцее изложение того, что "для того, чтобы сделать то-то и то-то, надо сделать то-то". Нет вводного раздела с описанием того, а что это за предмет, что в принципе с ним можно сделать. Надо же понимать, что ты делаешь! Мы должны знать, чего ожидать в случае, если мы (случайно или намеренно) произведём определённую последовательность действий.
А где же стандарты? Руководящие документы?
Очень жаль. Всё могло бы быть иначе.