Ну я конкретно в веб разработке поменьше, лет 6, до этого был в десктоп разработке + администрирование сетей/серверов. Причём я буквально тот самый создатель "массового продукта", потому что пишу в основном под wordpress и laravel на php, сейчас немного вкатываюсь в go.) У меня как раз много проектов сейчас скопилось, где git и автотесты не использовали и они с годами превратилось в legacy ад. Хороший пример сайты на wordpress. Сам по себе wp очень плохо поддаётся покрытию тестов. С git ещё ладно, можно вынести в репозитории отдельные плагины, чтобы не тащить всё на сервера, какого-нибудь github. Я специально для этого создал даже небольшую composer библиотеку, что основана на основе шаблонного метода (да, да, да сейчас тут на хабре мне расскажут, что нужно было DDD пихать, а я такое видел, и вообще делать плагин для wp на миркросервисах иначе не тру архитектура) и позволяет создавать плагины в ООП стиле, отделяя бизнес логику от wp приколов, по типу action filter и прочего. Правда моя библиотека тоже кривая, но лучше, чем ничего.) Надо бы её довести до ума как-нибудь.
Так вот, даже моя кривая библиотека позволила покрывать тестами код wp плагинов и это облегчило жизнь, убрав огромное количество плавающих багов. В wp они не редкость, где action в action в filter с кучей transients. А теперь представьте, что со всем этим нужно подружить нейросеть и чтобы она ничего не сломала.) К слову, о нейросетях, сейчас все агентные нейронки, по типу claude, codex и т.д., не просто так создают папочку project_name.worktree с отдельной git веткой внутри и не удаляет её после apply.) Codex вон вообще работает через github создавая самостоятельно PR.
Касаемо тестов, ну вот недавно у меня была задача написать десяток сложных медицинских калькуляторов, где расчёт шёл не просто по формуле, а с использованием разных медицинских таблиц и особенностей расчётов, интерпретаций ответов исходя из научных статей. Конечно, все расчёты для калькуляторов были изолированы друг от друга, но без покрытия тестов, я не представляю, как бы этот проект закрыл. Учитывая, что калькуляторы могут использовать одни и те же таблицы, а нейронка, чтобы подогнать ответ обожала их немного менять, либо если запретить им строго менять, они делали "хаки", т.е. пытались подогнать например округлением или интерполяцией под ответ. Но когда есть десяток тестов с 100-1000 кейсами основанных на эталонных данных, уже мухлевать ей было сложно. Поэтому и говорю, что не представляю как сейчас делать проекты без git и unit тестов. Причём unit тесты это один из типов тестов, которых намного больше, но unit имхо это базовый минимум) Тем-более, что сейчас можно тестами покрывать проект "лениво" при помощи тех же нейронок. Да, так лучше не делать, но это лучше, чем ничего.) Главное следить чтобы не было галлюцинаций наподобие assert(true, true), нейронки такое любят 😂.
В общем, советую попробовать применить у себя в проектах хотя бы unit тесты. Поначалу будет непривычно, но потом вы даже не представляете, как вам это жизнь облегчит, даже если вы ведёте один проект и один программист на нём, который идеально его знает.)
Про первую ситуацию из первого вопроса. Если тикет гуляет по кругу, а команды по сути перекладывают друг на друга ответственность, то проблема в такой компании явно не на уровне сеньора, а на уровне организации работы. Так же, почему-то не была упомянута команда тестировщиков, которая и должна воспроизвести баг. Понимаю, что хотел сказать автор, но ответил бы на первый вопрос немного иначе. За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
В то время, как tg давно создал mini app и полноценную экосистему внутри своего приложения, мах завёз ботов без какой-либо тех. поддержки, доступных не всем, так ещё и работающих криво судя по комментариям.
Имхо, но если уж быть турбопатриотом, то даже вк выглядит намного лучше в этом плане, потому что он имеет свою устоявшуюся годами экосистему с ботами и аналогом mini app, а так же нормальным саппортом и документацией и главное даже в нём создание ботов доступно всем.
Если что, не пиарю вк (потому что его современные владельцы создали макс), просто говорю какое же говно вам пытаются скормить взамен тг и других мессенджеров. Честно, учитывая какое отношение к максу у народа, я бы просто его уже закрыл и не мучил. Но учитывая, что макс принадлежит, вроде как сынку Кириенко и что на нём наверное пилят огромные бабки, никто ничего сворачивать не собирается.
Я пробежался по комитам и есть ощущение, что проект полностью навайбкожен. Ничего против использования в программировании нейронок не имею, но такое ощущение, что автор в целом плохо разбирается в программировании. Отсюда и вск вышеописанные проблемы. Хотя, могу ошибаться.
Если с английским ещё ладно, по нему информации много и когда его учил проблем с приложениями курсами и т.д. не было, то с мало популярныи яп (например сейчас учу румынский) приложения часто отсутствуют, либо содержат много ошибок.
Я по итогу, делаю своё приложение, где хочу совместить приятное с полезным. Фишка его в том, что он работает как лидкод, но для изучения языков. Все задачи построены по языку так, что вам нужно написать алгоритм для решения задачи, не просто слова подставить или выбрать вариант ответа.
Простой пример, в румынском есть спряжение глаголов и прилагательных в зависимости от числа, рода и времени. Есть правила спряжений со своими исключениями. Вам, как программисту, нужно написать функцию, что будет применять в себя слово, род, число и возвращать правильное склонение с учётом исключений. Есть набор юнит тестов (скажем на 500 ассертов) этой функции.
Вы скажете: "да там алгоритм будет на одних if, чего сложного?". Я отвечу что здесь главное не написать идеальный алгоритм O(n), а структурировать у себя а голове все правила, изучаемого языка. Лично мне куда проще запомнить правила, особенно комплексные с исключениями, когда по ним напишу код.
Да и андроид планшет в эту цену с более мощными характеристиками можно спокойно найти. Даже с клавиатурой.
Здесь скорее вопрос не в наивности. Каждый родитель хочет порадовать своё чадо. 50$ не такая большая цена. Если ребенок например сломает "игрушку", то вроде как жаль, но не критично. Так же, это неплохой вариант для семей с небольшим достатком. Думаю народ прекрасно понимает, что покупает и чего особо от таких планшетов не ожидает.)
AI ученый в контексте моченый.) Извините за такой комментарий, но честно, уже надоели эти маркетинговые обещания. Какой смысл в AI ученом, если реальные ученые давно используют нейронки, причём зачастую их пишут самостоятельно под определенные задачи. Llm хорошее подспорье, но создание универсальной системы на её основе. Не знаю насколько это целесообразно. Хотя как система, что сможет корректно объяснять обычным людям сложные научные темы, почему нет. Правда с этим и текущие модели справляются более-менее нормально.
Тоже пришёл к чему-то похожему, только с немного другим подходом.
1) Этап планирования и сбор ТЗ
2) Этап создания архитектуры проекта, желательно с минимальным вовлечением ИИ. Здесь создаю документацию, skills, rules, файлы классов с их описанием и примерным набором критически важных методов/свойств. Устанавливаю все необходимые зависимости, настраиваю хуки, git и рабочие области, пишу предварительные unit тесты, настраиваю CI/CD в общем максимально подготавливаю проект для работы llm, чтобы он мог фокусироваться только на коде, а промпты сводились к описанию задачи.
3) После того, как каркас проекта готов, "отдаю" его в работу бэкграунд агентам. Мой любимый это Codex, т.к. он под каждую задачу создаёт отдельную ветку, а после выполнения делает PR. Это очень удобно. Однако, после перехода кодекс на gpt5, openAI сильно начали душить лимитами, без возможности переключения на более старые версии. В целом способов организовать работу много.
Далее, как у автора, идут итерации разработки с тщательной слежкой и правками того, что там выдала llm.
Описал сумбурно, но думаю смысл понятен. Не то чтобы это какой-то ультимативный подход, скорее один из сотен, который лично мне ближе по душе и который можно изменять, как угодно под разные проекты (везде своя специфика).
Знаете, что самое забавное, по сути ничего не поменялось. Всё что описал автор, я или описано в полноценных методиках/подходах, применимо к обычной ручной разработке. Просто сейчас нейросети требуют для качественной разработки следовать подходам, культуре кода, рекомендациям, паттернам и т.д. которыми многие принебрегали до хайпа нейронок. Если раньше, это был вопрос организации работы в больших командах и банального удобства, то сейчас это технический вопрос. Скорее даже необходимость для адекватной работы с нейронками.
Знаете, что самое забавное в текущей ситуации. HR автоматизируют отсев кандидатов при помощи ИИ. Кандидаты автоматизируют создание релевантных резюме под каждую вакансию. По итогу, одни ИИ пытаются обмануть другие ИИ, а те в свою очередь обойти отсев первых. 😂
По итогу, это даже не клоунада, найм просто сломан и работодатели вернулись к единственному способу отсева, который в данном случае работает - блату.
В такой системе джунам почти нет места (учитывая, что их поджимают нейронки), рынок понемногу охлаждается, что в будущем приведёт к ещё бОльшему дефициту специализированных кадров. Новых подходов в найме не появилось, следовательно, проблема решена не будет.
Касаемо же информации в посте, то он немного запоздал. Всё описанное было актуально году в 2023. Уже тогда llm активно использовали HR в своей работе для отсева кандидатов и уже тогда появились и первые лайфхаки со стороны кандидатов, как нейронку можно обмануть.
Это правда, контроллеры должны быть тонкими. Обычно всю бизнес логику из них выносят в сервисы (как минимум), а оттуда уже "распихивают" на более мелкие классы/модули/и т.д., если сервис разрастается. Опять же зависит от архитекторы, но контроллер бизнес логику содержать не должен.
Для всего остального используют middlewares, validators, паресры, всяческие надстройки для request response и т.д. (зависит от фреймворка или в целом от lifecycle архитектуры проекта).
И приходится заставлять себя вчитываться в то, что выдано.
Я всегда, проверяю весь кол в 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 например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.
Ну я конкретно в веб разработке поменьше, лет 6, до этого был в десктоп разработке + администрирование сетей/серверов. Причём я буквально тот самый создатель "массового продукта", потому что пишу в основном под wordpress и laravel на php, сейчас немного вкатываюсь в go.) У меня как раз много проектов сейчас скопилось, где git и автотесты не использовали и они с годами превратилось в legacy ад. Хороший пример сайты на wordpress. Сам по себе wp очень плохо поддаётся покрытию тестов. С git ещё ладно, можно вынести в репозитории отдельные плагины, чтобы не тащить всё на сервера, какого-нибудь github. Я специально для этого создал даже небольшую composer библиотеку, что основана на основе шаблонного метода (да, да, да сейчас тут на хабре мне расскажут, что нужно было DDD пихать, а я такое видел, и вообще делать плагин для wp на миркросервисах иначе не тру архитектура) и позволяет создавать плагины в ООП стиле, отделяя бизнес логику от wp приколов, по типу action filter и прочего. Правда моя библиотека тоже кривая, но лучше, чем ничего.) Надо бы её довести до ума как-нибудь.
Так вот, даже моя кривая библиотека позволила покрывать тестами код wp плагинов и это облегчило жизнь, убрав огромное количество плавающих багов. В wp они не редкость, где action в action в filter с кучей transients. А теперь представьте, что со всем этим нужно подружить нейросеть и чтобы она ничего не сломала.) К слову, о нейросетях, сейчас все агентные нейронки, по типу claude, codex и т.д., не просто так создают папочку project_name.worktree с отдельной git веткой внутри и не удаляет её после apply.) Codex вон вообще работает через github создавая самостоятельно PR.
Касаемо тестов, ну вот недавно у меня была задача написать десяток сложных медицинских калькуляторов, где расчёт шёл не просто по формуле, а с использованием разных медицинских таблиц и особенностей расчётов, интерпретаций ответов исходя из научных статей. Конечно, все расчёты для калькуляторов были изолированы друг от друга, но без покрытия тестов, я не представляю, как бы этот проект закрыл. Учитывая, что калькуляторы могут использовать одни и те же таблицы, а нейронка, чтобы подогнать ответ обожала их немного менять, либо если запретить им строго менять, они делали "хаки", т.е. пытались подогнать например округлением или интерполяцией под ответ. Но когда есть десяток тестов с 100-1000 кейсами основанных на эталонных данных, уже мухлевать ей было сложно. Поэтому и говорю, что не представляю как сейчас делать проекты без git и unit тестов. Причём unit тесты это один из типов тестов, которых намного больше, но unit имхо это базовый минимум) Тем-более, что сейчас можно тестами покрывать проект "лениво" при помощи тех же нейронок. Да, так лучше не делать, но это лучше, чем ничего.) Главное следить чтобы не было галлюцинаций наподобие assert(true, true), нейронки такое любят 😂.
В общем, советую попробовать применить у себя в проектах хотя бы unit тесты. Поначалу будет непривычно, но потом вы даже не представляете, как вам это жизнь облегчит, даже если вы ведёте один проект и один программист на нём, который идеально его знает.)
Про первую ситуацию из первого вопроса. Если тикет гуляет по кругу, а команды по сути перекладывают друг на друга ответственность, то проблема в такой компании явно не на уровне сеньора, а на уровне организации работы. Так же, почему-то не была упомянута команда тестировщиков, которая и должна воспроизвести баг. Понимаю, что хотел сказать автор, но ответил бы на первый вопрос немного иначе. За все задачи, что поступают мне ответственен я, пока они не будут выполнены, либо пока на 100% не буду уверен, что проблема не в моей зоне ответственности, после чего передам тикет с подробным описанием ресёрча и всеми обоснованиями, предположениями, тестами. Чего буду в подобных ситуациях ждать и от коллег, а не просто "у нас всё хорошо, ищите сами", я то найду, но если выяснится, что проблема всё же на строне коллег выйдет неприятный момент.
Касаемо тестов. Ответ в наших реалиях очень простой. Без git и unit тестов даже разработка пет проектов невозможна. Это базовый минимум в наши дни, особенно с приходом llm, которые программисты любят использовать, но не особо любят ревювить их код. Без тестов, проект сейчас просто невозможно адекватно поддерживать вдолгую. Какую бы вы замороченную и идеальную архитектуру не выбрали и какую бы навороченную инфру вокруг неё не выстроили, без тестов это превратиться со временем в кучу малу.
Имхо, но эти вопросы сейчас валидны для всех. Я мидл разработчик и это 2 базовых вопроса, которые и джунам задают.
Мне кажется сейчас в принципе актуальнее вопрос про ответственность, потому что именно за неё мы получаем зп. Контракт с бизнесом очень прост. Бизнес платит деньги нам не за писульки кода, а за ответственность стабильной работы созданных по запросу бизнеса решений. Всем плевать, что вы использовали лучшие практики. Если что-то не работает спрашивают с нас. Да да, капитан очевидность, но вы даже не представляете, как много людей не понимают этой простой истины. Бизнес не будет слушать про, то что json'ы пользователю не приходят из-за особенностей вашей же выстроенной архитектуры, он найдет вместо вас тех, кто сделает так, чтобы json'ы приходили, если вы не хотите нести за это ответственность.
В то время, как tg давно создал mini app и полноценную экосистему внутри своего приложения, мах завёз ботов без какой-либо тех. поддержки, доступных не всем, так ещё и работающих криво судя по комментариям.
Имхо, но если уж быть турбопатриотом, то даже вк выглядит намного лучше в этом плане, потому что он имеет свою устоявшуюся годами экосистему с ботами и аналогом mini app, а так же нормальным саппортом и документацией и главное даже в нём создание ботов доступно всем.
Если что, не пиарю вк (потому что его современные владельцы создали макс), просто говорю какое же говно вам пытаются скормить взамен тг и других мессенджеров. Честно, учитывая какое отношение к максу у народа, я бы просто его уже закрыл и не мучил. Но учитывая, что макс принадлежит, вроде как сынку Кириенко и что на нём наверное пилят огромные бабки, никто ничего сворачивать не собирается.
Я пробежался по комитам и есть ощущение, что проект полностью навайбкожен. Ничего против использования в программировании нейронок не имею, но такое ощущение, что автор в целом плохо разбирается в программировании. Отсюда и вск вышеописанные проблемы. Хотя, могу ошибаться.
Если с английским ещё ладно, по нему информации много и когда его учил проблем с приложениями курсами и т.д. не было, то с мало популярныи яп (например сейчас учу румынский) приложения часто отсутствуют, либо содержат много ошибок.
Я по итогу, делаю своё приложение, где хочу совместить приятное с полезным. Фишка его в том, что он работает как лидкод, но для изучения языков. Все задачи построены по языку так, что вам нужно написать алгоритм для решения задачи, не просто слова подставить или выбрать вариант ответа.
Простой пример, в румынском есть спряжение глаголов и прилагательных в зависимости от числа, рода и времени. Есть правила спряжений со своими исключениями. Вам, как программисту, нужно написать функцию, что будет применять в себя слово, род, число и возвращать правильное склонение с учётом исключений. Есть набор юнит тестов (скажем на 500 ассертов) этой функции.
Вы скажете: "да там алгоритм будет на одних if, чего сложного?". Я отвечу что здесь главное не написать идеальный алгоритм O(n), а структурировать у себя а голове все правила, изучаемого языка. Лично мне куда проще запомнить правила, особенно комплексные с исключениями, когда по ним напишу код.
Да и андроид планшет в эту цену с более мощными характеристиками можно спокойно найти. Даже с клавиатурой.
Здесь скорее вопрос не в наивности. Каждый родитель хочет порадовать своё чадо. 50$ не такая большая цена. Если ребенок например сломает "игрушку", то вроде как жаль, но не критично. Так же, это неплохой вариант для семей с небольшим достатком. Думаю народ прекрасно понимает, что покупает и чего особо от таких планшетов не ожидает.)
AI ученый в контексте моченый.) Извините за такой комментарий, но честно, уже надоели эти маркетинговые обещания. Какой смысл в AI ученом, если реальные ученые давно используют нейронки, причём зачастую их пишут самостоятельно под определенные задачи. Llm хорошее подспорье, но создание универсальной системы на её основе. Не знаю насколько это целесообразно. Хотя как система, что сможет корректно объяснять обычным людям сложные научные темы, почему нет. Правда с этим и текущие модели справляются более-менее нормально.
Тоже пришёл к чему-то похожему, только с немного другим подходом.
1) Этап планирования и сбор ТЗ
2) Этап создания архитектуры проекта, желательно с минимальным вовлечением ИИ. Здесь создаю документацию, skills, rules, файлы классов с их описанием и примерным набором критически важных методов/свойств. Устанавливаю все необходимые зависимости, настраиваю хуки, git и рабочие области, пишу предварительные unit тесты, настраиваю CI/CD в общем максимально подготавливаю проект для работы llm, чтобы он мог фокусироваться только на коде, а промпты сводились к описанию задачи.
3) После того, как каркас проекта готов, "отдаю" его в работу бэкграунд агентам. Мой любимый это Codex, т.к. он под каждую задачу создаёт отдельную ветку, а после выполнения делает PR. Это очень удобно. Однако, после перехода кодекс на gpt5, openAI сильно начали душить лимитами, без возможности переключения на более старые версии. В целом способов организовать работу много.
Далее, как у автора, идут итерации разработки с тщательной слежкой и правками того, что там выдала llm.
Описал сумбурно, но думаю смысл понятен. Не то чтобы это какой-то ультимативный подход, скорее один из сотен, который лично мне ближе по душе и который можно изменять, как угодно под разные проекты (везде своя специфика).
Знаете, что самое забавное, по сути ничего не поменялось. Всё что описал автор, я или описано в полноценных методиках/подходах, применимо к обычной ручной разработке. Просто сейчас нейросети требуют для качественной разработки следовать подходам, культуре кода, рекомендациям, паттернам и т.д. которыми многие принебрегали до хайпа нейронок. Если раньше, это был вопрос организации работы в больших командах и банального удобства, то сейчас это технический вопрос. Скорее даже необходимость для адекватной работы с нейронками.
Я буду читать точно) И на дтф жду подборки интересных в тех. реализации j2me игр
Знаете, что самое забавное в текущей ситуации. HR автоматизируют отсев кандидатов при помощи ИИ. Кандидаты автоматизируют создание релевантных резюме под каждую вакансию. По итогу, одни ИИ пытаются обмануть другие ИИ, а те в свою очередь обойти отсев первых. 😂
По итогу, это даже не клоунада, найм просто сломан и работодатели вернулись к единственному способу отсева, который в данном случае работает - блату.
В такой системе джунам почти нет места (учитывая, что их поджимают нейронки), рынок понемногу охлаждается, что в будущем приведёт к ещё бОльшему дефициту специализированных кадров. Новых подходов в найме не появилось, следовательно, проблема решена не будет.
Касаемо же информации в посте, то он немного запоздал. Всё описанное было актуально году в 2023. Уже тогда llm активно использовали HR в своей работе для отсева кандидатов и уже тогда появились и первые лайфхаки со стороны кандидатов, как нейронку можно обмануть.
Это правда, контроллеры должны быть тонкими. Обычно всю бизнес логику из них выносят в сервисы (как минимум), а оттуда уже "распихивают" на более мелкие классы/модули/и т.д., если сервис разрастается. Опять же зависит от архитекторы, но контроллер бизнес логику содержать не должен.
Для всего остального используют middlewares, validators, паресры, всяческие надстройки для request response и т.д. (зависит от фреймворка или в целом от lifecycle архитектуры проекта).
Я всегда, проверяю весь кол в 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 например, вполне использовавшийся в энтерпрайзе пока не пришёл веб.