Search
Write a publication
Pull to refresh
12
0
Send message

Так ведь и есть, в какой проект не ткни - он сложный и уникальный, даже если он внешне кажется простым.

  1. если кто-то захочет за это платить

  2. если бизнес не загнется раньше, из-за очень медленной разработки

решение "делать ли приложение из мусора" принимают не инженеры, а менеджеры

= но советуются то они с инженерами или нет? нельзя же принимать важные решения без экспертных знаний, которыми менеджеры здесь не обладают

"работает же"

= а потом выявится неприятный баг или понадобится новая фича, а в этом говнокоде уже мало кто разберется, включая GPT. Можно нанять опытного программиста, но кто из опытных за это возьмется, за обычную зарплату? Я не возьмусь, я не работаю с ужасным кодом, я уже наступал на эти грабли. Или попрошу зарплату в 2-3 раза выше за такую работу.
Инженер об этом знает, а менеджеры - нет. Хороший менеджер скорее обратится к инженеру за советом в такого рода решениях, потому что инженер - эксперт в написании и поддержке приложений, а менеджер - нет.

Многое из того, что было предсказано без наличия реального опыта не сбылось, и многое превзошло ожидания. Из этого мы можем только сделать вывод, что такие события невозможно предсказать без реального опыта. Никто не знает. что необходимо для создания AGI, и сколько времени на это потребуется, т.к. еще нет опыта создания AGI.

перенесли 30 тысяч приложений продуктов с Java 8 или 11 на более новую версию

== с конвертацией LLM справляется очень хорошо, с этим по-моему никто и не спорит, и такие задачи не требуют инженерного мышления.

не допускающее двояких толкований

== это сложно сделать на человеческом языке, где есть много многозначных или размытых слов

сложную задачу если разбить на маленькие простые подзадачи и подать на вход ИИ

== этот подход бы работал, если бы это было так просто - просто разбить проект на мелкие задачи. А это как раз и требует всего то, что я описал в статье про инженерное мышление. Потому что непродуманная и казалось бы мелочь может вылиться в большие проблемы в будущем. Большой опыт разработки многие такие проблемы быстро выявляет. Над какими-то приходится долго думать. Какие-то выявляются только на практике. Чтобы понять как вообще реализовывать проект из каких частей он должен состоять, нужно заниматься непрерывным исследованием, т.к. проблемы и неожиданности могут быть на каждом шагу, а лучше даже саму разработку превратить в одно большое исследование, побочным результатом которого будет готовый продукт.

Я пытался и пытаюсь до сих пор, год пишу свой пэт-проект лично для себя, чтобы самому этим пользоваться. Я здесь и инженер, и пользователь, и менеджер, я сам себе плачу своим же временем. Использую GitHub copilot активно, даю Claude AI какие-то простые шаблонные задачи, и потом проверяю и исправляю его, на что тоже может уходить час - два, но это все же быстрее чем писать самому. В итоге, по истечению почти года, у меня получилось хорошее и удобное веб приложение, которым я доволен, но его делал в основном я, я принимал все тысячи решений, которые сделали это приложение удобным и которым приятно пользоваться. LLM модели предлагали шаблонные и плохие решения, потому что они не обладают моим опытом, они не могут продумывать будущие проблемы, вместо исследования они лопатой загребают мусор и вываливают в чат, подавая как хорошие решения, или делают вид что что-то исследуют, а в итоге получается тот же мусор. Я даже не знаю возможно ли сделать удобное приложение из мусора, я даже пробовать не хочу, у меня хватает опыта поддержки плохого кода, чтобы в это не вляпываться.

связаны всего лишь с незнанием особенностей применения тех или иных библиотек/фреймворков

Нужно не только знать как применять библиотеки, но еще и когда и какие, какие их функции использовать какие нет, прогнозировать будущее, ведь в будущем возможно придется использовать другую библиотеку, а код уже полностью завязан на использование старой, и выпилить ее уже никак не получается.

ChatGPT от состояния "вообще ничего не могу" до "могу делать простые вещи" прошел за один год.

и 1 млрд долларов

Архитектурно там нет никаких препятствий идти дальше

еще 10 млрд или 100 млрд - не проблема? там ведь рост не линейный, а логарифмический. Так что сразу триллион нужно закладывать чтобы получить что-то стоящее.

