И приходится заставлять себя вчитываться в то, что выдано.
Я всегда, проверяю весь кол в diff режиме и считаю, что использование нейронок в разработке без git невозможна.
Честно и в отношении пет проектов есть много вопросов. Когда только вышел Codex, я ради эксперимента решил навайбкодить при помощи него игру. После десятка новых фишек и разрастания проекта, я полез уже серьезно в кол и ужаснулся. Там бал такой спагетти код, что даже новички напишут намного лучше. Поэтому работа с нейронками требует немного другого подхода с самого начала работы проекта.
Своими экспериментами я получил более-менее жизнеспособный пайплайн разработки, который бы позволил удобно организовать работу, но честно ответить на главный вопрос: "на долгую дистанцию разработки ИИ экономит время?", однозначный ответ дать не могу. Имхо экономит, но довольно мало.
Хороший посыл, который вроде простой, но многие этого не осознают. Я сам относительно недавно (несколько лет назад) осознал простую истину, что нет вообще никакого смысла гнаться за "крутыми", "модными" архитектурами и стеками в любом проекте.
Действительно, стек, архитектуру, паттерны определяет не мода, а реальная потребность при разработке. Золотые слова, про пример с сайтом на 3.5 пользователя а день. Зачем тратить впустую время и свои же человеко часы, если можно взять для этой задачи Вордпресс и просто сделать сайт без всяких выклбеливаний. Большинству заказчиков в целом всё-равно, как технически реализован их сервис им важно качество, время (ведь от него зависит бюджет проекта) и стабильность работы. Следовательно, нужно всегда планировать, что лучше всего подойдёт для того или иного проекта.
Касаемо кода, то сейчас наблюдаю довольно ироничную ситуацию. С приходом в разработку llm, по сути оказалось, что KISS DRY и часть SOLID, очень любимы нейронками. При этом "красивые", но мудреные подходы они не сильно любят. Почему так, описывать долго, но если коротко, то связано с принципами работы llm и mcp. Так что да, сложные решения нужно использовать тогда, когда в них есть реальная необходимость.
А, точно в C# же куча постоянно живёт и GC глохнет если очень много аллокаций. Эхх, понемногу начинаю, забывать специфику C#.( Надо бы на нём, что-то написать, чтобы обновить в памяти.
Да, вы правы мой код в C#, при очень частых вызовах будет "грузить" GC. Я кстати поэтому упомянул, что помещение условий в массив, не всегда уместна.)
Кстати мой пример, чтобы не грузить GC аллокациями можно, переделав, переместив условия из массивов в обычные методы/функции.
Кстати вы верно подметили, и написали хороший вариант для рефакторинга оригинального примера из статьи, там в целом код, как понял проблемный.
Когда много условий, как в примере, иногда выношу их в отдельные массивы. Переписал код из примера на C#, если что не верно, не ругайте (писал без компилятора под рукой, только попросил нейронку синтаксис поправить), но суть думаю понятна.
Вместо того, чтобы все условия писать в строчки, я их группирую в массивы, по смыслу. После, чего использую any() или другие похожие функции в других языках, чтобы реализовать "или" (если нужно "и" можно использовать all() или ему подобные, либо вообще написать эти функции самому они не то чтобы сложные цикл + условие). Если в исходном условии есть скобки, можно один массив вкладывать в другой.
Плюсы такого подхода? Как по мне, более читаемо, по массивам сразу видно, что именно проверяется, чем когда все условия в куче. Удобнее тестировать, в дебаге видны массивы результатов всех условий. Лично мне, проще вносить изменения в подобные массивы, т.к. точно не нарушу скобки. Если говорить по теме, то с таким подходом можно любые длинные условия развернуть и сгруппировать по смыслу.
Из минусов: any() и подобные функции генерируют больше операций (т.к. под капотом там цикл и условия), однако если мы работаем с фиксированным небольшим набором данных, то нагрузка хоть и увеличивается, но разница нулевая. Опять же, всё зависит от конкретного случая, поэтому и не использую такой подход повсеместно.
Лайв кодинг может помочь проверить скорее не хадр скилы, а как вообще человек кодит. Я с такими требованиями не встречался, но если бы мне поручили провести лайвкодинг, то дал бы простую задачу которую без доп контекста даже топовые нейронки до сих пор решают не верно. Лайвкодинг я бы проводил так: дал бы описание задачи в удобном формате для кандидата и попросил бы её решить с демонстрацией экрана у себя на компьютере в любой удобной для него ide. Причём разрешил бы даже нейронкой или гуглом пользоваться (ведь задачу нейронка решит не верно и кандидату придётся понять где ошибка и доработать её). При этом я бы не сидел, как профессор с троечником на экзамене, а постоянно бы направлял, общался, задавал наводящие вопросы, потому что мне моё время дорого и сидеть по часу молча, я не хочу.
И тут вопрос, а что бы я вообще проверил таким лайвкодингом? А намного больше, чем вы сможете проверить в вашей яндекс web ide с задачкой из литкода.
1) Мне важно было бы увидеть ide человека с которой он работает в привычных условиях (особенно если удаленка). Если человек, говорит, что он мидл-сеньор, но открывая например VSCode, у него нет ни одного плагина и он путается в интерфейсе, то что-то тут не то.
2) Нейронки сейчас используют очень многие, бороться с этим бессмысленно да и зачем? Следовательно, я хочу увидеть как человек пишет промпт, т.к. это важно и влияет напрямую на качество ответа нейронки. Если человек пишет "ну там это напиши чтобы всё работало по красоте вот задача:", то уже понятно, что человек не особо понимает, что хочет видеть в результате.
3) Как и говорил задачи бы брал с подвохом и нейронка в большинстве случаев кандидату выдало не верное решение, следовательно ему придётся показать, как он умеет решать задачи в данной ситуации, когда llm не спасает. Заучить решение задач с лит кода каждый может, а вот решить живой кейс нет.
Как по мне, только такой лайв кодинг имеет смысл и реально хоть что-то может показать. Всё остальное это извиняюсь за выражение дроч ради дрочи.
Твоя ценность — это твоя способность сформулировать задачу и заставить кремний работать на тебя. Это убивает предсказуемость. Больше нет гарантированных треков. Есть только ты и хаос.
Хм, так может, чтобы не было хаоса и была возможность грамотно строить технические промпты с последующей проверкой/доработкой проекта всё же нужны хард скилы из старого мира? 🤔
Да не, бред какой-то пойду дальше писать llm "сделаи код шоб робил красива без ашибак".
Касаемо робототехники, то в большинстве случаев разработка ведётся на C/C++ где по сути всё тоже самое в плане контроля. Особенно на более старых версиях, где иногда за ошибку может например восприниматься лишний пробел в конце файла.
Касаемо паскаля, то был же Delphi например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.
Уже есть. 54-ый с его командой, запихал в tg mini app, часть j2me игр и часть игр с ps1. Они это делают ради хайпа. Это на хабре все знают о wasm и многие тут сами в состоянии сделать такой порт (там кроме фронта на js, ничего кодить особо не нужно), а на других ресурсах, где люди далеки от IT, подобные заголовоки дают хайпа много.
Есть ещё один момент. Вроде как нет ни одного сустава в известной природе (я не биолог могу ошибаться), что мог бы прокручиваться на 360° огромное количество раз подряд. Да, например у сов шея крутится на 360° но они не могут крутить головой, словно лопасти вертолёта.
Мне кажется, построение тел, рез суставы куда более эффективный подход в наших реалиях. Эволюция всегда идёт по принципу: чем проще и эффективней, тем лучше.
Ну я тоже видел в PR конфликты, обычно это происходит если в одной задаче продолжать диалог по доработкам и не уточнить из какой ветки брать информацию. По итогу, он берёт из основной из-за чего появляются конфликты, но сколько их не видел они очень простые и в самом интерфейсе гитхаба фиксятся быстро. Так же, если соблюдать правило 1 задача - 1 запрос к Кодексу, то проблем вообще не возникает.
Пользуюсь им с мая месяца и мне он нравится. Проблем с ним не было, единственное он когда ещё на gpt 3 был, любил писать говнокод, но сейчас такого меньше.
Да нет, просто одно дело самому находить проблемные участки кода, описывать задачу нейронке, что нужно исправить и в чем проблема, с контролем и допиливанием результата генерации.
А другое дело вайбкодинг, когда "программист" пишет нейронке, что-то вроде: "окей gpt, напиши мне тг бот, что будет переводить текст в звук". А потом пихает весь код не глядя по файлам, получив на выходе scriptor-telegram. Как раз софт автора, что багет, выдаёт полные error trace stack с информацией о бэкенде и в целом не работает.
Если отвечать, на вопрос, то конечно чистый код будет. К слову, чистый код, это не только про пробелы и отступы.
Почитав комментарии вайбкодеров долго смеялся над их позицией. Мол нейронка любой код понимает, поэтому чистый код нужен только программистам...
Чистый код будет всегда, просто поменяется в будущем под особенности работы нейронок. LLM хорошо понимает именно языковые конструкции, которыми языки программирования и являются, следовательно в будущем, чистым кодом будет тот, который не только понятен и удобен человеку, но и так же понятен и удобен самим LLM. Поэтому не надейтесь, что стандарты куда-то исчезнут. Они уже активно формируются.
В комментариях, активно пишут, что программисты не нужны, сейчас вторые 90-ые и время возможностей. Скоро мол вайбкодеры заменят программистов, что читать смешно.
Вас заменят ещё быстрее, чем нас. Как раз, потому-что вы умеете только табать, без понимания тех. контекста. Для вас нейронки это не понятный инструмент, а бог из машины, что работает на магии.
Помню, когда только появились background агенты, тот же codex, многие таберы писали: "Выглядит круто, но что такое github? Консоль какая-то, этим как пользоваться, то вообще? А где скачать?". Сейчас бэкграунд агенты не редкость и уже часть таберов отсеялось. Потом агенты стало популярно деплоить локально и тут таберы офигели с docker и контейнеризации. Что-то таб не помогает разбираться, сложна.
Уже появились первые паттерны для работы с нейросетями. Например, как лучше передавать/получать данные в чатах. Какие температуры использовать, как правильно организовывать тот же RAG и как правильно использовать MCP. Дальше разработка вместе с нейросетями будет только усложняться и это нормально. Следовательно, станут востребованы настоящие программисты, с базой знаний/скилов, которым будет довольно просто будет во всём разобраться. Намного легче, чем человеку без тех. базы. Так что кардинально ничего не поменяется, а порог входа только вырастет.
Касаемо школ программирования, то они не особо смотрят на желания учеников, потому что те обычно мало знают о положении дел в IT. Обычно, они смотрят по каким направлениям проще всего, а главное дешевле, можно найти преподов. Например, сейчас сильно популярен python, следовательно на нём проще всего найти специалистов и внушить ученикам, перспективность изучения.
В школьной программе, есть предметы, которые не особо нужны при пост апокалипсисе. Например обществознание и право. Бесполезные знания, когда в мире нет государств в привычном понимании, а власть рождает винтовка.) Или например этика и изо. Но большинство знаний из современной школьной программы правда бы пригодились
Я всегда, проверяю весь кол в diff режиме и считаю, что использование нейронок в разработке без git невозможна.
Честно и в отношении пет проектов есть много вопросов. Когда только вышел Codex, я ради эксперимента решил навайбкодить при помощи него игру. После десятка новых фишек и разрастания проекта, я полез уже серьезно в кол и ужаснулся. Там бал такой спагетти код, что даже новички напишут намного лучше. Поэтому работа с нейронками требует немного другого подхода с самого начала работы проекта.
Своими экспериментами я получил более-менее жизнеспособный пайплайн разработки, который бы позволил удобно организовать работу, но честно ответить на главный вопрос: "на долгую дистанцию разработки ИИ экономит время?", однозначный ответ дать не могу. Имхо экономит, но довольно мало.
Хороший посыл, который вроде простой, но многие этого не осознают. Я сам относительно недавно (несколько лет назад) осознал простую истину, что нет вообще никакого смысла гнаться за "крутыми", "модными" архитектурами и стеками в любом проекте.
Действительно, стек, архитектуру, паттерны определяет не мода, а реальная потребность при разработке. Золотые слова, про пример с сайтом на 3.5 пользователя а день. Зачем тратить впустую время и свои же человеко часы, если можно взять для этой задачи Вордпресс и просто сделать сайт без всяких выклбеливаний. Большинству заказчиков в целом всё-равно, как технически реализован их сервис им важно качество, время (ведь от него зависит бюджет проекта) и стабильность работы. Следовательно, нужно всегда планировать, что лучше всего подойдёт для того или иного проекта.
Касаемо кода, то сейчас наблюдаю довольно ироничную ситуацию. С приходом в разработку llm, по сути оказалось, что KISS DRY и часть SOLID, очень любимы нейронками. При этом "красивые", но мудреные подходы они не сильно любят. Почему так, описывать долго, но если коротко, то связано с принципами работы llm и mcp. Так что да, сложные решения нужно использовать тогда, когда в них есть реальная необходимость.
Можно монолит создавать с учётом возможного перехода на микросервисы. Чтобы потом его без проблем попилить. Хуже от этого не станет)
А, точно в C# же куча постоянно живёт и GC глохнет если очень много аллокаций. Эхх, понемногу начинаю, забывать специфику C#.( Надо бы на нём, что-то написать, чтобы обновить в памяти.
Да, вы правы мой код в C#, при очень частых вызовах будет "грузить" GC. Я кстати поэтому упомянул, что помещение условий в массив, не всегда уместна.)
Кстати мой пример, чтобы не грузить GC аллокациями можно, переделав, переместив условия из массивов в обычные методы/функции.
Кстати вы верно подметили, и написали хороший вариант для рефакторинга оригинального примера из статьи, там в целом код, как понял проблемный.
Когда много условий, как в примере, иногда выношу их в отдельные массивы. Переписал код из примера на C#, если что не верно, не ругайте (писал без компилятора под рукой, только попросил нейронку синтаксис поправить), но суть думаю понятна.
Вместо того, чтобы все условия писать в строчки, я их группирую в массивы, по смыслу.
После, чего использую any() или другие похожие функции в других языках, чтобы реализовать "или" (если нужно "и" можно использовать all() или ему подобные, либо вообще написать эти функции самому они не то чтобы сложные цикл + условие). Если в исходном условии есть скобки, можно один массив вкладывать в другой.
Плюсы такого подхода? Как по мне, более читаемо, по массивам сразу видно, что именно проверяется, чем когда все условия в куче. Удобнее тестировать, в дебаге видны массивы результатов всех условий. Лично мне, проще вносить изменения в подобные массивы, т.к. точно не нарушу скобки. Если говорить по теме, то с таким подходом можно любые длинные условия развернуть и сгруппировать по смыслу.
Из минусов: any() и подобные функции генерируют больше операций (т.к. под капотом там цикл и условия), однако если мы работаем с фиксированным небольшим набором данных, то нагрузка хоть и увеличивается, но разница нулевая. Опять же, всё зависит от конкретного случая, поэтому и не использую такой подход повсеместно.
Да, но видимо есть причина почему не делали SDK на паскале (учитывая популярность языка в своё время).
Лайв кодинг может помочь проверить скорее не хадр скилы, а как вообще человек кодит. Я с такими требованиями не встречался, но если бы мне поручили провести лайвкодинг, то дал бы простую задачу которую без доп контекста даже топовые нейронки до сих пор решают не верно. Лайвкодинг я бы проводил так: дал бы описание задачи в удобном формате для кандидата и попросил бы её решить с демонстрацией экрана у себя на компьютере в любой удобной для него ide. Причём разрешил бы даже нейронкой или гуглом пользоваться (ведь задачу нейронка решит не верно и кандидату придётся понять где ошибка и доработать её). При этом я бы не сидел, как профессор с троечником на экзамене, а постоянно бы направлял, общался, задавал наводящие вопросы, потому что мне моё время дорого и сидеть по часу молча, я не хочу.
И тут вопрос, а что бы я вообще проверил таким лайвкодингом? А намного больше, чем вы сможете проверить в вашей яндекс web ide с задачкой из литкода.
1) Мне важно было бы увидеть ide человека с которой он работает в привычных условиях (особенно если удаленка). Если человек, говорит, что он мидл-сеньор, но открывая например VSCode, у него нет ни одного плагина и он путается в интерфейсе, то что-то тут не то.
2) Нейронки сейчас используют очень многие, бороться с этим бессмысленно да и зачем? Следовательно, я хочу увидеть как человек пишет промпт, т.к. это важно и влияет напрямую на качество ответа нейронки. Если человек пишет "ну там это напиши чтобы всё работало по красоте вот задача:", то уже понятно, что человек не особо понимает, что хочет видеть в результате.
3) Как и говорил задачи бы брал с подвохом и нейронка в большинстве случаев кандидату выдало не верное решение, следовательно ему придётся показать, как он умеет решать задачи в данной ситуации, когда llm не спасает. Заучить решение задач с лит кода каждый может, а вот решить живой кейс нет.
Как по мне, только такой лайв кодинг имеет смысл и реально хоть что-то может показать. Всё остальное это извиняюсь за выражение дроч ради дрочи.
Хм, так может, чтобы не было хаоса и была возможность грамотно строить технические промпты с последующей проверкой/доработкой проекта всё же нужны хард скилы из старого мира? 🤔
Да не, бред какой-то пойду дальше писать llm "сделаи код шоб робил красива без ашибак".
Касаемо робототехники, то в большинстве случаев разработка ведётся на C/C++ где по сути всё тоже самое в плане контроля. Особенно на более старых версиях, где иногда за ошибку может например восприниматься лишний пробел в конце файла.
Касаемо паскаля, то был же Delphi например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.
Уже есть. 54-ый с его командой, запихал в tg mini app, часть j2me игр и часть игр с ps1. Они это делают ради хайпа. Это на хабре все знают о wasm и многие тут сами в состоянии сделать такой порт (там кроме фронта на js, ничего кодить особо не нужно), а на других ресурсах, где люди далеки от IT, подобные заголовоки дают хайпа много.
Есть ещё один момент. Вроде как нет ни одного сустава в известной природе (я не биолог могу ошибаться), что мог бы прокручиваться на 360° огромное количество раз подряд. Да, например у сов шея крутится на 360° но они не могут крутить головой, словно лопасти вертолёта.
Мне кажется, построение тел, рез суставы куда более эффективный подход в наших реалиях. Эволюция всегда идёт по принципу: чем проще и эффективней, тем лучше.
Ну я тоже видел в PR конфликты, обычно это происходит если в одной задаче продолжать диалог по доработкам и не уточнить из какой ветки брать информацию. По итогу, он берёт из основной из-за чего появляются конфликты, но сколько их не видел они очень простые и в самом интерфейсе гитхаба фиксятся быстро. Так же, если соблюдать правило 1 задача - 1 запрос к Кодексу, то проблем вообще не возникает.
Пользуюсь им с мая месяца и мне он нравится. Проблем с ним не было, единственное он когда ещё на gpt 3 был, любил писать говнокод, но сейчас такого меньше.
Да нет, просто одно дело самому находить проблемные участки кода, описывать задачу нейронке, что нужно исправить и в чем проблема, с контролем и допиливанием результата генерации.
А другое дело вайбкодинг, когда "программист" пишет нейронке, что-то вроде: "окей gpt, напиши мне тг бот, что будет переводить текст в звук". А потом пихает весь код не глядя по файлам, получив на выходе scriptor-telegram. Как раз софт автора, что багет, выдаёт полные error trace stack с информацией о бэкенде и в целом не работает.
В этом и есть разница.
Просто он настолько старый, что застал времена, когда ещё не было exception и debug режима.))
В том, то и дело, что по определению это и есть подход, когда пользователь ничего в коде понимать не должен, а нейронка всё делает за него.
Программист, использующий нейронки в работе, не равно вайбкодер. Так что в моих словах противоречия нет.
Если отвечать, на вопрос, то конечно чистый код будет. К слову, чистый код, это не только про пробелы и отступы.
Почитав комментарии вайбкодеров долго смеялся над их позицией. Мол нейронка любой код понимает, поэтому чистый код нужен только программистам...
Чистый код будет всегда, просто поменяется в будущем под особенности работы нейронок. LLM хорошо понимает именно языковые конструкции, которыми языки программирования и являются, следовательно в будущем, чистым кодом будет тот, который не только понятен и удобен человеку, но и так же понятен и удобен самим LLM. Поэтому не надейтесь, что стандарты куда-то исчезнут. Они уже активно формируются.
В комментариях, активно пишут, что программисты не нужны, сейчас вторые 90-ые и время возможностей. Скоро мол вайбкодеры заменят программистов, что читать смешно.
Вас заменят ещё быстрее, чем нас. Как раз, потому-что вы умеете только табать, без понимания тех. контекста. Для вас нейронки это не понятный инструмент, а бог из машины, что работает на магии.
Помню, когда только появились background агенты, тот же codex, многие таберы писали: "Выглядит круто, но что такое github? Консоль какая-то, этим как пользоваться, то вообще? А где скачать?". Сейчас бэкграунд агенты не редкость и уже часть таберов отсеялось. Потом агенты стало популярно деплоить локально и тут таберы офигели с docker и контейнеризации. Что-то таб не помогает разбираться, сложна.
Уже появились первые паттерны для работы с нейросетями. Например, как лучше передавать/получать данные в чатах. Какие температуры использовать, как правильно организовывать тот же RAG и как правильно использовать MCP. Дальше разработка вместе с нейросетями будет только усложняться и это нормально. Следовательно, станут востребованы настоящие программисты, с базой знаний/скилов, которым будет довольно просто будет во всём разобраться. Намного легче, чем человеку без тех. базы. Так что кардинально ничего не поменяется, а порог входа только вырастет.
Касаемо школ программирования, то они не особо смотрят на желания учеников, потому что те обычно мало знают о положении дел в IT. Обычно, они смотрят по каким направлениям проще всего, а главное дешевле, можно найти преподов. Например, сейчас сильно популярен python, следовательно на нём проще всего найти специалистов и внушить ученикам, перспективность изучения.
И тут можно плавно подойти к вопросу, о роли человека в мире, где развиты роботизация и ai. Не окажется ли она "выдуманной", "не настоящей".
В школьной программе, есть предметы, которые не особо нужны при пост апокалипсисе. Например обществознание и право. Бесполезные знания, когда в мире нет государств в привычном понимании, а власть рождает винтовка.) Или например этика и изо. Но большинство знаний из современной школьной программы правда бы пригодились