В коде, написанном ИИ ничего волшебного нет, более того он как правило заметно хуже кода, написанного сениором. Так же не всегда с первого промпта получается то что нужно. А ещё задачи нужно часто дробить и очень подробно описывать. В итоге это хорошо подходит для "проектов под NDA" так как там очень много типовых рутинных задач вроде crud либо наоборот api клиенты, верстка по фигме, юнит тесты, фичи которые делаются по одному шаблону и так далее. И тут нейронки отлично помогают. При этом сложные вещи вроде архитектуры или схемы бд для важных частей системы всё равно надо делать руками или хотя бы очень подробно описать ИИ в мелочах. А вот баги опен сорс проектов - сложные непонятные задачи, какой-то обучающей выборки у нейронки на проблемы такого рода почти нет, зато примеров crud api или стилей разных кнопочек - напротив много.
Вы пишете что ИИ пока в 2025 году не умеет делать некоторые действия (запускать код, отладка, дебаг, проверка напрямую в браузере). Но фактически нормальные ИИ агенты (не копилот) умеют это делать уже года 2. Так же они существенно улучшают промпты, добавляя туда автоматически как банальные вещи (пиши как эксперт), так и расширенный контекст, используя RAG с индексированным в векторной базе кодом. MCP тоже можно использовать, например чтобы брать дизайн напрямую из фигмы, но для отладки в браузере используются другое инструменты. Минус более продвинутых агентов - достаточно высокая цена за api доступ к LLM, так как очень высокий расход токенов (если большой проект, то за один промпт контекстное окно в 200к токенов может быть сброшено несколько раз). Так же для приемлемой генерации нужно четко прописывать правила. Плюс агентов - возможности существенно выше чем то что описано в статье. Примеры таких агентов: cline, cursor, kilo code.
Я слышал, что существует возможность не использовать gradle, но на самом деле это мощный инструмент, позволяющий во многом автоматизировать процесс сборки. Кроме того, люди на него особо не жалуются. Да и я проблем с ним пока не встречал. Потому особых резонов отказываться от gradle я не вижу.
Несмотря на то, что Android Studio основана на IntelliJ IDEA, это разные продукты. Фактически, они являются конкурентами. Android Studio — это интегрированное решение, рассчитанное исключительно на разработку под Android OS, поэтому накладывает на пользователя некоторые ограничения. IntelliJ IDEA — более независимая среда, потому с дополнительными плагинами её возможности нативной разработки под Android фактически становятся равными возможностям Eclipse.
Поддерживаю akira (проголосовать правда не могу, кармы маловато), разработчики официально не включили поддержку NDK в Android Studio. Но разве это повод отказываться от работы в ней? Тем более, сложностей как таковых нет, добавить 11 строк (включая фигурные скобки) в buld.gradle достаточно легко. Но догадаться о таком решении проблемы было сложнее. А статья такая развернутая для того, чтобы её могли понять и те люди, которые только начали работать в Android Studio и не имеют опыта взаимодействия с gradle. Ведь всегда лучше не только знать решение, но и понимать, как оно работает, что именно делает, способ реализации, а также иметь возможность сознательно что-то изменить для лучшего удовлетворения своих потребностей. А для более опытных разработчиков в конце статьи есть небольшой раздел, где написан только алгоритм действий, если интересует только это, то не обязательно читать весь материал.
В коде, написанном ИИ ничего волшебного нет, более того он как правило заметно хуже кода, написанного сениором. Так же не всегда с первого промпта получается то что нужно. А ещё задачи нужно часто дробить и очень подробно описывать. В итоге это хорошо подходит для "проектов под NDA" так как там очень много типовых рутинных задач вроде crud либо наоборот api клиенты, верстка по фигме, юнит тесты, фичи которые делаются по одному шаблону и так далее. И тут нейронки отлично помогают. При этом сложные вещи вроде архитектуры или схемы бд для важных частей системы всё равно надо делать руками или хотя бы очень подробно описать ИИ в мелочах. А вот баги опен сорс проектов - сложные непонятные задачи, какой-то обучающей выборки у нейронки на проблемы такого рода почти нет, зато примеров crud api или стилей разных кнопочек - напротив много.
Вы пишете что ИИ пока в 2025 году не умеет делать некоторые действия (запускать код, отладка, дебаг, проверка напрямую в браузере). Но фактически нормальные ИИ агенты (не копилот) умеют это делать уже года 2. Так же они существенно улучшают промпты, добавляя туда автоматически как банальные вещи (пиши как эксперт), так и расширенный контекст, используя RAG с индексированным в векторной базе кодом. MCP тоже можно использовать, например чтобы брать дизайн напрямую из фигмы, но для отладки в браузере используются другое инструменты. Минус более продвинутых агентов - достаточно высокая цена за api доступ к LLM, так как очень высокий расход токенов (если большой проект, то за один промпт контекстное окно в 200к токенов может быть сброшено несколько раз). Так же для приемлемой генерации нужно четко прописывать правила. Плюс агентов - возможности существенно выше чем то что описано в статье. Примеры таких агентов: cline, cursor, kilo code.
Поддерживаю akira (проголосовать правда не могу, кармы маловато), разработчики официально не включили поддержку NDK в Android Studio. Но разве это повод отказываться от работы в ней? Тем более, сложностей как таковых нет, добавить 11 строк (включая фигурные скобки) в buld.gradle достаточно легко. Но догадаться о таком решении проблемы было сложнее. А статья такая развернутая для того, чтобы её могли понять и те люди, которые только начали работать в Android Studio и не имеют опыта взаимодействия с gradle. Ведь всегда лучше не только знать решение, но и понимать, как оно работает, что именно делает, способ реализации, а также иметь возможность сознательно что-то изменить для лучшего удовлетворения своих потребностей. А для более опытных разработчиков в конце статьи есть небольшой раздел, где написан только алгоритм действий, если интересует только это, то не обязательно читать весь материал.