1. Статья декларируется как бизнес-успех (а не инженерный), при этом бизнес метрики отсутствуют. Затраты и бюджеты посчитаны не верно. Результат оценен не верно. Исходный посыл не верный (то что 1M$ убил бы ваш стартап).
Каким образом по вашему статья может декларируется как бизнес-успех если ничего не продается и продукт находится в бете? О каких метриках вы начали речь если там четко это написано? Для меня успех в том, что я дошел до этой самой беты. Вот о чем статья. Статья о том, что это один из первых таких прецендентов, когда человек без опыта сделал продукт подобной сложности и да, я сравнил это со стартапами которые собирают миллион инвестиций в серии А. Причем тут какой-то успех кроме самого факта того что я написал выше?
У вас примерно 0 чего-то полезного с инженерной точки зрения. Более того основной посыл "инженеры для MVP не нужны мне всё сделал LLM". Что тут полезного для инженеров?
А вам не кажется что сам факт того что инженеры не нужны это как минимум полезная информация для инженеров, что бы задуматься? Информация о том, что их работу теперь может сделать "Вася Пупкин задалбывая ллм своими гениальными идеями". Или может быть это мотивация для таких "горе-фаундеров" как я которые могут увидеть, что границы возможного сдвинуты, если я смог сделать это, значит кто то другой может сделать что то еще гараздо круче. Вас это раздражает? Я понимаю, без иронии. Направляйте претензии в OpenAI
Нету в статье никакой архитектуры:
В этой точно нету, в прошлой была как вы сами сказали. Еще раз, я пришел зафиксировать один из первых подобных прецендентов. Я считаю это смена парадигмы. Большенство инженеров все еще считают, что это невозможно и "ллм для простых задач" и я принес пруф. Вы с этим тезисом будете спорить? Это не имеет пользы для технического ресурса? Это самый передний край разработки, просто вам не нравится подход, но мир изменился хотите вы того или нет. Если это не прицендент, приведите примеры продуктов подобной сложности сделаного одним человеком не являющемся программистом. Я искал и не смог найти, может быть у вас получится.
По поводу целевой аудитории и что "это никому не нужно" не хотел отвечать потому что как я сказал мне не интересны советы или мнения о бизнесе, так как я тут ничего не продаю. Но мне интересно, вы делаете выводы исходя из своих желаний? Иначе на чем вы их основываете что так уверенны? Если я годами варился в сфере трейдинга и знаю эту аудиторию как самого себя потому что их боль это моя боль, то как вы думаете может быть все таки найдется кто-то кому это нужно? Или вам просто тяжело это принять? Иначе я просто не понимаю откуда эта уверенность про "горе-фаундеров" и прочее? Я вижу тут только одну причину, вас лично задевает, что "порог входа" снизился и "Горе-фаундеры теперь задалбывают ллм, а не вас". Я не решил, что мне будут только позитивный фидбек тут писать, я решил, что будут писать конструктивный и в чуть более корректной форме, а еще я решил, что в статье всем понятно что я хотел сказать этой статьей, но видимо не всем.
Прочитав ваш коментарий я даже на секунду подумал, что по ошибке опубликовал статью на vc.ru, но нет, мы на хабре. Насколько мне известно - это ресурс для инженеров. Здесь обсуждают архитектуру, стеки и методы разработки. Если бы я хотел обсудить Unit-экономику, CAC и LTV - я бы пошел на vc.ru или TechCrunch. Требовать от технической статьи бизнес-метрик - это как требовать от статьи про устройство двигателя Ferrari отчета о продажах автосалона. Когда я пишу "продукт уровня Series A", я говорю об инженерной сложности и плотности функционала, а не о выручке (ARR), казалось это очевидно. В обычном мире такой объем разработки стоит сотни тысяч. Суть статьи - в стоимости производства, а не в стоимости продажи.
В словах про "горе-фаундеров" чувствуетстся некая обида. Как буд-то вас раздражает тот факт, что порог входа снизился и "горе-фаундеры" теперь "задалбывают ЛЛМ своим бредом", а не вас. Иначе обьяснить, что вы не поленились вылить негатив не по теме я не могу. Меня, честно говоря, мало интересует мнение диванных "экспертов" по успешному успеху. Я пришел сюда за мнением инженеров касательно архитектуры и подхода.
Вы правы в одном - продавать сложнее, чем кодить. Но статья как раз о том, как дешево ошибаться. Раньше, чтобы проверить "гениальную идею", фаундер должен был сжечь $300k инвесторских денег и год жизни команды. Сейчас он тратит $200 и свое время. Странно, что вас это расстраивает.
Почему-то у некоторых складывается ощущение, что я как-то плохо отношусь к программистам, но на самом деле я отношусь к ним с большим уважением, потому что сам я в свое время кодинг не осилил, не хватило усидчивости, времени, образования. Поэтому АИ революция для меня - это чудо.
И вот вы сказали интересную мысль по поводу того, что "самая сложная часть это получить полноценное описание что нужно написать". Тогда получается я и занимался тем, что писал ТЗ для ИИ. Но скорее даже вместе с ним, потому что это сейчас я относительно понимаю как это работает, но когда начинал, я мог сформулировать это только простым языком. Допустим, как я написал в статье у меня был бы бюджет, знание предметной области и я бы нанял программиста вроде вас. Вопрос: смог бы я составить такое ТЗ, что бы программист который не знаком с трейдингом меня понял и реализовал именно то что я хочу? Я для себя сделал вывод, что вряд ли и по сути об этом статья. Я не смог бы так реализовать свое виденье как это сдеалал с ИИ, потому что он понимает и код и трейдинг и прочее. Или мне бы пришлось искать разработчика трейдера?
По поводу скальпинга не совсем верно, скальпинг - это не значит, что берутся очень мелкие движения, они по сути могут быть любыми. Скальпинг - это в первую очередь торговля по ленте и стакану, а остальное уже зависит от риск менеджмента. Плюс от того же бинанса можно получать ребейты 50% и платформа не только для скальпинга, я стремлюсь добиться того, что бы на ней можно было реализовать практически любую торговую систему.
Еще то чего нет у большенства подобных платфом это визуальное дерево принятия решений которое сразу на графике показывает основания которые сработали или были отклонены так как используется система взвешеных оснований. Это очень помогает наглядно оценить, что вообще происходило в момент принятия решения и почему открылась та или иная сделка
В плане трейдинга? Да, я считаю, что разбираюсь. Тестирую с помощью юнит тестов которых уже более 600. Или к примеру, сравнением с эталоном. Я беру данные с биржи, прогоняю через свой движок и сверяю индикаторы/сигналы с TradingView. Так же я беру кусок истории и прогоняю его как через бэктестер, так и через движок лайв торговли, что бы сделки в реале и на бэктестах совпадали. Сморю логи. Ну и в конце концов визуально на графике сразу видно, если стратегия начинает совершать сделки в прошлом или "рисует" миллионы процентов.
Вы не так поняли - это конструктор ботов для автоматической торговли, по моему мнению довольно гибкий с поддержкой даже сложнейших скальперских стратегий с лентой, стаканом, корреляцей, поводырями и так далее. Посмотрите гифку в начале статьи - это классическая скальперская стратегия в виде как трейдеры записывают ее для себя и АИ-ассистент собирает эту логику из готовых блоков в визуальном конструкторе :)
Инерция и риски. Крупный бизнес не может позволить себе резко уволить всех разрабов и посадить джуна с агентами. Технология только появилась и только в прошлом году вышла на достойный уровень. Рынок ещё не успел перестроиться. Я написал это потому что таких кейсов все ещё очень мало. Именно поэтому бытует мнение, что "ллм это для простых задач". Корпорации с тысячами пользователей просто не могут позволить себе такие риски, тем не менее мы все чаще видим в новостях, что многим компании перестраиваются
Есть такая библиотека tree-sitter (она строит AST-дерево кода). Gemini написал скрипт который сканирует проект, находит определения классов/функций и главное, вызовы между ними.
На выходе получаю XML со всеми связями в коде. Этот XML закидываю в Gemini Pro. У неё контекст млн токенов, и через этот граф зависимостей он начинает видеть весь проект целиком. Например, когда пишет ТЗ сразу понимает какие модули может задеть, какие тесты и так далее. Некоторые агенты делают это автоматически. Но я делал в ручную через aistudio
Если вы имеете в виду с ЛЛМ - то безусловно. Но без - мне кажется, на такое способны единицы, даже среди профи, слишком уж широкий спектр знаний нужен. В одном только трейдинге нужно повариться хотя бы пару лет, не говоря уже о том, чтобы изучить весь задействованный стек на достаточном уровне. Опять же, я конечно могу ошибаться, но далеко не каждый стартап настолько требователен к технической части, хотя коммерчески может быть в сотни раз успешнее.
Может быть это на сайте gemini.com? Я большую часть этого проекта создал через aistudio причём ещё на старой версии 2.5 pro и таких проблем не было, в среднем контекст бывал по 300к токенов и он с ним неплохо справлялся, а примерно 15к строк кода
Для этого я написал скрипт на tree-sitter, который делает статический анализ всего проекта и строит граф связей: файлы, классы, функции и даже HTTP-запросы с фронта на бэк. В итоге я даю ИИ не просто голый код, а актуальную карту связей, пример как это выглядит визуально я кидал в конце прошлой статьи.
Плюс использую Gemini - у неё окно в 1 млн токенов.
Добавлю так же важную деталь, которую я указывал в прошлой статье: у меня практически не было опыта в программировании(не считая попытки узучить php 15 лет назад). Вот в чем прецендент по моему мнению. Теперь не нужно 10 лет изучать программирование, что бы создавать подобные продукты. И это заслуга прогресса, а не моя
Вы правы, история IT знает немало соло-героев. Но есть пара нюансов, которые делают этот случай прецедентом:
Цукерберг был одаренным студентом Гарварда с бэкграундом в программировании. Я же - человек без коммерческого опыта и профильного образования. Раньше «гаражная разработка» была привилегией тех, кто уже умел кодить. Сейчас этот барьер рухнул для всех.
Ранний Facebook был классическим CRUD-приложением (база данных и формы). Здесь же мы имеем гибрид из высоконагруженного бэкенда, векторного движка, генетических алгоритмов и визуального редактора. В традиционной модели это требует глубоких знаний сразу в 3-4 разных областях (Quant, DevOps, Frontend, Backend). Одному человеку (даже профи) охватить всё это в такие сроки без AI практически нереально - просто не хватит часов в сутках на изучение документации и отладку.
Мой посыл не в том, что «я уникум», а в том, что инструментарий изменил правила игры. Теперь фаундер без команды может реализовать сложное архитектурное видение на 100%, не идя на компромиссы, которые неизбежны в классических командах из-за «социального трения».
Честно признаюсь, не читал :) Но благодаря вашему комментарию только что загуглил основные тезисы и да, кажется там именно о том, что добавление людей в проект лишь затягивает его из-за экспоненциального роста затрат на коммуникацию.
Парадокс в том, что раньше у нас просто не было выбора. Чтобы создать сложный продукт, ты был обязан нанимать команду, соглашаясь на этот "налог" на общение и потерю контекста. Одному человеку не хватило бы жизни, чтобы написать всё вручную.
Сегодня ИИ впервые в истории позволяет обойти этот закон и вот статья скорее об этом. Рад, что мои мысли подтверждаются практикой 50 летней давности.
Спасибо за наводку, теперь эта книга точно в моем списке на прочтение.
Приветствую. Спасибо за взвешенный комментарий и за то, что уделили время прочтению. Мнение человека с 10-летним опытом в индустрии для меня ценно, без иронии.
Я использовал это как сокращение от «Quantitative analysis» (количественный анализ). Подход, где рынок рассматривается как систему переменных, а цены, объёмы и факторы риска как элементы одной большой модели
Здесь я согласен лишь отчасти. Мы действительно не можем объективно оценить финансовую эффективность стратегий в будущем (рынок - это хаос). Но мы можем объективно оценить инженерную сложность функционала. Векторный движок, парсинг Order Flow в реальном времени, генетическая оптимизация - это конкретные фичи. Мой поинт в том, что раньше реализация такого стека требовала команды и бюджета. Теперь это доступно одному. Мы оцениваем инструмент, а не то, как рынок на него отреагирует.
Тут согласен. Я использую этот термин как маркер уровня сложности и стоимости входа. Обычно софт такого уровня насыщенности фичами создается именно внутри крупных структур с большими бюджетами, а не инди-разработчиками. Смысл был в сравнении ресурсов, а не бизнес-модели.
Возможно выводы звучат громко. Но это выводы человека, который смог материализовать идею, которая еще 2 года назад осталась бы просто фантазией из-за отсутствия ~$300k на разработку.
И мне, кстати, очень интересно ваше мнение как ветерана индустрии касательно "Социального трения". Согласны ли вы с тезисом, что изначальное видение фаундера часто "размывается" и теряет остроту, проходя через длинную цепочку ТЗ - Архитектор - Тимлид - Код? Или в качественном энтерпрайзе это работает иначе? Может быть я ошибаюсь?
Для меня немного странно, что вы как буд-то бы отказываетесь принять очевидный факт который написан в заголовке, а внизу ссылка ведущая на доказательства. Что ж, "не смотреть наверх" - это личный выбор каждого.)
Промахнулся с ответом https://habr.com/ru/articles/982606/#comment_29336522
Каким образом по вашему статья может декларируется как бизнес-успех если ничего не продается и продукт находится в бете? О каких метриках вы начали речь если там четко это написано? Для меня успех в том, что я дошел до этой самой беты. Вот о чем статья. Статья о том, что это один из первых таких прецендентов, когда человек без опыта сделал продукт подобной сложности и да, я сравнил это со стартапами которые собирают миллион инвестиций в серии А. Причем тут какой-то успех кроме самого факта того что я написал выше?
А вам не кажется что сам факт того что инженеры не нужны это как минимум полезная информация для инженеров, что бы задуматься? Информация о том, что их работу теперь может сделать "Вася Пупкин задалбывая ллм своими гениальными идеями". Или может быть это мотивация для таких "горе-фаундеров" как я которые могут увидеть, что границы возможного сдвинуты, если я смог сделать это, значит кто то другой может сделать что то еще гараздо круче. Вас это раздражает? Я понимаю, без иронии. Направляйте претензии в OpenAI
В этой точно нету, в прошлой была как вы сами сказали. Еще раз, я пришел зафиксировать один из первых подобных прецендентов. Я считаю это смена парадигмы. Большенство инженеров все еще считают, что это невозможно и "ллм для простых задач" и я принес пруф. Вы с этим тезисом будете спорить? Это не имеет пользы для технического ресурса? Это самый передний край разработки, просто вам не нравится подход, но мир изменился хотите вы того или нет. Если это не прицендент, приведите примеры продуктов подобной сложности сделаного одним человеком не являющемся программистом. Я искал и не смог найти, может быть у вас получится.
По поводу целевой аудитории и что "это никому не нужно" не хотел отвечать потому что как я сказал мне не интересны советы или мнения о бизнесе, так как я тут ничего не продаю. Но мне интересно, вы делаете выводы исходя из своих желаний? Иначе на чем вы их основываете что так уверенны? Если я годами варился в сфере трейдинга и знаю эту аудиторию как самого себя потому что их боль это моя боль, то как вы думаете может быть все таки найдется кто-то кому это нужно? Или вам просто тяжело это принять? Иначе я просто не понимаю откуда эта уверенность про "горе-фаундеров" и прочее? Я вижу тут только одну причину, вас лично задевает, что "порог входа" снизился и "Горе-фаундеры теперь задалбывают ллм, а не вас". Я не решил, что мне будут только позитивный фидбек тут писать, я решил, что будут писать конструктивный и в чуть более корректной форме, а еще я решил, что в статье всем понятно что я хотел сказать этой статьей, но видимо не всем.
Прочитав ваш коментарий я даже на секунду подумал, что по ошибке опубликовал статью на vc.ru, но нет, мы на хабре. Насколько мне известно - это ресурс для инженеров. Здесь обсуждают архитектуру, стеки и методы разработки. Если бы я хотел обсудить Unit-экономику, CAC и LTV - я бы пошел на vc.ru или TechCrunch. Требовать от технической статьи бизнес-метрик - это как требовать от статьи про устройство двигателя Ferrari отчета о продажах автосалона. Когда я пишу "продукт уровня Series A", я говорю об инженерной сложности и плотности функционала, а не о выручке (ARR), казалось это очевидно. В обычном мире такой объем разработки стоит сотни тысяч. Суть статьи - в стоимости производства, а не в стоимости продажи.
В словах про "горе-фаундеров" чувствуетстся некая обида. Как буд-то вас раздражает тот факт, что порог входа снизился и "горе-фаундеры" теперь "задалбывают ЛЛМ своим бредом", а не вас. Иначе обьяснить, что вы не поленились вылить негатив не по теме я не могу. Меня, честно говоря, мало интересует мнение диванных "экспертов" по успешному успеху. Я пришел сюда за мнением инженеров касательно архитектуры и подхода.
Вы правы в одном - продавать сложнее, чем кодить. Но статья как раз о том, как дешево ошибаться. Раньше, чтобы проверить "гениальную идею", фаундер должен был сжечь $300k инвесторских денег и год жизни команды. Сейчас он тратит $200 и свое время.
Странно, что вас это расстраивает.
Круто, респект и спасибо за пожелание :)
Почему-то у некоторых складывается ощущение, что я как-то плохо отношусь к программистам, но на самом деле я отношусь к ним с большим уважением, потому что сам я в свое время кодинг не осилил, не хватило усидчивости, времени, образования. Поэтому АИ революция для меня - это чудо.
И вот вы сказали интересную мысль по поводу того, что "самая сложная часть это получить полноценное описание что нужно написать". Тогда получается я и занимался тем, что писал ТЗ для ИИ. Но скорее даже вместе с ним, потому что это сейчас я относительно понимаю как это работает, но когда начинал, я мог сформулировать это только простым языком. Допустим, как я написал в статье у меня был бы бюджет, знание предметной области и я бы нанял программиста вроде вас. Вопрос: смог бы я составить такое ТЗ, что бы программист который не знаком с трейдингом меня понял и реализовал именно то что я хочу? Я для себя сделал вывод, что вряд ли и по сути об этом статья. Я не смог бы так реализовать свое виденье как это сдеалал с ИИ, потому что он понимает и код и трейдинг и прочее. Или мне бы пришлось искать разработчика трейдера?
По поводу скальпинга не совсем верно, скальпинг - это не значит, что берутся очень мелкие движения, они по сути могут быть любыми. Скальпинг - это в первую очередь торговля по ленте и стакану, а остальное уже зависит от риск менеджмента. Плюс от того же бинанса можно получать ребейты 50% и платформа не только для скальпинга, я стремлюсь добиться того, что бы на ней можно было реализовать практически любую торговую систему.
Еще то чего нет у большенства подобных платфом это визуальное дерево принятия решений которое сразу на графике показывает основания которые сработали или были отклонены так как используется система взвешеных оснований. Это очень помогает наглядно оценить, что вообще происходило в момент принятия решения и почему открылась та или иная сделка
В плане трейдинга? Да, я считаю, что разбираюсь. Тестирую с помощью юнит тестов которых уже более 600. Или к примеру, сравнением с эталоном. Я беру данные с биржи, прогоняю через свой движок и сверяю индикаторы/сигналы с TradingView. Так же я беру кусок истории и прогоняю его как через бэктестер, так и через движок лайв торговли, что бы сделки в реале и на бэктестах совпадали. Сморю логи. Ну и в конце концов визуально на графике сразу видно, если стратегия начинает совершать сделки в прошлом или "рисует" миллионы процентов.
Вы не так поняли - это конструктор ботов для автоматической торговли, по моему мнению довольно гибкий с поддержкой даже сложнейших скальперских стратегий с лентой, стаканом, корреляцей, поводырями и так далее. Посмотрите гифку в начале статьи - это классическая скальперская стратегия в виде как трейдеры записывают ее для себя и АИ-ассистент собирает эту логику из готовых блоков в визуальном конструкторе :)
Потому что с ллм это быстрее и проще и главное, нагляднее, чем искать готовые решения и разбираться в них. Об этом и статья.
Если есть сомнения, напишите в личку, я вам скину свой скрипт ;)
Инерция и риски. Крупный бизнес не может позволить себе резко уволить всех разрабов и посадить джуна с агентами. Технология только появилась и только в прошлом году вышла на достойный уровень. Рынок ещё не успел перестроиться. Я написал это потому что таких кейсов все ещё очень мало. Именно поэтому бытует мнение, что "ллм это для простых задач". Корпорации с тысячами пользователей просто не могут позволить себе такие риски, тем не менее мы все чаще видим в новостях, что многим компании перестраиваются
Есть такая библиотека tree-sitter (она строит AST-дерево кода). Gemini написал скрипт который сканирует проект, находит определения классов/функций и главное, вызовы между ними.
На выходе получаю XML со всеми связями в коде. Этот XML закидываю в Gemini Pro. У неё контекст млн токенов, и через этот граф зависимостей он начинает видеть весь проект целиком. Например, когда пишет ТЗ сразу понимает какие модули может задеть, какие тесты и так далее. Некоторые агенты делают это автоматически. Но я делал в ручную через aistudio
Если вы имеете в виду с ЛЛМ - то безусловно. Но без - мне кажется, на такое способны единицы, даже среди профи, слишком уж широкий спектр знаний нужен. В одном только трейдинге нужно повариться хотя бы пару лет, не говоря уже о том, чтобы изучить весь задействованный стек на достаточном уровне. Опять же, я конечно могу ошибаться, но далеко не каждый стартап настолько требователен к технической части, хотя коммерчески может быть в сотни раз успешнее.
Может быть это на сайте gemini.com? Я большую часть этого проекта создал через aistudio причём ещё на старой версии 2.5 pro и таких проблем не было, в среднем контекст бывал по 300к токенов и он с ним неплохо справлялся, а примерно 15к строк кода
Для этого я написал скрипт на tree-sitter, который делает статический анализ всего проекта и строит граф связей: файлы, классы, функции и даже HTTP-запросы с фронта на бэк. В итоге я даю ИИ не просто голый код, а актуальную карту связей, пример как это выглядит визуально я кидал в конце прошлой статьи.
Плюс использую Gemini - у неё окно в 1 млн токенов.
Добавлю так же важную деталь, которую я указывал в прошлой статье: у меня практически не было опыта в программировании(не считая попытки узучить php 15 лет назад). Вот в чем прецендент по моему мнению. Теперь не нужно 10 лет изучать программирование, что бы создавать подобные продукты. И это заслуга прогресса, а не моя
Вы правы, история IT знает немало соло-героев. Но есть пара нюансов, которые делают этот случай прецедентом:
Цукерберг был одаренным студентом Гарварда с бэкграундом в программировании. Я же - человек без коммерческого опыта и профильного образования. Раньше «гаражная разработка» была привилегией тех, кто уже умел кодить. Сейчас этот барьер рухнул для всех.
Ранний Facebook был классическим CRUD-приложением (база данных и формы). Здесь же мы имеем гибрид из высоконагруженного бэкенда, векторного движка, генетических алгоритмов и визуального редактора. В традиционной модели это требует глубоких знаний сразу в 3-4 разных областях (Quant, DevOps, Frontend, Backend). Одному человеку (даже профи) охватить всё это в такие сроки без AI практически нереально - просто не хватит часов в сутках на изучение документации и отладку.
Мой посыл не в том, что «я уникум», а в том, что инструментарий изменил правила игры. Теперь фаундер без команды может реализовать сложное архитектурное видение на 100%, не идя на компромиссы, которые неизбежны в классических командах из-за «социального трения».
Честно признаюсь, не читал :)
Но благодаря вашему комментарию только что загуглил основные тезисы и да, кажется там именно о том, что добавление людей в проект лишь затягивает его из-за экспоненциального роста затрат на коммуникацию.
Парадокс в том, что раньше у нас просто не было выбора. Чтобы создать сложный продукт, ты был обязан нанимать команду, соглашаясь на этот "налог" на общение и потерю контекста. Одному человеку не хватило бы жизни, чтобы написать всё вручную.
Сегодня ИИ впервые в истории позволяет обойти этот закон и вот статья скорее об этом. Рад, что мои мысли подтверждаются практикой 50 летней давности.
Спасибо за наводку, теперь эта книга точно в моем списке на прочтение.
Приветствую. Спасибо за взвешенный комментарий и за то, что уделили время прочтению. Мнение человека с 10-летним опытом в индустрии для меня ценно, без иронии.
Я использовал это как сокращение от «Quantitative analysis» (количественный анализ). Подход, где рынок рассматривается как систему переменных, а цены, объёмы и факторы риска как элементы одной большой модели
Здесь я согласен лишь отчасти. Мы действительно не можем объективно оценить финансовую эффективность стратегий в будущем (рынок - это хаос). Но мы можем объективно оценить инженерную сложность функционала. Векторный движок, парсинг Order Flow в реальном времени, генетическая оптимизация - это конкретные фичи. Мой поинт в том, что раньше реализация такого стека требовала команды и бюджета. Теперь это доступно одному. Мы оцениваем инструмент, а не то, как рынок на него отреагирует.
Тут согласен. Я использую этот термин как маркер уровня сложности и стоимости входа. Обычно софт такого уровня насыщенности фичами создается именно внутри крупных структур с большими бюджетами, а не инди-разработчиками. Смысл был в сравнении ресурсов, а не бизнес-модели.
Возможно выводы звучат громко. Но это выводы человека, который смог материализовать идею, которая еще 2 года назад осталась бы просто фантазией из-за отсутствия ~$300k на разработку.
И мне, кстати, очень интересно ваше мнение как ветерана индустрии касательно "Социального трения". Согласны ли вы с тезисом, что изначальное видение фаундера часто "размывается" и теряет остроту, проходя через длинную цепочку ТЗ - Архитектор - Тимлид - Код? Или в качественном энтерпрайзе это работает иначе? Может быть я ошибаюсь?
А причем тут форбс? Мы о деньгах или о технологии "бредогенератора"? Если вы о деньгах и Вы там есть, то я тогда не смею спорить.
Простите, я по своей глупости принял эту дискуссию за конструктивную, ошибку понял :)
Для меня немного странно, что вы как буд-то бы отказываетесь принять очевидный факт который написан в заголовке, а внизу ссылка ведущая на доказательства. Что ж, "не смотреть наверх" - это личный выбор каждого.)
Спасибо, большое. Сейчас уже голова не варит, завтра прочитаю подробнее