GPT не генерирует тексты по шаблонам

Это фундамент GPT модели - генерировать шаблонный текст. И мой огромный опыт общения с ним это подтверждает - он учится на шаблонах и генерирует шаблонные тексты во всех областях, не только в программировании.

"Для многих видов работ генерация текста по шаблонам достаточно"

так он генерирует текст по шаблонам или нет или вы не уверены в этом?

для многих рутинных задач - да, но это не может покрыть написание приложение в целом, только очень малую его часть.

Есть не предпосылки, а реальные продукты тот же гпт и копилот, и альфакод от гугла сейчас способны решать множество задач

GPT и copilot не занимаются инженерией

Такие системы сейчас разрабатываются и будут работать через 1-2 года.

Конечно люди будут пытаться что-то сделать, но это не значит что они сделают это. Вечный двигатель тоже пытались сделать. Нужно полагаться на какие-то объективные критерии чтобы предсказать произойдет что-то или нет. Аналогии не являются такими критериями.
Системы автопрограмирования построены на многократных запросах к ChatGPT. Такая система не способна к обучению на своих ошибках, а напротив склонна повторять свои ошибки. ChatGPT - это предобученная модель, дообучать которую нельзя. Ей можно только скармливать контекст, и моя практика показывает, что с помощью контекста можно только корректировать или форматировать ее ответы, но не обучать ее, она все равно будет полагаться на шаблоны, на которых она обучалась и стараться пропихнуть их везде.

Хорошая архитектура и код никого не волнует, главное чтоб продукт работал.

"главное, чтоб продукт работал" - это и есть одна из целей хорошей архитектуры. Если архитектура будет плохой? то проект быстро зайдет в тупик, когда ничего уже не будет работать и не кому будет это исправить.

Это будет гораздо дешевле любого разработчика, посчитайте цены GPT 4 turbo и разработчика не из страны третьего мира.

Эту цену нужно умножить как минимум на 100, т.к. для разработки программ нужно думать, заниматься инженерией, а мыслительный процесс - это не один, а очень много ChatGPT запросов. Но и из этого ничего не выйдет, т.к. обучать ChatGPT контекстом нельзя, зато легко получить такой заговнокоденый проект, который потом никто не возьмется дорабатывать или за это попросят гораздо большие деньги чем ушло на ChatGPT.

Разве то что я написал не является перечислением доказательств?
Разве чтобы заниматься инженерией достаточно только генерировать тексты по шаблонам?
Разве есть какие-то предпосылки того, что какая-то из современных ИИ моделей способна заниматься инженерией (пробовать идеи на практике, получать опыт, учиться на ошибках, обобщать огромный опыт как это делают опытные разработчики, чтобы изначально писать качественный код с хорошей архитектурой)?

В комментах я уже отвечал почему GPT модели это тупик - они уперлись в денежный потолок. Нужна совершенно новая модель, о которой даже упоминаний нет.

Если у вас есть контр аргументы к моим, то давайте обсудим.

Ускорение развития ИИ нелинейно, оно может как сделать большой прыжок, так и застрять в развитии лет на 10, никто этого не может предсказать.

Программирование - это инженерия. Инженерию нельзя свести к генерации контента. Это все равно что назвать научную деятельность генерацией научных статей. Инженерия предполагает обучение на реальном опыте, исследования, экспериментирование, прогнозирование будущего и т.п.

ChatGPT 4 не справляется даже с простыми задачами, укладывающимися в его небольшой контекст. Проблема здесь не в размере контекста.

который в ряде случаев все равно приемлем, особенно если задачи простые

Здесь еще нужно добавить, что это касается простых проектов в целом, не предполагающих развития. Если проект предполагается большой, то читайте о проблеме экспоненциального роста сложности приложения, которая привела к необходимости создания качественной архитектуры и написания качественного кода. А в архитектуре ChatGPT полный ноль. Следование принципу "и так сойдет" может в конечном итоге убить большой проект до того как он себя окупит или вообще начнет приносить прибыль.

