Каюсь, действительно не подумал о таком эффекте. Думал всем сейчас расскажу как подготовиться к будущему, а какой-нибудь компании ещё и бабла срубить и мне удобную IDE получить. Зато теперь понимаю всяких CEO GitHub и пр. директоров, которые очень аккуратно высказываются, рассказывают как никого не уволят и мы все будем жить в радужном будущем, где у всех будет достаток и не придется работать
Понимает текст, да. И тут я наткнулся на проблему, что сплошным текстом описывать требования неудобно для последующего понимания и неэффективно с точки зрения количества текста. Хотелось бы иметь какой-то стандартный "жаргон" и набор лучших практик переиспользования. Это я бы и назвал "языком программирования" будущего, чего сейчас нет
Думаю нет сысла общаться в публичном поле, когда тут столько напуганных и агрессивных людей ) Но на счет курсора, да, мне кажется это оптимальный вариант сейчас. Точнее даже так: можно проект открывать одновременно в двух IDE, в курсоре генирить код, а писать требования и просматривать результат в чем-то от JetBrains. Обе IDE хорошо отслеживают изменение файлов на диске
Вот вы вроде делаете вид, что почитали статью. В код залезли. Подумали над написанным. Но результат говорит об обратном. Вы даже не поняли, какую цель закрывал вайб-кодинг из статьи.
Цель была - получить решение, соответствующее требованиям. Которое для пользователя выполняет нужные ему действия. А код, который эти действия делает абсолютно не важен. Он может быть хоть 1000 раз индусским, если не выходит за рамки по производительности. И никто, включая автора утилиты, не собирается в нем копаться и поддерживать.
Достаточно прописать подробные требования и тест-кейсы, чтобы ожидания сходились с результатом, а возникающие баги ИИ поправит без вас.
Это уже реальность для утилит среднего размера. Понятно, что в моменте что-то сложнее так не сделать. Но то, что в перспективе нескольких лет это всё станет возможным для проектов любого размера без прослойки в виде токсичного программиста, не вызывает сомнения
А где противоречие? Я же это и написал. Будут отбираться люди, готовые сместить фокус. Не важно, из программистов или менеджеров. Даже программистам будет предпочтение.
У меня было много неудачных опытов с кодогенерацией, с рефакторингом и исправлением багов. Долгое время казалось, что это бесполезный инструмент. Статью решил написать, когда наконец стало получаться генерить полезный код и автоматически исправлять баги. Т.е. здесь нужна ещё определенная практика, чтобы этот инструмент (как и все остальные) начал приносить пользу
Я понимаю вашу претензию, выглядит так, что возможно я делаю бессмысленную работу, если сначала досконально не разобраться в требованиях. Но я хотел в этой статье сконцентрироваться на технической части. Указанный код лично мне уже экономит некоторое время по работе. И если бы я писал его руками, то на это ушло бы в 10 раз больше времени (опять же говорю за себя).
Про выбор Go, как в статье и говорится - выбор исключительно на основе того, что ИИ с ним выдает максимальное количество рабочего кода. Сравнивал с Python и Java. Т.е. Go тут рассматривается как язык, на котором мне не придется что-то писать руками.
К сожалению, чтобы детально ответить на всё, надо созваниваться на пол часа, иначе ничего просто не получится
В статье как раз говорится о том, что в перспективе можно будет отказаться от ревью кода и оперировать только требованиями и тест-кейсами, уточняя их в случае бага. И ровно так мне удавалось доводить код до рабочего состояния не погружаясь в исходники. ИИ сам отлаживал баги по уточненным требованиям
Очевидно никто не откажется от услуг программистов, пока ИИ не сможет сам поддерживать код. Вопрос только в том, что для утилит средних размеров он уже делает это сам. А в статье говорится о том, что достаточно крупные проекты он сможет поддерживать сам в течении 2-5 лет. И описывается, в каких услугах тогда будет нуждаться бизнес. Опять же наивно полагать, что программистов просто резко распустят и бизнес остановится. Какое-то время программисты со всеми знаниями будут держаться рядом и постепенно заменяться теми, кто готов сместить фокус в сторону аналитики и архитектуры. И уж в каких-то редких случаях будут прибегать к услугам тех 10 программистов с полной квалификацией
В статье же пример кода даже есть с кратким описанием зачем (но утилита для внутреннего использования, поэтому в бизнесовую составляющую не вдавался). Если прочитать
Часто слышу как ФАС кого-то из крупных компаний проверит. Но почти никогда потом не слышу, что цены упали. Т.е. они ждут пока основные продажи пройдут, потом приходят с проверкой, получают денежку и уходят, но момент уже упущен. И получается все довольны, кроме потребителей, а схема потом повторяется
Ага, там есть. Если почитать
последний, а не первый
Каюсь, действительно не подумал о таком эффекте. Думал всем сейчас расскажу как подготовиться к будущему, а какой-нибудь компании ещё и бабла срубить и мне удобную IDE получить. Зато теперь понимаю всяких CEO GitHub и пр. директоров, которые очень аккуратно высказываются, рассказывают как никого не уволят и мы все будем жить в радужном будущем, где у всех будет достаток и не придется работать
Не люблю Go, но нравится, что на нем получается рабочий код и бинарник без зависимостей. А статья, она о будущем, да
удивлен, что кто-то всё-таки читает статью прежде чем комментировать
Понимает текст, да. И тут я наткнулся на проблему, что сплошным текстом описывать требования неудобно для последующего понимания и неэффективно с точки зрения количества текста. Хотелось бы иметь какой-то стандартный "жаргон" и набор лучших практик переиспользования. Это я бы и назвал "языком программирования" будущего, чего сейчас нет
Думаю нет сысла общаться в публичном поле, когда тут столько напуганных и агрессивных людей ) Но на счет курсора, да, мне кажется это оптимальный вариант сейчас. Точнее даже так: можно проект открывать одновременно в двух IDE, в курсоре генирить код, а писать требования и просматривать результат в чем-то от JetBrains. Обе IDE хорошо отслеживают изменение файлов на диске
Вот вы вроде делаете вид, что почитали статью. В код залезли. Подумали над написанным. Но результат говорит об обратном. Вы даже не поняли, какую цель закрывал вайб-кодинг из статьи.
Цель была - получить решение, соответствующее требованиям. Которое для пользователя выполняет нужные ему действия. А код, который эти действия делает абсолютно не важен. Он может быть хоть 1000 раз индусским, если не выходит за рамки по производительности. И никто, включая автора утилиты, не собирается в нем копаться и поддерживать.
Достаточно прописать подробные требования и тест-кейсы, чтобы ожидания сходились с результатом, а возникающие баги ИИ поправит без вас.
Это уже реальность для утилит среднего размера. Понятно, что в моменте что-то сложнее так не сделать. Но то, что в перспективе нескольких лет это всё станет возможным для проектов любого размера без прослойки в виде токсичного программиста, не вызывает сомнения
А где противоречие? Я же это и написал. Будут отбираться люди, готовые сместить фокус. Не важно, из программистов или менеджеров. Даже программистам будет предпочтение.
У меня было много неудачных опытов с кодогенерацией, с рефакторингом и исправлением багов. Долгое время казалось, что это бесполезный инструмент. Статью решил написать, когда наконец стало получаться генерить полезный код и автоматически исправлять баги. Т.е. здесь нужна ещё определенная практика, чтобы этот инструмент (как и все остальные) начал приносить пользу
Я понимаю вашу претензию, выглядит так, что возможно я делаю бессмысленную работу, если сначала досконально не разобраться в требованиях. Но я хотел в этой статье сконцентрироваться на технической части. Указанный код лично мне уже экономит некоторое время по работе. И если бы я писал его руками, то на это ушло бы в 10 раз больше времени (опять же говорю за себя).
Про выбор Go, как в статье и говорится - выбор исключительно на основе того, что ИИ с ним выдает максимальное количество рабочего кода. Сравнивал с Python и Java. Т.е. Go тут рассматривается как язык, на котором мне не придется что-то писать руками.
К сожалению, чтобы детально ответить на всё, надо созваниваться на пол часа, иначе ничего просто не получится
В статье как раз говорится о том, что в перспективе можно будет отказаться от ревью кода и оперировать только требованиями и тест-кейсами, уточняя их в случае бага. И ровно так мне удавалось доводить код до рабочего состояния не погружаясь в исходники. ИИ сам отлаживал баги по уточненным требованиям
Очевидно никто не откажется от услуг программистов, пока ИИ не сможет сам поддерживать код. Вопрос только в том, что для утилит средних размеров он уже делает это сам. А в статье говорится о том, что достаточно крупные проекты он сможет поддерживать сам в течении 2-5 лет. И описывается, в каких услугах тогда будет нуждаться бизнес. Опять же наивно полагать, что программистов просто резко распустят и бизнес остановится. Какое-то время программисты со всеми знаниями будут держаться рядом и постепенно заменяться теми, кто готов сместить фокус в сторону аналитики и архитектуры. И уж в каких-то редких случаях будут прибегать к услугам тех 10 программистов с полной квалификацией
В статье же пример кода даже есть с кратким описанием зачем (но утилита для внутреннего использования, поэтому в бизнесовую составляющую не вдавался). Если прочитать
эти секции - экспресс курсы по буллингу и абьюзу
можно открыть видео-плеером и ставить на паузу в нужный момент
Заголовок не соответствует содержанию. "C" падает, значит можно сказать, что в рейтинге TIOBE начали падать быстрые языки программирования
Часто слышу как ФАС кого-то из крупных компаний проверит. Но почти никогда потом не слышу, что цены упали. Т.е. они ждут пока основные продажи пройдут, потом приходят с проверкой, получают денежку и уходят, но момент уже упущен. И получается все довольны, кроме потребителей, а схема потом повторяется
Победит бомж с помойки за пирожок. Представляете сколько пирожков можно купить за $20?
Зато в шумном (а часто и душном) офисе сразу такой цветущий, благоухающий и счастливый, потратив +3 часа жизни на дорогу