Я кстати нашёл язык, минимально из мэйнстрима, который идеально подходит в качестве протокола общения с LLM-ками.
Это ЛИСП! )))
Что смешного? Ну, лисперы в своё время считались куда хардкорнее чем сегодня хаскелисты и юникс/линукс-оиды. А уровень токсичности темки вообще зашкаливал :)
Ну я подскочил и резко въехал ему в щщи с вертушки и пояснил криком "не люблю ооп", потому что я угорел по лиспу, пацаны дух старой школы живёт только в функциональном программировании, где угорают по хардкору, где пацаны живут линейными символами и хвостовой рекурсией! только лисп только функции, только скобки!!! юнити ультрахардкор лисп!!! пацаны угарайте по рекурсии любите лисп, списки и скобки! говорите открыто и смело прямо в лицо! ЛИСП!
Точнее, сегодня это Racket (потомок Scheme).
Чистый АланКеевский путь - язык описывает сам себя.
Плюс: это буквально родной инструмент для создания DSL.
Минус: далековат от прода, хотя... Поддерживают Racket финансово NSF, DARPA и др.
Racket is a language for making languages, so that a programmer can write every module in a well-suited language.
Often an application domain comes with several languages. When you need a new language, you make it - on the fly. Open an IDE window; create a language right there, with just a few keystrokes; and run a module in this new language in a second IDE window. Making new languages really requires no setup, no project files, no external tools, no nothing.
Вот реально, колеблюсь между хакселем и ракетом. Мощная формальная математика и система типов против абсолютной гибкости (кстати именно racket код нейронкам заходит лучше всего).
Это ЛИСП! )))
Что смешного? Ну, лисперы в своё время считались куда хардкорнее чем сегодня хаскелисты и юникс/линукс-оиды. А уровень токсичности темки вообще зашкаливал :)
Ну я подскочил и резко въехал ему в щщи с вертушки и пояснил криком "не люблю ооп", потому что я угорел по лиспу, пацаны дух старой школы живёт только в функциональном программировании, где угорают по хардкору, где пацаны живут линейными символами и хвостовой рекурсией! только лисп только функции, только скобки!!! юнити ультрахардкор лисп!!! пацаны угарайте по рекурсии любите лисп, списки и скобки! говорите открыто и смело прямо в лицо! ЛИСП!
Точнее, сегодня это Racket (потомок Scheme).
Чистый АланКеевский путь - язык описывает сам себя.
(define-language my-domain
(agent (knows abstractions) (does task)))
Плюс: это буквально родной инструмент для создания DSL.
Минус: далековат от прода, хотя... Поддерживают Racket финансово NSF, DARPA и др.
Racket is a language for making languages, so that a programmer can write every module in a well-suited language.
Often an application domain comes with several languages. When you need a new language, you make it - on the fly. Open an IDE window; create a language right there, with just a few keystrokes; and run a module in this new language in a second IDE window. Making new languages really requires no setup, no project files, no external tools, no nothing.
Вот реально, колеблюсь между хакселем и ракетом. Мощная формальная математика и система типов против абсолютной гибкости (кстати именно racket код нейронкам заходит лучше всего).
👍30❤12✍9⚡7
Красивое: GlimpseOfLean : an introduction to theorem proving in Lean for the impatient.
Вот секретная ссылочка на код, в самом низу которой есть ссылочка на онлайн-версию. Просто симпатичная обучалка тактикам лина, а если ставите курсор на строчку, то видно как меняются значения переменных.
Евросообщество Lean4 доступ к своему сервису для России уже давно закрыло (как и к Racket кстати), поэтому можно в этот онлайн зайти только через впн, ну а так как скоро и эти три буквы у нас будут тотально ликвидированы и потеряется доступ к тысячам важнейших мировых математических и компьютерных ресурсов
(как например Калифорнийский университет Беркли, который на днях (следом за Йелем) признали нежелательной экстремистской организацией, и даже просто за ссылки на его научные труды - или за использование FreeBSD :) - можно легко получить штраф, если не что похуже -- от низовых исполнителей для лёгкой статистики, разбираться никто не будет),
рекомендую скачать себе локально весь GlimpseOfLean кому интересно, пока ещё не поздно. Ну и вообще готовимся к самому худшему. На моей жизни я уже ничего позитивного не жду.
p.s. Забыл, в их последнем деплое закомментите
import Mathlib.Data.Complex.Trigonometric
Вот секретная ссылочка на код, в самом низу которой есть ссылочка на онлайн-версию. Просто симпатичная обучалка тактикам лина, а если ставите курсор на строчку, то видно как меняются значения переменных.
Евросообщество Lean4 доступ к своему сервису для России уже давно закрыло (как и к Racket кстати), поэтому можно в этот онлайн зайти только через впн, ну а так как скоро и эти три буквы у нас будут тотально ликвидированы и потеряется доступ к тысячам важнейших мировых математических и компьютерных ресурсов
(как например Калифорнийский университет Беркли, который на днях (следом за Йелем) признали нежелательной экстремистской организацией, и даже просто за ссылки на его научные труды - или за использование FreeBSD :) - можно легко получить штраф, если не что похуже -- от низовых исполнителей для лёгкой статистики, разбираться никто не будет),
рекомендую скачать себе локально весь GlimpseOfLean кому интересно, пока ещё не поздно. Ну и вообще готовимся к самому худшему. На моей жизни я уже ничего позитивного не жду.
p.s. Забыл, в их последнем деплое закомментите
import Mathlib.Data.Complex.Trigonometric
🔥30✍13❤8👍1
У нас уже и были, и остаются огромные проблемы с объёмом легаси-кода, который существовал, когда его писали люди. Почему мы думаем, что ускорение этого процесса будет улучшением?? )))
Откуда мы знаем, что терабайты вайб-кода вообще работают?
Наиболее распространённый ответ: я просмотрел код, прогнал тесты, и все в порядке.
Именно здесь дальнейшее обсуждение становится затруднительным, потому что трудно ответить на это утверждение конструктивно, не рискуя обидеть людей :)
Более того, сколько бы ни было ошибок в проде, и сколь бы сильно не росло их количество при вайб-кодинге, как только вы фиксите очередной баг, тимлид продолжает верить, что код-ревью может предотвратить баги в будущем, хотя их частота лишь растёт.
(В целом странно конечно, что умение хорошо просматривать код теперь гораздо более ценно, чем умение хорошо писать код.)
TDD? Да, это мощная штука, близкая к формальным спецификациям, если ей следовать вдумчиво, но как вы проверите, что агент действительно этому следует? На уровне агентов это чистый карго-культ. Агент заявит, что якобы тестирует систему, и даже следует базе "красный-зелёный-рефакторинг", но откуда вы знаете, что это не симуляция? Что это, весьма вероятно, программа, которая только выглядит так, как будто она проходит все тесты, но на самом деле не имеет отношения к реальным требованиям?
Вместо того, чтобы самому/агентами писать код в прод, и затем просить нейронку покрыть это всё тестами, почему бы не написать сперва тесты, и только потом не попросить агентов реализовать их?
Ну, по какой-то причине, которую я никогда не понимал, 98% разработчиков не нравится писать тесты, так что это, вероятно, тоже нереально.
Если вы не участвуете в создании тестов, вы не можете сказать, какие гарантии они дают (и дают ли хоть какие-то гарантии вообще). И тогда тестирование становится простой церемонией, призванной подарить вам приятное тёплое чувство без реальной защиты.
Ну ладно мэйнстриновские проекты, фиг с ними, с интересами пользователей в них никогда не считались, и десятилетиями сбрасывали на юзеров все проблемы с выявлением багов в духе "раннего доступа".
Но что насчёт КИИ? Или даже немного более широкая тема: софт, где качество -- реально ключевой критерий, и поэтому так важны подходы по проверке и обеспечению корректности кода. Мы сегодня видим экспоненциальный рост объёма софта, создаваемого нейронками, в то время как объёмы (около)критического кода остаются пропорционально сопоставимыми ручным объёмам. Ну, потому что эту цифру трудно масштабировать.
К сожалению, я также ожидаю, что всё больше подобных систем будут оказываться ненадёжными вследствие бесконтрольного распространения вайб-кодинга, и будут потеряны (и уже теряются) и огромные финансы, и жизни. И более того, выводов из этого, как и до сего дня, никто не сделает (что будет легко измеряемо по росту критических сбоев КИИ по самым разным причинам).
Откуда мы знаем, что терабайты вайб-кода вообще работают?
Наиболее распространённый ответ: я просмотрел код, прогнал тесты, и все в порядке.
Именно здесь дальнейшее обсуждение становится затруднительным, потому что трудно ответить на это утверждение конструктивно, не рискуя обидеть людей :)
Более того, сколько бы ни было ошибок в проде, и сколь бы сильно не росло их количество при вайб-кодинге, как только вы фиксите очередной баг, тимлид продолжает верить, что код-ревью может предотвратить баги в будущем, хотя их частота лишь растёт.
(В целом странно конечно, что умение хорошо просматривать код теперь гораздо более ценно, чем умение хорошо писать код.)
TDD? Да, это мощная штука, близкая к формальным спецификациям, если ей следовать вдумчиво, но как вы проверите, что агент действительно этому следует? На уровне агентов это чистый карго-культ. Агент заявит, что якобы тестирует систему, и даже следует базе "красный-зелёный-рефакторинг", но откуда вы знаете, что это не симуляция? Что это, весьма вероятно, программа, которая только выглядит так, как будто она проходит все тесты, но на самом деле не имеет отношения к реальным требованиям?
Вместо того, чтобы самому/агентами писать код в прод, и затем просить нейронку покрыть это всё тестами, почему бы не написать сперва тесты, и только потом не попросить агентов реализовать их?
Ну, по какой-то причине, которую я никогда не понимал, 98% разработчиков не нравится писать тесты, так что это, вероятно, тоже нереально.
Если вы не участвуете в создании тестов, вы не можете сказать, какие гарантии они дают (и дают ли хоть какие-то гарантии вообще). И тогда тестирование становится простой церемонией, призванной подарить вам приятное тёплое чувство без реальной защиты.
Ну ладно мэйнстриновские проекты, фиг с ними, с интересами пользователей в них никогда не считались, и десятилетиями сбрасывали на юзеров все проблемы с выявлением багов в духе "раннего доступа".
Но что насчёт КИИ? Или даже немного более широкая тема: софт, где качество -- реально ключевой критерий, и поэтому так важны подходы по проверке и обеспечению корректности кода. Мы сегодня видим экспоненциальный рост объёма софта, создаваемого нейронками, в то время как объёмы (около)критического кода остаются пропорционально сопоставимыми ручным объёмам. Ну, потому что эту цифру трудно масштабировать.
К сожалению, я также ожидаю, что всё больше подобных систем будут оказываться ненадёжными вследствие бесконтрольного распространения вайб-кодинга, и будут потеряны (и уже теряются) и огромные финансы, и жизни. И более того, выводов из этого, как и до сего дня, никто не сделает (что будет легко измеряемо по росту критических сбоев КИИ по самым разным причинам).
1👍34❤9✍8
Фигня этот ваш жпт5.4.
Попросил его написать скрипт на питоне где-то на 500 строк, причём вся логика линейная, просто надо условно говоря давать агентам те или иные инструкции в зависимости от десятка счётчиков. Так он начал концептуально тупить уже на первых 50 строках, кое-как вроде что-то собрал, где-то час я на общение с ним потратил, а как стал тестировать, и оказалось, что он так всё напутал со счётчиками, что надо вообще всё переделывать заново с нуля, а если делать точечные фиксы, то он сразу превращает всё в little ball of mud. А внимательный джун сделал бы, ну пусть за 4 часа, но как минимум чтобы всё работало по тикету.
Так что замена программистов на эйай таки пока что явно откладывается :) Понятно, что можно давить грубой силой -- запущать тучи агентов, которые будут перебором искать подходящий вариант миллионами токенов, но это же какая-то глупость...
Попросил его написать скрипт на питоне где-то на 500 строк, причём вся логика линейная, просто надо условно говоря давать агентам те или иные инструкции в зависимости от десятка счётчиков. Так он начал концептуально тупить уже на первых 50 строках, кое-как вроде что-то собрал, где-то час я на общение с ним потратил, а как стал тестировать, и оказалось, что он так всё напутал со счётчиками, что надо вообще всё переделывать заново с нуля, а если делать точечные фиксы, то он сразу превращает всё в little ball of mud. А внимательный джун сделал бы, ну пусть за 4 часа, но как минимум чтобы всё работало по тикету.
Так что замена программистов на эйай таки пока что явно откладывается :) Понятно, что можно давить грубой силой -- запущать тучи агентов, которые будут перебором искать подходящий вариант миллионами токенов, но это же какая-то глупость...
🤔33❤11👍11✍3🤯2
Продолжаю работу с ментатами (и ментатками 🌷) 🤓
5 задач ужасающей сложности оказались правда ужасающими сложными для меня. С такой сложной схемой БД, где более 50 таблиц, мне работать не приходилось. И задачи правда оказались невероятно сложными с требованием сложной аналитики. Обычно в работе сталкиваюсь с БД до 10-15 таблиц, а то и меньше.
Очень сложно (практически невозможно) выполнять такую работу с незнакомыми для тебя сущностями. Я привык к продажам, остаткам, логистике, БД различных пользовательских сервисов. С играми я никогда не работал. И продумывать аналитику влияния погоды на атаки или влияние лунной фазы на что-то невероятно сложно. И все это без боевых данных...
Получили трёхкратную разницу. Я не ожидал, что hibernate будет тащить так много лишних данных. В изначальном варианте с orm было очень много джоинов. Кажется это связано с тем, что сущности тесно связаны друг с другом и такая длинная цепочка джоинов является попыткой распутать клубок связей. Однако данные, которые достаются с помощью такого объёмного запроса нам не нужны и эти длинные запросы избыточны...
Однажды я полагал, что в одном из методов данные выдаются в упорядоченном виде, ну и закладывался на такое поведение. Потом выяснилось, что во время проверок так складывались звёзды и данные выдавались по возрастанию id...
Для себя я сформулировал простой принцип, который хочу применять дальше: перед тем как писать или менять код, стоит задать себе вопросы «зачем это существует?», «в каком месте системы это используется?» и «что нельзя делать с этим кодом». Если ответы не очевидны из сигнатур и структуры — они должны быть записаны в комментариях...
Тесты не спасают от всех багов — только от тех, на которые ты догадался написать проверку.
Например, что должен вернуть метод CalculateAverage для массива { 1, 2 } — 1 или 1.5? Если такой тест не написан,
баг может жить в коде годами, пока кто-нибудь не столкнётся с ним в продакшене...
Если честно, то я не задумывался о таких мелочах. Теперь понимаю, насколько это было недальновидно. Особенно мне казалось использование словаря в подобных случаях избыточным. Теперь вижу, что result['fresh_messages'] намного понятнее, чем fresh, old = some_function(). Не нужно держать в голове порядок возвращаемых элементов.
На будущее:
Нужно регулярно задавать себе вопрос: "А не скрыта ли здесь логическая связь?"
Чаще использовать словарь вместо кортежа...
Вообще, все больше и больше кажется, что иду (скажем мягко) не очень верным путем. Но тут, наверное, надо однозначно упереться в уже явный тупик, чтобы по факту можно было проанализировать свои шаги, которые туда и привели...
Затем я попытался достичь 10k RPS создав 10 тысяч пользователей(хотя для такого rps это, как будто, много). Но прогон завершился с ошибками и я даже не получил отчёт. Ещё впервые за долгое время услышал как мак гудит вентиляторами :)
По дипломному проекту, по заданию 42 следующий результат: поработал со Swagger. Самое для меня странное, что мы ведем документацию на апи в Swagger (все описание делаем вручную) - а я даже не в курсе был, что он может это все сам генерировать...
Чувствую, что надо переходить к AI-темкам, так как бизнес хочет вокруг AI строить все решения.
...В этом проекте я вообще максимально долго пытался сохранить монолит, но так как приходит вторая большая команда, то придется делить его как минимум на 2 (микро)сервиса, чтобы команды не толкались в одной кодовой базе...
Ну, "поделить монолит на несколько частей и будет проще автономным командам", это уже многократно проверенная иллюзия. Сейчас весь FAANG наоборот уходит в монолиты, на днях как раз несколько постов на эту тему выложу. Кодовую базу надо делить не на микросервисы (это техническое решение), а на правильную доменную логику, из которой архитектура будет следовать уже естественно и легко.
Как? Вот уже прям в марте будет вам гайд "Функциональные Архитектуры" 🔥
5 задач ужасающей сложности оказались правда ужасающими сложными для меня. С такой сложной схемой БД, где более 50 таблиц, мне работать не приходилось. И задачи правда оказались невероятно сложными с требованием сложной аналитики. Обычно в работе сталкиваюсь с БД до 10-15 таблиц, а то и меньше.
Очень сложно (практически невозможно) выполнять такую работу с незнакомыми для тебя сущностями. Я привык к продажам, остаткам, логистике, БД различных пользовательских сервисов. С играми я никогда не работал. И продумывать аналитику влияния погоды на атаки или влияние лунной фазы на что-то невероятно сложно. И все это без боевых данных...
Получили трёхкратную разницу. Я не ожидал, что hibernate будет тащить так много лишних данных. В изначальном варианте с orm было очень много джоинов. Кажется это связано с тем, что сущности тесно связаны друг с другом и такая длинная цепочка джоинов является попыткой распутать клубок связей. Однако данные, которые достаются с помощью такого объёмного запроса нам не нужны и эти длинные запросы избыточны...
Однажды я полагал, что в одном из методов данные выдаются в упорядоченном виде, ну и закладывался на такое поведение. Потом выяснилось, что во время проверок так складывались звёзды и данные выдавались по возрастанию id...
Для себя я сформулировал простой принцип, который хочу применять дальше: перед тем как писать или менять код, стоит задать себе вопросы «зачем это существует?», «в каком месте системы это используется?» и «что нельзя делать с этим кодом». Если ответы не очевидны из сигнатур и структуры — они должны быть записаны в комментариях...
Тесты не спасают от всех багов — только от тех, на которые ты догадался написать проверку.
Например, что должен вернуть метод CalculateAverage для массива { 1, 2 } — 1 или 1.5? Если такой тест не написан,
баг может жить в коде годами, пока кто-нибудь не столкнётся с ним в продакшене...
Если честно, то я не задумывался о таких мелочах. Теперь понимаю, насколько это было недальновидно. Особенно мне казалось использование словаря в подобных случаях избыточным. Теперь вижу, что result['fresh_messages'] намного понятнее, чем fresh, old = some_function(). Не нужно держать в голове порядок возвращаемых элементов.
На будущее:
Нужно регулярно задавать себе вопрос: "А не скрыта ли здесь логическая связь?"
Чаще использовать словарь вместо кортежа...
Вообще, все больше и больше кажется, что иду (скажем мягко) не очень верным путем. Но тут, наверное, надо однозначно упереться в уже явный тупик, чтобы по факту можно было проанализировать свои шаги, которые туда и привели...
Затем я попытался достичь 10k RPS создав 10 тысяч пользователей(хотя для такого rps это, как будто, много). Но прогон завершился с ошибками и я даже не получил отчёт. Ещё впервые за долгое время услышал как мак гудит вентиляторами :)
По дипломному проекту, по заданию 42 следующий результат: поработал со Swagger. Самое для меня странное, что мы ведем документацию на апи в Swagger (все описание делаем вручную) - а я даже не в курсе был, что он может это все сам генерировать...
Чувствую, что надо переходить к AI-темкам, так как бизнес хочет вокруг AI строить все решения.
...В этом проекте я вообще максимально долго пытался сохранить монолит, но так как приходит вторая большая команда, то придется делить его как минимум на 2 (микро)сервиса, чтобы команды не толкались в одной кодовой базе...
Ну, "поделить монолит на несколько частей и будет проще автономным командам", это уже многократно проверенная иллюзия. Сейчас весь FAANG наоборот уходит в монолиты, на днях как раз несколько постов на эту тему выложу. Кодовую базу надо делить не на микросервисы (это техническое решение), а на правильную доменную логику, из которой архитектура будет следовать уже естественно и легко.
Как? Вот уже прям в марте будет вам гайд "Функциональные Архитектуры" 🔥
👍37❤13✍2
Решил расширить свои лингвистические/блогерские изыскания немного в сторону художественную. Если программирование пока ещё сопротивляется пришествию AI, то вот художественную литературу пора уже уничтожать более чем полностью :) Ну, и там и там мэйнстрим/попсу/хипстерство имею в виду конечно.
И код, и текст, и музыка, и картинки сами по себе не будут помоями только потому, что созданы искусственным интеллектом. Код, текст, музыка и картинки будут помоями независимо от того, кто их автор (белковый или цифровой) -- они помои просто потому, что они помои.
И у кода, и у худ.текста очень много общего, причем как in small, так и in large. Я за свою жизнь прочитал немалые тысячи книг (и продолжаю активно), из них немало по лингвистике и литературоведению (у нас в редакции в 90-е работали суровые литературные редакторы советской школы), и на лит.курсах занимался, и вот теперь хочу в заключение немного поэкспериментировать в смежной сфере.
Книги пишутся обычно по двум схемам.
Инженерная (чистое графоманство, или даже скорее литературное цыганство :) -- это когда структура/схема/сюжет книги продумываются заранее достаточно подробно (примерно как проектируем программный проект на абстрактных уровнях), и потом на такую рыбу наращивается мясо -- непосредственно текст. По такой схеме пишут 98% бесталанных авторов, мечтающих издасться ради тщеславия, ну и практически все коммерческие авторы, попавшие в струю. Со временем они всё дальше и дальше уходят в "проектирование" рыб своих книг, а к их реализации для ускорения темпа массово привлекаются дешёвые литературные негры. Никакого творчества, просто бизнес.
Писательская (это удел чистых талантов, но при этом здесь также довольно велик процент сумасшедших :). Автор задумывает некоторую идею, делает конечно какие-то очень схематические наброски, но пишет текст в некотором трансе: на сознательном уровне он реально не знает, как будут вести себя его персонажи! он их просто вводит в контекст и конфликты, задаёт общее направление, но последующий сюжет развивается "естественно" как бы самими персонажами (в подсознании автора).
Вы не поверите, но 80% великих книг были написано именно так. Ну максимум 20% "инженерии".
=
И так как я совершенно бесталанный в художественном плане, то хочу довести до идеала инженерный подход. Ведь "проектирование" книги in large -- это по сути процесс, изоморфный проектированию системы, разве что менее формальный. А нейронки сегодня пишуткод художественный текст вот точно уже лучше 98% не только литературных негров, но профессиональных авторов — на уровне хорошего PhD.
То есть и тут на первый план, как и в IT, выходят скиллы "техлида": качественные замысел, сюжет, драматургия, умение зацепить/увлечь, примерно как и в геймдеве кстати. Ну и стиль/in small самого текста конечно важен (как картинка в игре).
Цель тут у меня экспериментальная -- достичь теоретически возможного литературного качества. Потому что так-то сегодня дай нейронке промпт "напиши мне книгу про шпионов в духе Штирлица", и она тебе за час выдаст целую серию книг -- правда, ужасающего качества во всех отношениях...
И код, и текст, и музыка, и картинки сами по себе не будут помоями только потому, что созданы искусственным интеллектом. Код, текст, музыка и картинки будут помоями независимо от того, кто их автор (белковый или цифровой) -- они помои просто потому, что они помои.
И у кода, и у худ.текста очень много общего, причем как in small, так и in large. Я за свою жизнь прочитал немалые тысячи книг (и продолжаю активно), из них немало по лингвистике и литературоведению (у нас в редакции в 90-е работали суровые литературные редакторы советской школы), и на лит.курсах занимался, и вот теперь хочу в заключение немного поэкспериментировать в смежной сфере.
Книги пишутся обычно по двум схемам.
Инженерная (чистое графоманство, или даже скорее литературное цыганство :) -- это когда структура/схема/сюжет книги продумываются заранее достаточно подробно (примерно как проектируем программный проект на абстрактных уровнях), и потом на такую рыбу наращивается мясо -- непосредственно текст. По такой схеме пишут 98% бесталанных авторов, мечтающих издасться ради тщеславия, ну и практически все коммерческие авторы, попавшие в струю. Со временем они всё дальше и дальше уходят в "проектирование" рыб своих книг, а к их реализации для ускорения темпа массово привлекаются дешёвые литературные негры. Никакого творчества, просто бизнес.
Писательская (это удел чистых талантов, но при этом здесь также довольно велик процент сумасшедших :). Автор задумывает некоторую идею, делает конечно какие-то очень схематические наброски, но пишет текст в некотором трансе: на сознательном уровне он реально не знает, как будут вести себя его персонажи! он их просто вводит в контекст и конфликты, задаёт общее направление, но последующий сюжет развивается "естественно" как бы самими персонажами (в подсознании автора).
Вы не поверите, но 80% великих книг были написано именно так. Ну максимум 20% "инженерии".
=
И так как я совершенно бесталанный в художественном плане, то хочу довести до идеала инженерный подход. Ведь "проектирование" книги in large -- это по сути процесс, изоморфный проектированию системы, разве что менее формальный. А нейронки сегодня пишут
То есть и тут на первый план, как и в IT, выходят скиллы "техлида": качественные замысел, сюжет, драматургия, умение зацепить/увлечь, примерно как и в геймдеве кстати. Ну и стиль/in small самого текста конечно важен (как картинка в игре).
Цель тут у меня экспериментальная -- достичь теоретически возможного литературного качества. Потому что так-то сегодня дай нейронке промпт "напиши мне книгу про шпионов в духе Штирлица", и она тебе за час выдаст целую серию книг -- правда, ужасающего качества во всех отношениях...
✍32👍11❤6🔥5🤔4
.
Облако драгоценностей за неделю.
В отчётах по карьере теперь обязательно пояснять, как вы используете AI в своей работе (если не знаете как, я подскажу).
Приватный клуб.
Спецификация — идея в целом полезная. Но есть большой нюанс: синхронизация спецификации как письменного артефакта, с изменяющейся программной системой, требует постоянных затрат, а программисты созданы для серийных работ...
Для донов-начинающих:
С вероятностью 98% обучение теме искусственного интеллекта с обещаниями научить на этом зарабатывать, получить новую профессию — классическая схема мошенничества. И вот почему...
Для донов-неначинающих:
Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
78. Микросервисы должны умереть
Никто из крупных компаний не начинал с микросервисов. Никто не загружался с помощью service mesh. Они начинали с простого. Они развивались осознанно и эволюционно. Они масштабировались, когда к этому вынуждала реальность, а не хайп на конференции.
И после многих лет наблюдения за тем, как компании масштабируются и перестраиваются, вот что сегодня выделяют гуру программной инженерии:
только три модели архитектуры стабильно работают в условиях реального роста...
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В курс карьеры добавлен 129-й материал "Стабильность -- это ловушка".
Чем больше вы обеспечиваете себе безопасность и стабильность (которая на самом деле всегда иллюзорна), тем труднее становится на самом деле пойти на риск (хотя реальный риск прежде всего завязнуть в карьерном болоте)...
В СильныеИдеи добавлен материал "136) SOLID26: LSP".
Единственный в SOLID хороший принцип :) И теперь я понимаю почему: он был изобретён людьми, которые знали математическую теорию типов...
💪🏻
Мы здесь, потому что это трудно.
=
Гайд про функциональные архитектуры, 64 топика (+9), как наберётся 64, дам ментатам доступ :) Мои ближайшие планы на эту весну уже реализовываю в рамках этого гайда.
=
— Это произойдёт, и вы ничего не сможете поделать!
В этих словах прозвучала надменность, свойственная ментатам, когда они попадают на поле своей логики.
"Еретики Дюны"
Облако драгоценностей за неделю.
В отчётах по карьере теперь обязательно пояснять, как вы используете AI в своей работе (если не знаете как, я подскажу).
Приватный клуб.
Спецификация — идея в целом полезная. Но есть большой нюанс: синхронизация спецификации как письменного артефакта, с изменяющейся программной системой, требует постоянных затрат, а программисты созданы для серийных работ...
Для донов-начинающих:
С вероятностью 98% обучение теме искусственного интеллекта с обещаниями научить на этом зарабатывать, получить новую профессию — классическая схема мошенничества. И вот почему...
Для донов-неначинающих:
Продолжаю выкладывать для донов материалы СильныхИдей — доступны моим курсантам, но тут расширенные и дополненные версии.
78. Микросервисы должны умереть
Никто из крупных компаний не начинал с микросервисов. Никто не загружался с помощью service mesh. Они начинали с простого. Они развивались осознанно и эволюционно. Они масштабировались, когда к этому вынуждала реальность, а не хайп на конференции.
И после многих лет наблюдения за тем, как компании масштабируются и перестраиваются, вот что сегодня выделяют гуру программной инженерии:
только три модели архитектуры стабильно работают в условиях реального роста...
(все старые материалы для донов быстро сгорают)
=
Новые материалы для ментатов Лаборатории.
В курс карьеры добавлен 129-й материал "Стабильность -- это ловушка".
Чем больше вы обеспечиваете себе безопасность и стабильность (которая на самом деле всегда иллюзорна), тем труднее становится на самом деле пойти на риск (хотя реальный риск прежде всего завязнуть в карьерном болоте)...
В СильныеИдеи добавлен материал "136) SOLID26: LSP".
Единственный в SOLID хороший принцип :) И теперь я понимаю почему: он был изобретён людьми, которые знали математическую теорию типов...
💪🏻
Мы здесь, потому что это трудно.
=
Гайд про функциональные архитектуры, 64 топика (+9), как наберётся 64, дам ментатам доступ :) Мои ближайшие планы на эту весну уже реализовываю в рамках этого гайда.
=
— Это произойдёт, и вы ничего не сможете поделать!
В этих словах прозвучала надменность, свойственная ментатам, когда они попадают на поле своей логики.
"Еретики Дюны"
1👍34❤7✍3
Порассуждаю письмом на эту темку.
Числовых характеристик художественного текста существуют многие десятки если не сотни, причём по самым разным критериям. Лингвистические, стилистические, архитектоника, концептуальные, смысловые... И если по многим из них математические исследования ведутся уже давно по понятным причинам, то возможность как-то (и весьма кстати неплохо) оценивать смысл, а также различные ранее считавшиеся неуловимыми вещи (чисто "творческие") с явлением нейронок стала реальностью.
Sentiment analysis, Topic modeling & thematic analysis, Стилеметрия etc. То есть сегодня количественно можно мерять семантическую глубину, энтропия vs. шум (база хорошего текста, на самом деле), и ещё много чего. В computer science активно ведутся исследования, например свежее
Machine Learning-Based Sentiment Analysis in English Literature: Using Deep Learning Models to Analyze Emotional and Thematic Content in Texts
Ну и конечно появились онлайн-сервисы с неплохим набором подобной аналитики, причём есть очень даже хорошие конкретно для русского языка. Ссылки давать не буду чтобы не выглядело рекламой, вот небольшой обзор основных таких сервисов.
С LitCritic AI и другими обязательно поэкспериментирую с проф версией.
Там не упоминается ещё RuLingva лаборатории КФУ «Мультидисциплинарные исследования текста» (везёт же тамошним студентам аспирантам :). В МПГУ ведутся исследования по многослойному анализу текста с акцентом на ритме, ярославские учёные разработали ProseRhythmDetector.
Почему такой акцент на ритме? Потому что это характеристика подсознательная, подпороговая, но при этом крайне важная. Буквально только в этом столетии появилось математическое подтверждение гениальной идеи Андрея Белого, который предполагал, что ритм связан со смыслом. А теперь ещё оказывается, что и обратное тоже верно! То есть в частности анализировать чисто человеческие характеристики восприятия текста можно формально через ритм.
10 лет назад вышла монография "Гармоническая организация художественного произведения", можно купить на литресе например, где ровно за эту тему поясняется. Ритм перестал быть "невыразимым" -- он стал измеримым, что потянуло за собой кучу других ранее казавшихся принципиально неизмеримыми характеристик текста, а появление нейронок подняло такой анализ вообще на топовый уровень!
(и с конспирологической т.зр., раз удаётся формализовать даже такие нюансы, растет вероятность, что это всё симуляция:)
Пока я сформулировал предварительный пайп из семи шагов, который потенциально должен будет уничтожить весь мэйнстрим-худлит :)
Святые писатели говорили, что все великие тексты написаны по одному рецепту: 1% гениальности и 99% радикального редактирования, и я хочу этот рецепт автоматизировать.
Тренироваться буду на котиках -- на вас, дорогие, уж извините :) Занимаюсь этим исключительно из любви к науке и творчеству (художник должен быть голодным).
И ты, огневая Музыка слов,
Безумствуй, сжигая меня,
Россия, Россия, Россия,–
Мессия грядущего дня!
А.Б.
Числовых характеристик художественного текста существуют многие десятки если не сотни, причём по самым разным критериям. Лингвистические, стилистические, архитектоника, концептуальные, смысловые... И если по многим из них математические исследования ведутся уже давно по понятным причинам, то возможность как-то (и весьма кстати неплохо) оценивать смысл, а также различные ранее считавшиеся неуловимыми вещи (чисто "творческие") с явлением нейронок стала реальностью.
Sentiment analysis, Topic modeling & thematic analysis, Стилеметрия etc. То есть сегодня количественно можно мерять семантическую глубину, энтропия vs. шум (база хорошего текста, на самом деле), и ещё много чего. В computer science активно ведутся исследования, например свежее
Machine Learning-Based Sentiment Analysis in English Literature: Using Deep Learning Models to Analyze Emotional and Thematic Content in Texts
Ну и конечно появились онлайн-сервисы с неплохим набором подобной аналитики, причём есть очень даже хорошие конкретно для русского языка. Ссылки давать не буду чтобы не выглядело рекламой, вот небольшой обзор основных таких сервисов.
С LitCritic AI и другими обязательно поэкспериментирую с проф версией.
Там не упоминается ещё RuLingva лаборатории КФУ «Мультидисциплинарные исследования текста» (везёт же тамошним студентам аспирантам :). В МПГУ ведутся исследования по многослойному анализу текста с акцентом на ритме, ярославские учёные разработали ProseRhythmDetector.
Почему такой акцент на ритме? Потому что это характеристика подсознательная, подпороговая, но при этом крайне важная. Буквально только в этом столетии появилось математическое подтверждение гениальной идеи Андрея Белого, который предполагал, что ритм связан со смыслом. А теперь ещё оказывается, что и обратное тоже верно! То есть в частности анализировать чисто человеческие характеристики восприятия текста можно формально через ритм.
10 лет назад вышла монография "Гармоническая организация художественного произведения", можно купить на литресе например, где ровно за эту тему поясняется. Ритм перестал быть "невыразимым" -- он стал измеримым, что потянуло за собой кучу других ранее казавшихся принципиально неизмеримыми характеристик текста, а появление нейронок подняло такой анализ вообще на топовый уровень!
Пока я сформулировал предварительный пайп из семи шагов, который потенциально должен будет уничтожить весь мэйнстрим-худлит :)
Святые писатели говорили, что все великие тексты написаны по одному рецепту: 1% гениальности и 99% радикального редактирования, и я хочу этот рецепт автоматизировать.
Тренироваться буду на котиках -- на вас, дорогие, уж извините :) Занимаюсь этим исключительно из любви к науке и творчеству (художник должен быть голодным).
И ты, огневая Музыка слов,
Безумствуй, сжигая меня,
Россия, Россия, Россия,–
Мессия грядущего дня!
А.Б.
👍34✍12❤8⚡2🔥1
This media is not supported in your browser
VIEW IN TELEGRAM
Гениально: "CashClaw - опенсорсный ИИ, который будет просто грести деньги лопатой и постоянно обучаться, становясь всё лучше и лучше в заработке"
Даже "зороботок на крипте 100500%" до подобного не додумался :)
Вопросы "если эта штука умеет зарабатывать, так зачем же вы её всем отдаёте?" задавать конечно не имеет смысла. Но зато какой вирусный пиар по всему миру.
"Гуру объяснил (менеджерам Сбера), что менеджер должен постоянно пребывать в моменте, потому что все бабло исключительно там
Гуру из Индии – святой. Настоящий. Его в «Роллс-Ройсе» возят. Цветы под ноги кидают, все дела. А учитель йоги, если его за сто долларов нанимают – это эрзац. Там только слова такие же, а то, что за ними стоит, внутреннее состояние, оно может быть совсем-совсем другое. Особенно если он на свои курсы йоги в метро ездит и все эти хари ежедневно видит."
-- Пелевин
Даже "зороботок на крипте 100500%" до подобного не додумался :)
Вопросы "если эта штука умеет зарабатывать, так зачем же вы её всем отдаёте?" задавать конечно не имеет смысла. Но зато какой вирусный пиар по всему миру.
"Гуру объяснил (менеджерам Сбера), что менеджер должен постоянно пребывать в моменте, потому что все бабло исключительно там
Гуру из Индии – святой. Настоящий. Его в «Роллс-Ройсе» возят. Цветы под ноги кидают, все дела. А учитель йоги, если его за сто долларов нанимают – это эрзац. Там только слова такие же, а то, что за ними стоит, внутреннее состояние, оно может быть совсем-совсем другое. Особенно если он на свои курсы йоги в метро ездит и все эти хари ежедневно видит."
-- Пелевин
😁49❤7👍2
Много лет в своей карьере я ценил некоторые неправильные вещи (некоторые были прям очень неправильными). Это заставляет меня задуматься, что я неправильно оцениваю прямо сейчас.
(Но за все 47 лет непрерывного программирования стратегической ключевой ошибкой всегда, вижу из сегодня, было недооценивание силы computer science и математики)
❤🔥44❤9👌4👍1
Сегодня оказывается День свободы слова в Интернете lol
То-то телеграм лежит по всему миру: видимо Паша выкатывает новый стелз-фикс )))
Честно говоря, не понимаю ажиотаж вокруг этого вашего макса-шмакса. Хотя нет, понимаю: это классическая операция прикрытия (только проводят её явные дилетанты в теме :). Ведь этот национальный мессенджер из трёх английских букв -- ну максимум 0.2% от национальной цифровой инфраструктуры, в которой имеются проблемные куски в сотни раз крупнее, и где на многие годы вперёд нет никаких перспектив импортозамещения ни в программном, ни в аппаратном формате (личное оценочное суждение). Ну вот, переводим внимание с реальных проблем на какую-то более-менее работающую крохотулечку, тем более что задачка-то по большому счёту абсолютно типовая, и можно бравурные отчёты делать.
Но вот главное, что честно не понимаю: есть клиент ВКонтакте (и ОК:), в нём куча возможностей, включая и чаты, и видеозвонки, и всего другого. Это уже нормально работающий, десятилетием проверенный - и куда более национальный по сути, чем макс - мессенджер, ну так и зачем создавать ещё одну альтернативу под той же крышей?
Этой весной будет 7 лет, как я открыл Лабораторию(экс-Школу), и всё это время практически 100% моего нано-"бизнеса" велось и ведётся в VK. Где-то в 2020-м я окончательно и безвозвратно выпилился из фбука (просто противно стало читать тамошнюю публику), ну а телеграм у меня чисто для души.
Вообще, всегда было удивительно видеть, как люди строят бизнес с ЦА в России на нероссийских площадках. Я с самого начала закладывался строго на VK, подход оправдывается на 100%, и вот что ещё не понимаю -- так это почему сейчас все бросились переходить в пустой макс (противно смотреть на линки "мы в шмаксе") - а не в VK, где уже огромная аудитория и хорошая рекламная система??
Где логика где разум :)
И вот ещё что тоже умиляет: когда авторитетные блогеры пишут "я буду вести свой тг-канал до конца, останется ядро аудитории, потому что есть три волшебных английских буквы". Ну что за детский сад... Странно думать, что этой темой занимаются люди глупее тебя. Как раз они куда умнее.
Вот мой прогноз:
- в апреле забанят телеграм полностью (но конечно, что "тг даже через впн не будет работать" это полный бред, ну сделает Дуров второй тор, и получится сильно хуже всем),
- в мае забанят стим (мем не мой, но игры там из моего реального стима :),
- летом начнутся сперва огромные штрафы за впн-трафик, а потом и сама эта технология будет ликвидирована более чем полностью (вот тогда и в тг уже не зайдёшь).
И дальше будет только хуже. Graviora manent.
Моя рекомендация: указывайте поскорее "Мы в VK".
То-то телеграм лежит по всему миру: видимо Паша выкатывает новый стелз-фикс )))
Честно говоря, не понимаю ажиотаж вокруг этого вашего макса-шмакса. Хотя нет, понимаю: это классическая операция прикрытия (только проводят её явные дилетанты в теме :). Ведь этот национальный мессенджер из трёх английских букв -- ну максимум 0.2% от национальной цифровой инфраструктуры, в которой имеются проблемные куски в сотни раз крупнее, и где на многие годы вперёд нет никаких перспектив импортозамещения ни в программном, ни в аппаратном формате (личное оценочное суждение). Ну вот, переводим внимание с реальных проблем на какую-то более-менее работающую крохотулечку, тем более что задачка-то по большому счёту абсолютно типовая, и можно бравурные отчёты делать.
Но вот главное, что честно не понимаю: есть клиент ВКонтакте (и ОК:), в нём куча возможностей, включая и чаты, и видеозвонки, и всего другого. Это уже нормально работающий, десятилетием проверенный - и куда более национальный по сути, чем макс - мессенджер, ну так и зачем создавать ещё одну альтернативу под той же крышей?
Этой весной будет 7 лет, как я открыл Лабораторию(экс-Школу), и всё это время практически 100% моего нано-"бизнеса" велось и ведётся в VK. Где-то в 2020-м я окончательно и безвозвратно выпилился из фбука (просто противно стало читать тамошнюю публику), ну а телеграм у меня чисто для души.
Вообще, всегда было удивительно видеть, как люди строят бизнес с ЦА в России на нероссийских площадках. Я с самого начала закладывался строго на VK, подход оправдывается на 100%, и вот что ещё не понимаю -- так это почему сейчас все бросились переходить в пустой макс (противно смотреть на линки "мы в шмаксе") - а не в VK, где уже огромная аудитория и хорошая рекламная система??
Где логика где разум :)
И вот ещё что тоже умиляет: когда авторитетные блогеры пишут "я буду вести свой тг-канал до конца, останется ядро аудитории, потому что есть три волшебных английских буквы". Ну что за детский сад... Странно думать, что этой темой занимаются люди глупее тебя. Как раз они куда умнее.
Вот мой прогноз:
- в апреле забанят телеграм полностью (но конечно, что "тг даже через впн не будет работать" это полный бред, ну сделает Дуров второй тор, и получится сильно хуже всем),
- в мае забанят стим (мем не мой, но игры там из моего реального стима :),
- летом начнутся сперва огромные штрафы за впн-трафик, а потом и сама эта технология будет ликвидирована более чем полностью (вот тогда и в тг уже не зайдёшь).
И дальше будет только хуже. Graviora manent.
Моя рекомендация: указывайте поскорее "Мы в VK".
✍46⚡6❤6
Прочитал на платном медиуме историю, как сеньор с пятнадцатилетним опытом уволился с хорошего места с хорошей зарплатой. Всё началось с того, как компания уволила восемь джуниоров и заменила их на LLM, а затем руководство попросило оставшихся сеньоров контролировать работу AI. Далее он с грустью наблюдал, как кодовая база превращается в катастрофичный Big Ball of Mud, которую никто как следует не понимал, а все проблемы стали сваливать на сеньоров: типа, вы несёте ответственность за код, который пишет нейронка.
Компании по всему миру объявляют, что AI успешно справляется с тем, чем раньше занимались джуниоры. Инвесторам это особенно нравится, и цены на акции растут. Все отмечают растущую эффективность работы. Да только вот никто не сообщает о том, что происходит в тех же компаниях шесть месяцев спустя.
Компании, сокращающие должности джуниоров, по сути, убивают отрасль, в которой они работают. Примерно через пять-семь лет возникнет нехватка сеньоров, которая постепенно станет поистине катастрофической.
Нейронка пишет код, который выглядит корректно и проходит все тесты. Она выполняет примерно то, о чем вы просили в промпте. Чего она не делает, так это не понимает бизнес-логику, которая годами формировалась в кодовой базе. Она не знает, почему в 2019-м было принято определённое архитектурное решение, которое кажется странным, но было правильным по некоторой причине. Она не понимает неявных контрактов между подсистемами, которые нигде не были записаны, потому что человек, создавший обе подсистемы, держал это в голове.
Нейронка генерирует правдоподобный код, который создаёт едва заметные проблемы. Проблемы, которые не проявляются месяцами. Проблемы, для диагностики которых требуется специалист с глубоким пониманием контекста.
Сеньоров не увольняют. Компании нуждаются в них, по крайней мере, на данный момент, чтобы контролировать работу AI и выявлять ошибки, которые AI допускает. Но теперь сеньоры выполняют три работы: их текущая, анализ результатов работы AI, и попытка объединить кодовые базы, которые постепенно становятся всё менее понятными человеку. Поэтому они уходят. Добровольно. Пока на другие позиции, а дальше, возможно, вообще из ИТ.
А джуниоры и миддлы, которые потратят три года на проверку кода за AI, никогда не станут сеньорами. Они станут просто очень опытными рецензентами кода AI. А это совершенно другой набор скиллов. Потому что они никогда не создавали ментальную модель того, как работают эти системы, которая может быть получена только в результате их реального создания вручную.
85% разработчиков сегодня используют AI-инструменты. Но у нас почти нет поколения новых разработчиков, изучающих базу, которая позволит им выявлять сегодняшние ошибки AI через пять лет.
Таким образом, компании в конечном итоге получат AI, который они не смогут правильно контролировать, и который будет поддерживаться людьми, которые научились работать с AI до того, как научились понимать системы, которые AI должен создавать, и которым достались кодовые базы, которые больше никто до конца не понимает, потому что все, кто их понимал (или хотя бы мог понимать), либо были сокращены, либо уволились.
Это не эффективность. Это замедленная катастрофа, но с хорошими квартальными показателями на сегодня.
Система, которая уничтожает свои собственные ресурсы для краткосрочных результатов, становится крайне хрупкой. Эта система выглядит здоровой прямо сейчас -- но будет выглядеть совсем по-другому через несколько лет.
Правдоподобный результат без понимания его внутренней структуры хорош до тех пор, пока это так. А когда он перестаёт быть хорошим, он перестаёт быть хорошим самым худшим из возможных способов. В производственных системах. В критически важной инфраструктуре. Там, где "AI сгенерировал что-то, что выглядело правильным", это неприемлемо.
Этот день всё ближе. Вопрос только в том, найдётся ли тогда хоть кто-нибудь, обладающий глубокими знаниями, чтобы это исправить.
Компании по всему миру объявляют, что AI успешно справляется с тем, чем раньше занимались джуниоры. Инвесторам это особенно нравится, и цены на акции растут. Все отмечают растущую эффективность работы. Да только вот никто не сообщает о том, что происходит в тех же компаниях шесть месяцев спустя.
Компании, сокращающие должности джуниоров, по сути, убивают отрасль, в которой они работают. Примерно через пять-семь лет возникнет нехватка сеньоров, которая постепенно станет поистине катастрофической.
Нейронка пишет код, который выглядит корректно и проходит все тесты. Она выполняет примерно то, о чем вы просили в промпте. Чего она не делает, так это не понимает бизнес-логику, которая годами формировалась в кодовой базе. Она не знает, почему в 2019-м было принято определённое архитектурное решение, которое кажется странным, но было правильным по некоторой причине. Она не понимает неявных контрактов между подсистемами, которые нигде не были записаны, потому что человек, создавший обе подсистемы, держал это в голове.
Нейронка генерирует правдоподобный код, который создаёт едва заметные проблемы. Проблемы, которые не проявляются месяцами. Проблемы, для диагностики которых требуется специалист с глубоким пониманием контекста.
Сеньоров не увольняют. Компании нуждаются в них, по крайней мере, на данный момент, чтобы контролировать работу AI и выявлять ошибки, которые AI допускает. Но теперь сеньоры выполняют три работы: их текущая, анализ результатов работы AI, и попытка объединить кодовые базы, которые постепенно становятся всё менее понятными человеку. Поэтому они уходят. Добровольно. Пока на другие позиции, а дальше, возможно, вообще из ИТ.
А джуниоры и миддлы, которые потратят три года на проверку кода за AI, никогда не станут сеньорами. Они станут просто очень опытными рецензентами кода AI. А это совершенно другой набор скиллов. Потому что они никогда не создавали ментальную модель того, как работают эти системы, которая может быть получена только в результате их реального создания вручную.
85% разработчиков сегодня используют AI-инструменты. Но у нас почти нет поколения новых разработчиков, изучающих базу, которая позволит им выявлять сегодняшние ошибки AI через пять лет.
Таким образом, компании в конечном итоге получат AI, который они не смогут правильно контролировать, и который будет поддерживаться людьми, которые научились работать с AI до того, как научились понимать системы, которые AI должен создавать, и которым достались кодовые базы, которые больше никто до конца не понимает, потому что все, кто их понимал (или хотя бы мог понимать), либо были сокращены, либо уволились.
Это не эффективность. Это замедленная катастрофа, но с хорошими квартальными показателями на сегодня.
Система, которая уничтожает свои собственные ресурсы для краткосрочных результатов, становится крайне хрупкой. Эта система выглядит здоровой прямо сейчас -- но будет выглядеть совсем по-другому через несколько лет.
Правдоподобный результат без понимания его внутренней структуры хорош до тех пор, пока это так. А когда он перестаёт быть хорошим, он перестаёт быть хорошим самым худшим из возможных способов. В производственных системах. В критически важной инфраструктуре. Там, где "AI сгенерировал что-то, что выглядело правильным", это неприемлемо.
Этот день всё ближе. Вопрос только в том, найдётся ли тогда хоть кто-нибудь, обладающий глубокими знаниями, чтобы это исправить.
❤51🤔15👍4✍1😇1
Я чувствую себя отстающим почти во всём, что касается искусственного интеллекта, и при этом я программист, весьма активно изучающий эту тему. И я не могу представить, как чувствует себя отстающий в AI обычный человек. Поэтому читать, что и как люди говорят об искусственном интеллекте -- отличный способ понять, насколько глупо 98% людей. А некоторые из таких отстающих, особенно облечённые полномочиями принимать решения в области AI, зачем-то вдобавок особенно наглядно демонстрируют свою глупость на публику.
С другой стороны, каждый раз, когда вы сомневаетесь в себе, просто посмотрите, скольким людям, в сотни раз более тупым, чем вы, удалось добиться невероятного успеха.
С другой стороны, каждый раз, когда вы сомневаетесь в себе, просто посмотрите, скольким людям, в сотни раз более тупым, чем вы, удалось добиться невероятного успеха.
3👍42❤15😇6🙏4✍2
Большинство людей полагают, что создание программного продукта -- это код, но на самом деле речь идёт о том, чтобы выяснить, какая проблема раздражает людей настолько, чтобы они начали платить вам за её решение.
В тему, порекомендую очень смешной сериал-дораму "Талант не по годам", как парнишка-неудачник получает деньги от таинственного инвестора, и создаёт свой геймдев-стартап.
В тему, порекомендую очень смешной сериал-дораму "Талант не по годам", как парнишка-неудачник получает деньги от таинственного инвестора, и создаёт свой геймдев-стартап.
👍49❤7