Этот ИИ никогда не научиться объяснять что и зачем он напрограммировал.
Потому что он программирует не сам, и вообще думать не умеет.
Он умеет делать из промпта шаблон запроса, ищет ответы, выбирает нужное по весам (статистике), делает из ответов шаблоны, производит над ними операции (агрегации, подстановки).
Вот и всë!
Это, действительно, удобно и эффективно, но это только вспомогательный инструмент, не голова.
И проблема не столько в отладке, сколько в поддержке, если перебарщивать с использованием агента и не проверять, не знать что в системе меняется.
И главное, многие стартапы и островы проектов, частей проекта, похожи. Такой код просто найти. Когда начинается развитие, детали, нестандартные задачи у агента начинаются галлюцинации. Ему негде найти и скопипастить.
По сути, ИИ агент это автоматизированный процесс программирования методом копипаста. Конечно оснащëнный разными крутилками и вертелками.
А не может описанная в статье проблема возникать в случае чрезмерного использования агента? Привыкая к агентскому режиму начинаешь давать ему всë подряд, даже то, что быстрее сделать самому хоткеями, чем надиктовывать и поправлять?
Стандартные вещи, особенно требующие объемной механической работы -- агенту. То, что быстрее сделать самому -- агенту не давать.
Конечно, эту границу нужно нащупать опытным потом, но стремиться к гармонии.
Насколько я знаю, JTA, JMS, JPA, RMI не поддерживаются и не планируется.
Tomcat, как вы точно процитировали, web-сервер. Не является реализацией ключевых стандартов EE, не претендует на роль сервера приложений.
Есть пул соединений и потоков, транзакции на уровне JDBC.
Если есть примеры, когда на нëм делали без всяких Spring и других фреймворков большие корпоративные приложения, или был опыт развëртывания большого кластера, было бы интересно почитать.
У каждого варианта есть свой набор характеристик: реализация стандартов Jakarta EE, готовый / конструктор, стоимость, ресурсоëмкость, реактивность.
Насколько я понял из статьи, Digital Q.AppServer является не опцией для выбора, а скорее аркестратором.
Если целью статьи был Digital Q.AppServer, то было бы честно так и назвать статью, и рассказать какие возможности есть у него, какие преимущества перед существующими способами сопровождения и мониторинга группы Java-серверов для web.
Если таких статей не будет, то ИИ не на чем будет учиться. Появляются новые версии и функции, если никто не будет рассказывать, спрашивать и отвечать, победивший ChatGPT ничем помочь не сможет!
Постойте, постойте...
Но нам же обещали, что ИИ освободит человечество от грубой, тупой, вредной работы, чтобы все занимались творческим и интеллектуальным созиданием!
А не поработит...
Этот ИИ никогда не научиться объяснять что и зачем он напрограммировал.
Потому что он программирует не сам, и вообще думать не умеет.
Он умеет делать из промпта шаблон запроса, ищет ответы, выбирает нужное по весам (статистике), делает из ответов шаблоны, производит над ними операции (агрегации, подстановки).
Вот и всë!
Это, действительно, удобно и эффективно, но это только вспомогательный инструмент, не голова.
И проблема не столько в отладке, сколько в поддержке, если перебарщивать с использованием агента и не проверять, не знать что в системе меняется.
И главное, многие стартапы и островы проектов, частей проекта, похожи. Такой код просто найти. Когда начинается развитие, детали, нестандартные задачи у агента начинаются галлюцинации. Ему негде найти и скопипастить.
По сути, ИИ агент это автоматизированный процесс программирования методом копипаста. Конечно оснащëнный разными крутилками и вертелками.
А не может описанная в статье проблема возникать в случае чрезмерного использования агента? Привыкая к агентскому режиму начинаешь давать ему всë подряд, даже то, что быстрее сделать самому хоткеями, чем надиктовывать и поправлять?
Стандартные вещи, особенно требующие объемной механической работы -- агенту. То, что быстрее сделать самому -- агенту не давать.
Конечно, эту границу нужно нащупать опытным потом, но стремиться к гармонии.
Насколько я знаю, JTA, JMS, JPA, RMI не поддерживаются и не планируется.
Tomcat, как вы точно процитировали, web-сервер. Не является реализацией ключевых стандартов EE, не претендует на роль сервера приложений.
Есть пул соединений и потоков, транзакции на уровне JDBC.
Если есть примеры, когда на нëм делали без всяких Spring и других фреймворков большие корпоративные приложения, или был опыт развëртывания большого кластера, было бы интересно почитать.
Выбор, на мой взгляд, намного богаче и формулируется не так.
Tomcat это не сервер приложений, а контейнер сервлетов.
И если подходить с точки зрения задач, то я бы выделил 3 ниши:
1 Встроенные серверы (embedded)
2 Отдельные web-серверы
3 Серверы приложений (корпоративные приложения)
Для каждой ниши есть свои варианты (это только из того, что я знаю, выбор намного больше):
1 Jetty, Netty, Tomcat (embedded), Vert.x
2 Jetty (standalone), Tomcat, Vert.x (mod.web / +Spring / +Quarkus)
3 GlassFish, WildFly, JBoss EAP, WebSphere, WebLogic, Tomcat (Spring), Vert.x (mod.* / +Spring / +Quarkus)
У каждого варианта есть свой набор характеристик: реализация стандартов Jakarta EE, готовый / конструктор, стоимость, ресурсоëмкость, реактивность.
Насколько я понял из статьи, Digital Q.AppServer является не опцией для выбора, а скорее аркестратором.
Если целью статьи был Digital Q.AppServer, то было бы честно так и назвать статью, и рассказать какие возможности есть у него, какие преимущества перед существующими способами сопровождения и мониторинга группы Java-серверов для web.
Если таких статей не будет, то ИИ не на чем будет учиться. Появляются новые версии и функции, если никто не будет рассказывать, спрашивать и отвечать, победивший ChatGPT ничем помочь не сможет!
Ассистент и агент это ведь не одно и то же.
Ассистент действует по запросу и выполняет одну небольшую задачу.
Агент работает параллельно, с комплексными задачами и учитывая контекст всего проекта и даже сторонних сред.