Соглашусь) Это, все, конечно, не отменяет того факта, что все это можно перевести в цифры, скажем так, но факт того что необходимые взаимосвязи и как следствие - решения можно будет простроить только человеку.
Именно необходимые, потому что "правильные", ИИ, теоретически достаточно мощный для этого, найти сможет. Даже если вводных для этого будет очень много. Тут вопрос в обьеме контекста. Но совсем не значит, что правильное технически решение, как бы это странно не звучало, будет являться именно тем, которое нужно нам, как владельцу системы
Соглашусь, но есть одно но). Тренд - трендом, модели будут лучше, не спорю. Но статья не про “модели пока не умеют”. Модели, уже сейчас, умеют устрашающе много)
Большинство описанных проблем не имеют технического ответа, пока кто-то не решит, какое поведение МЫ хотим - а это не вопрос способностей модели. Да, создание подешевело, но не реальная цена решения. Для остального мира это подарок, а для нас - вовсе не конец. Напротив, вижу огромный потенциал в смежных с написанием кода направлениях. Профессия не умирает, но сильно меняется.
Сложно не согласиться, но я немного про другое. Эти вещи я не добавил явно не потому, что считаю их неважными, а потому что для меня они уже есть в описанных подходах. В статье гонка в useEffect лечится не пунктом "предусмотри гонку" в промпте, а тем, что серверное состояние живёт в react-query - там результат привязан к ключу запроса, а не к порядку ответов, и гонка перестаёт быть проблемой (в статье это на примере useQuery с queryKey и keepPreviousData показано). Форма брони, которая зависает при отвале сети - это про useMutation и правила сборки, а не про отдельную строчку.
Так что "сеть, сессия, гонки" - для меня, скорее, следствие стека и правил, а не пропущенный пункт. Мы просто смотрим на "и так далее" по-разному - и это окей)
Соглашусь) Это, все, конечно, не отменяет того факта, что все это можно перевести в цифры, скажем так, но факт того что необходимые взаимосвязи и как следствие - решения можно будет простроить только человеку.
Именно необходимые, потому что "правильные", ИИ, теоретически достаточно мощный для этого, найти сможет. Даже если вводных для этого будет очень много. Тут вопрос в обьеме контекста. Но совсем не значит, что правильное технически решение, как бы это странно не звучало, будет являться именно тем, которое нужно нам, как владельцу системы
Не менее главным является - умение находить такие места. Потому что не всегда, все может быть так очевидно, как в примерах статьи.
Соглашусь, но есть одно но). Тренд - трендом, модели будут лучше, не спорю. Но статья не про “модели пока не умеют”. Модели, уже сейчас, умеют устрашающе много)
Большинство описанных проблем не имеют технического ответа, пока кто-то не решит, какое поведение МЫ хотим - а это не вопрос способностей модели. Да, создание подешевело, но не реальная цена решения. Для остального мира это подарок, а для нас - вовсе не конец. Напротив, вижу огромный потенциал в смежных с написанием кода направлениях. Профессия не умирает, но сильно меняется.
Сложно не согласиться, но я немного про другое.
Эти вещи я не добавил явно не потому, что считаю их неважными, а потому что для меня они уже есть в описанных подходах.
В статье гонка в useEffect лечится не пунктом "предусмотри гонку" в промпте, а тем, что серверное состояние живёт в react-query - там результат привязан к ключу запроса, а не к порядку ответов, и гонка перестаёт быть проблемой (в статье это на примере useQuery с queryKey и keepPreviousData показано).
Форма брони, которая зависает при отвале сети - это про useMutation и правила сборки, а не про отдельную строчку.
Так что "сеть, сессия, гонки" - для меня, скорее, следствие стека и правил, а не пропущенный пункт. Мы просто смотрим на "и так далее" по-разному - и это окей)