Братья Райт создали самолет в 1903. Первый самолет пересек Атлантику в 1919, спустя 16 лет. Я здесь и не говорю, что программирующего ИИ никогда не будет, я говорю что его не будет в ближайшие 10-20 лет и обосновываю это не тем, что современный ИИ еще молодой и хромает на обе ноги, а тем что у самой модели ИИ нет и не предвидится тех важных способностей, которые позволили бы ей заниматься инженерией, а не просто генерацией текстов. Если появится какая-то другая модель ИИ, я изменю свое мнение. А сейчас это равносильно научной фантастике. Мы не знаем даже возможно ли создать такую модель с нашими текущими технологиями. Что тут вообще можно спрогнозировать?

Да, ChatGPT 4 создает заметно более качественный код, но он все еще остается говнокодом. Он может хорошо писать только такие куски кода, которыми и так уже завален весь интернет и учебники по программированию.

Какие есть перспективы развития этой модели?

Стоимость обучения ChatGPT 3 оценивается в 2-12 миллионов долларов. Стоимость графических чипов - 800 миллионов долларов (статья февральская, тогда еще не было ChatGPT 4).
https://www.techgoing.com/how-much-does-chatgpt-cost-2-12-million-per-training-for-large-models/
Создание ChatGPT стало возможным только благодаря большим инвестициям от Microsoft.

Зависимость интеллектуальных возможностей этой модели от количества параметров и объема данных не является линейной. ChatGPT 4 обучали на в 100 раз большем объеме данных и имеет в 100 раз больше параметров чем ChatGPT 3.5. Но он не стал от этого в 100 раз умнее, может только раз в 5.

Так что эта модель - это тупик, ей уже некуда развиваться.

Программирование - это не генерация контента. Перечитайте первую часть статьи о том, что требуется для того чтобы создать ИИ умеющий программировать. Сейчас нет даже эффективной модели ИИ, которая теоретически в далеком будущем позволит это сделать. И огромный размер контекста тут ничем не поможет.
Сами можете в этом убедиться, сейчас ChatGPT 4 поддерживает довольно большой размер контекста, а пишет все равно говнокод.

Ближайшее будущее в этой статье - это 10-20 лет. На 100 лет я не готов делать прогнозы.

Да, ИИ здесь не имеет строгого определения, и это здесь не так важно. В общем случае я называю ИИ все то, что может в какой-то степени заменить интеллектуальную работу человека. Я понимаю, что под это определение можно и калькулятор подвести, но мы говорим о достаточно сильном инструменте, который превосходит все предыдущие. Если изобретут машину умеющую программировать без нейросетей, то это будет сильный ИИ.

А почему вы думаете, что сильный ИИ это инструмент в руках человека (-разработчика), а не наоборот?

Потому что ИИ создает человек, и конечно человек будет стремиться создавать его таким, чтобы он работал на человека, а не наоборот. Если речь о том, что в какой-то момент человек потеряет власть над ИИ, то это уже тема для научной фантастики, мы не можем сейчас делать такие долгосрочные прогнозы на 100 и более лет вперед.

Про BEM + Tailwind, я же говорю, что технически это можно сделать, но чтобы говорить о такой архитектуре нужен большой опыт, хотя бы два года разработки проектов и желательно с нуля и с дальнейшей поддержкой. Пока не соберешь все подводные камни, хорошей архитектуры не построишь.

Я уже вижу здесь те же проблемы: если использовать @apply, то это создаст дополнительную работу по конвертации стилей в уме: и когда читаешь код, и когда исправляешь что-то в DevTools и хочешь перенести изменения в код. Если писать Tailwind классы в HTML, то плюс к этому добавляется еще и дополнительная работа по отсеиванию мусора, когда анализируешь HTML. Но возможно Tailwind будет удобен, если весь проект использует utility-first подход к верстке. И на Tailwind можно верстать без дизайнера. В любом случае нужен реальный и большой опыт, чтобы в этом разобраться.

пишешь jsx-элемент с атрибутом className

== я не нашел там автоматической изоляции стилей, или какой-то удобный способ одновременно использовать и BEM и изоляцию стилей. Svelte автоматически добавляет класс .s- к каждому селектору и к каждому html элементу. React, как я понял, такое не может. И если и использовать там BEM, то только как глобальные классы.

Я сжал gzip-ом большой CSS одного реального проекта с 2929KB до 75KB (сжатие в 40 раз), проект был на BEM.
Для эксперимента я сжал CSS страницы GitHub в 794KB до 111KB (сжатие в 7 раз), он на половину на Tailwind.

1

Information

Rating
Does not participate
Registered
Activity