Объективных оценок тут наверное сложно представить)
Если формализовать это более приземлённо, то код который я не сам писал сам, а через агента с этапом планирования и ревью, в течении полугода я с большим процентом вероятности расскажу что и зачем в нем происходит. Ну естественно при условии, что никто рядом ничего не переделывал :)
Согласен с вами, что чем меньше вникаешь к то что делает агент, тем меньше ты владеешь кодом. Но есть ряд задач, например фронтенд часть простой формочки, которую можно перегенировать хоть каждый день и прям детально в нее вникать нет никакого смысла и достаточно высокоуровневого понимания ее работы и контекста работы. Главное чтобы такое отношение, не начиналось для критически важных частей проекта)
Ещё один рабочий подход: CLAUDE.md не пишешь сам, а спрашиваешь агента после сессии «что ты узнал об этом модуле, что стоит зафиксировать?» Получается живой документ, который обновляется в процессе работы.
Но в таком случае он как раз начинает раздуваться :)
На самом деле оптимально сразу же добавить директорию для спек (specs или docs) и туда разложить минимальный набор по архитектуре, фичам, сценариям и постепенно автоматически пополнять после каждого коммита - это правило сразу можно зашить в тот же CLAUDE.md :)
Тут вопрос размеров и что для вас значит мелкая задача) Если поправить пару классов с понятным фиксом, то да, тут руками это будет очевидно быстрее.
Если речь про "есть проблема, но нет плана" как будто бы стоит сразу идти в /plan с набросками своей реализации, чтобы агент учел это.
А какие модельки используете? По своему опыту скажу, что план лучше строить с "умной" условной GPT5.4-medium (лучше reasoning high), а реализацию уже можно модели "потупее" отдать.
Посмотрю код, подумаю. Выкину процентов 10-20 (в основном не нужные проверки), что-то добавлю, что-то исправлю. Процентов 60-70, наверное, останется близко к сгенерированному
Это кстати довольно хорошо решается спецификациями и пометками AGENTS.md, чтобы в будущем исключать заведомо ненужные куски кода. ;)
На мой взгляд условный "крутой программист" этот тот кто решает задачи бизнеса в кратчайшие сроки и с оптимальным качеством. Странно кичится своим стеком и тем что кто-то может или НЕ может, например запрограммировать микропроцессор (открою небольшую тайну, с АИ-шкой на перевес можно решать много задач и программирование микроконтроллеров, уверен, не исключение).
По себе могу сказать, что производительность решения задач выросла в разы. Объемные рефакторинги, межмодульные зависимости и целый ряд других задач решаются сильно проще и быстрее. И я до сих пор в любой момент времени могу сказать что делает МОЙ код, который написал агент, под моим присмотром, а не я ;-)
На это есть комментарии, в которых коллеги смогут меня дополнить. Спасибо вам за это ;-)
Но тут вставлю свои пять копеек: дописывать нейронка скиллы может и вполне успешно это делает, но вот писать с нуля ей адекватно почему-то не удаётся, уж слишком многословно она излагается, что не всегда хорошо влияет на эффективность (в основном работаю с GPT5.4-high на таких задачках). Поэтому я стартую со стандартного скилла "create-skill" внутри курсор, затем выкидываю половину (немного утрирую) того что нагенерилось и далее по ходу работы пополняю и корректирую скилл.
Вы, конечно, спросите: а почему в Сочи такие дорогие квартиры? А потому что грамотная и осознанная политика одного человека привела к тому, что теперь вся Россия отдыхает здесь.
Какой-то туповатый ресрерч. Вам кто-то закрыл Турцию, Египет, Китай, Тайланд, прочую Азию и т.д.? Если бы турпоток из России в Турцию закрылся, то там бы страна была на гране экономического краха :D
С кастомными сущностями и связями не поработаешь из коробки
На базе ORM все прекрасно работает, в чем именно трудность?
Прошло уже много времени, а документации по данной фиче я не нашел
Документация по данному материалу к сожалению не готова, за изменениями в документации можете следить в нашем ТГ канале: https://t.me/bitrixdoc , или периодически заглядывать на сайт доки и гитхаб: https://docs.1c-bitrix.ru/
Конкретно по гриду в данном материале старался описать все достаточно подробно, чтобы было понятно как с ним работать. С чем именно возникают трудности?
Довольно странный пример, потому что очень похоже что вместо отдельных роутов вы хотите сделать какой-то один динамический. Ну и в целом ваша «проблема» решается использованием разделителя между abcd, который поддерживается URL строкой
Интересно вы конечно делаете (пытаетесь скрестить битрикс, ларавель и симфони).
Не обижайте Yii , он тоже хороший доннор для скрещивания :)
но ни слова как это подружить с компонентами, с Эрмитажем, да хоть просто со страницами. Ни слова что добавили урезанный до невозможности view(). Да, все это есть в документации, тогда для чего бессмысленная статья?
Статья про роутинг, а не про "всё на свете". Не переживайте, про работу с контроллерами статья будет.
(это возможно, у меня получилось, но костыли вам обеспечены)
Нельзя скрывать такое творчество от общественности, с нетерпеньем жду от вас статью с деталями ;)
Объективных оценок тут наверное сложно представить)
Если формализовать это более приземлённо, то код который я не сам писал сам, а через агента с этапом планирования и ревью, в течении полугода я с большим процентом вероятности расскажу что и зачем в нем происходит. Ну естественно при условии, что никто рядом ничего не переделывал :)
Согласен с вами, что чем меньше вникаешь к то что делает агент, тем меньше ты владеешь кодом. Но есть ряд задач, например фронтенд часть простой формочки, которую можно перегенировать хоть каждый день и прям детально в нее вникать нет никакого смысла и достаточно высокоуровневого понимания ее работы и контекста работы. Главное чтобы такое отношение, не начиналось для критически важных частей проекта)
Но в таком случае он как раз начинает раздуваться :)
На самом деле оптимально сразу же добавить директорию для спек (specs или docs) и туда разложить минимальный набор по архитектуре, фичам, сценариям и постепенно автоматически пополнять после каждого коммита - это правило сразу можно зашить в тот же CLAUDE.md :)
Тут вопрос размеров и что для вас значит мелкая задача) Если поправить пару классов с понятным фиксом, то да, тут руками это будет очевидно быстрее.
Если речь про "есть проблема, но нет плана" как будто бы стоит сразу идти в /plan с набросками своей реализации, чтобы агент учел это.
А какие модельки используете? По своему опыту скажу, что план лучше строить с "умной" условной GPT5.4-medium (лучше reasoning high), а реализацию уже можно модели "потупее" отдать.
Это кстати довольно хорошо решается спецификациями и пометками AGENTS.md, чтобы в будущем исключать заведомо ненужные куски кода. ;)
Ну и зря, там дальше полезно было)
На мой взгляд условный "крутой программист" этот тот кто решает задачи бизнеса в кратчайшие сроки и с оптимальным качеством. Странно кичится своим стеком и тем что кто-то может или НЕ может, например запрограммировать микропроцессор (открою небольшую тайну, с АИ-шкой на перевес можно решать много задач и программирование микроконтроллеров, уверен, не исключение).
По себе могу сказать, что производительность решения задач выросла в разы. Объемные рефакторинги, межмодульные зависимости и целый ряд других задач решаются сильно проще и быстрее. И я до сих пор в любой момент времени могу сказать что делает МОЙ код, который написал агент, под моим присмотром, а не я ;-)
На это есть комментарии, в которых коллеги смогут меня дополнить. Спасибо вам за это ;-)
Но тут вставлю свои пять копеек: дописывать нейронка скиллы может и вполне успешно это делает, но вот писать с нуля ей адекватно почему-то не удаётся, уж слишком многословно она излагается, что не всегда хорошо влияет на эффективность (в основном работаю с GPT5.4-high на таких задачках). Поэтому я стартую со стандартного скилла "create-skill" внутри курсор, затем выкидываю половину (немного утрирую) того что нагенерилось и далее по ходу работы пополняю и корректирую скилл.
Эээ я вообще вас цитировал: "А потому что грамотная и осознанная политика одного человека привела к тому, что теперь вся Россия отдыхает здесь"
Ааа понятно, ВВП и тут виноват, дело конечно же не в сливах, хакерских атаках и самой компании Сбер :D
Какой-то туповатый ресрерч. Вам кто-то закрыл Турцию, Египет, Китай, Тайланд, прочую Азию и т.д.? Если бы турпоток из России в Турцию закрылся, то там бы страна была на гране экономического краха :D
P.S. цены такие были со времён олимпиады ;-)
На базе ORM все прекрасно работает, в чем именно трудность?
Документация по данному материалу к сожалению не готова, за изменениями в документации можете следить в нашем ТГ канале: https://t.me/bitrixdoc , или периодически заглядывать на сайт доки и гитхаб: https://docs.1c-bitrix.ru/
Конкретно по гриду в данном материале старался описать все достаточно подробно, чтобы было понятно как с ним работать. С чем именно возникают трудности?
Метод “where” определяет правила маршрутизации. При генерации эти правила не учитываются, тк регулярку вы можете любую навертеть.
Касаемо SEO, накиньте пожалуйста контекста где именно требуются слеши, и почему нельзя использовать что-то кроме них.
А как же весёлая ферма в мини-приложнеиях ВК и старые добрые свитки TES ? :)))
Довольно странный пример, потому что очень похоже что вместо отдельных роутов вы хотите сделать какой-то один динамический. Ну и в целом ваша «проблема» решается использованием разделителя между abcd, который поддерживается URL строкой
Отсутствие ссылки на первоисточник (откуда слова депутата были взяты, видимо с потолка) в ведомостях никого конечно же не смущает)))
Ну, а вы не думали посмотреть как он используется? ;)
А чем вас стандартный PublicPageController не устроил? :)
Не обижайте Yii , он тоже хороший доннор для скрещивания :)
Статья про роутинг, а не про "всё на свете". Не переживайте, про работу с контроллерами статья будет.
Нельзя скрывать такое творчество от общественности, с нетерпеньем жду от вас статью с деталями ;)
В данный момент они не используется и вся логика привычных middleware отдана на откуп экшен фильтрам.
В обновлении main 25.900.0 большая пачка исправлений для CLI команд, эти в том числе
В обновлении main 25.900.0 большая пачка исправлений для CLI команд, эти в том числе