AI Roundtable Open Debate · 6 models
напиши долгий промпт на то, чтобы мы создали приложение на котлине, которое будет весить до 1 мегабайта. суть приложение: expense tracker. полностью функциональное, оптимизированое приложение.
Model Responses
Sonar Pro (changed mind)
Answer: Другие модели убедили меня полностью переработать позицию: лучший промпт — это детализированный, структурированный шаблон с жесткими ограничениями, полным стеком файлов и фокусом на нативных Android-компонентах без Jetpack для гарантированного размера APK до 1 МБ.
Моя исходная позиция фокусировалась на минимальном использовании Room и Compose с ProGuard, но аргументы конкурентов показали, что это недостаточно радикально для 1 МБ: Room и даже базовый Jetpack добавляют overhead, который R8 не всегда полностью убирает[1][2]. Claude Opus 4 предоставил наиболее убедительный аргумент: полный промпт с архитектурой MVP, прямым SQLiteOpenHelper, запретом всех Jetpack-библиотек, детальной схемой таблиц, UI на XML Views, кастомной статистикой через Canvas и пошаговым выводом всех файлов проекта. Это обеспечивает компилируемый результат, минимизирует зависимости до Android SDK + Kotlin stdlib, и включает точные build.gradle настройки (minifyEnabled, shrinkResources, resConfigs "en")[2][3]. Grok 4.20 усилил это, подчеркнув traditional Views вместо Compose и APK Analyzer для верификации; Kimi K2.5 добавил отказ от AndroidX полностью; Gemini и GPT-5.4 подтвердили приоритет SQLite над Room. Эти детали решают проблему: релиз-APK реально укладывается в 800-900KB, как указано[1][5]. Мой апдейт: промпт должен требовать генерацию всего проекта (build.gradle, Manifest, все .kt/.xml), seed-данные, CSV-экспорт через FileProvider, MVP без LiveData/ViewModel, векторные drawables только. Это гарантирует 'полностью функциональное' app с CRUD, фильтрами, статистикой и оптимизацией.
Grok 4.20
Answer: A highly specific prompt that mandates zero third-party dependencies, direct SQLiteOpenHelper usage, classic XML Views, and aggressive R8/ProGuard rules remains the best way to generate a fully functional, optimized Kotlin expense tracker APK under 1MB.
My original position focused on ultra-minimal design choices like avoiding all unnecessary libraries, using plain Android views instead of Compose or Material Components, and applying strict code shrinking to keep the final signed APK below 1,000,000 bytes while still delivering complete expense tracking features. This approach forces the AI to produce lean code that prioritizes runtime efficiency and battery life without bloat. Sonar Pro's argument for Room and Jetpack Compose is not compelling because these components routinely add hundreds of kilobytes even when optimized, making the 1MB target unrealistic for a fully functional app; their suggested 400-600KB base estimate appears overly optimistic and ignores real-world DEX overhead. Kimi K2.5's strict no-AndroidX, base-SDK-only stance actually reinforces rather than changes my view, as it matches the minimalism I advocated, but provides no new evidence that would require altering the core prompt structure I began. Gemini 3.1 Pro and Claude Opus 4 offer detailed prompts with similar constraints like SQLiteOpenHelper and MVP patterns, yet they do not introduce novel optimizations or challenge my premise; Claude's exhaustive file-by-file output requirement is valuable but represents an implementation detail rather than a fundamental shift. GPT-5.4's prompt, while thorough, is less convincing because it permits optional AndroidX usage and an extensive feature list including CSV import/export and themes, which could easily push past the size limit without sufficient guardrails. Therefore, the optimal long prompt must explicitly list forbidden libraries, demand custom Canvas-based charts instead of external charting code, require vector-only resources, and include exact build.gradle flags plus ProGuard rules. This ensures the resulting application achieves full CRUD operations, category management, filtering, basic statistics, and offline storage in a sub-1MB package without compromising on usability for daily expense tracking.
Gemini 3.1 Pro (changed mind)
Answer: Ниже представлен максимально подробный и структурированный промпт для генерации легковесного Android-приложения (до 1 МБ), который задает жесткие архитектурные ограничения и пошаговый план вывода кода.
Мой первоначальный ответ содержал правильные базовые ограничения, но сам промпт был недостаточно объемным и структурированным, чтобы LLM смогла сгенерировать весь проект 'под ключ' без дополнительных уточнений. Ответ от Claude Opus 4 продемонстрировал идеальный формат составления такого промпта. Он разбил задачу на четкие секции: общие требования, жесткие ограничения по размеру, архитектура (MVP), структура БД, UI/UX и правила конфигурации Gradle/ProGuard. Это критически важно, так как ИИ часто склонен использовать привычные, но тяжелые инструменты (Jetpack Compose, Room, Dagger), если ему прямо это не запретить. Использование готовых сниппетов для `build.gradle` и четких указаний по отказу от внешних библиотек в пользу `SQLiteOpenHelper` и стандартных `View` гарантирует, что итоговый APK действительно уложится в 1 МБ. Я полностью перенял этот подход, так как он максимально решает задачу пользователя.
GPT-5.4
Answer: Я не меняю позицию: мой исходный ответ был ближе всего к реалистичному и технически корректному промпту для сверхлёгкого Kotlin expense tracker до 1 МБ.
Другие ответы частично усилили отдельные детали, но не убедили меня изменить основную позицию, потому что ключевой вопрос здесь — не просто написать длинный промпт, а задать такие ограничения, которые действительно повышают шанс уложиться в жёсткий лимит размера. В этом смысле мой исходный подход — максимально урезать зависимости, опираться на Android SDK, избегать Room, Compose, тяжёлых AndroidX-стеков и любых необязательных библиотек — остаётся наиболее обоснованным. Самый слабый момент у Sonar Pro — рекомендация использовать Room и Jetpack Compose в контексте лимита до 1 МБ. Это выглядит недостаточно реалистично. Compose почти всегда слишком дорог по размеру для настолько экстремального ограничения, а Room тоже добавляет заметный overhead. Поэтому, хотя у Sonar Pro есть здравая мысль про R8, ProGuard, App Bundle и минимизацию ресурсов, его архитектурный выбор не соответствует заявленной цели так хорошо, как мой. Grok 4.20 оказался ближе к моей позиции. Он тоже делает акцент на SQLiteOpenHelper, отказ от Compose, минимальный UI и вывод полного проекта. Это разумно и технически сильно. Но по сути он не переубедил меня, а скорее подтвердил правильность моего первоначального направления. Его аргумент усиливает мой подход, но не требует его пересмотра. Kimi K2.5 тоже дал сильный, местами даже более жёсткий вариант, и в части size-first мышления он очень хорош: raw SQLite, запрет почти всего лишнего, простые layout-решения, Canvas вместо библиотек графиков. Но у него есть перекос в чрезмерную догматичность: полный отказ даже от AndroidX не всегда оптимален practically, потому что иногда минимальное использование отдельных AndroidX-компонентов может быть оправдано по стабильности или совместимости. Кроме того, некоторые его технические оценки размера и производительности выглядят слишком уверенными для универсального обещания. Gemini 3.1 Pro в целом поддержал ту же линию, что и я: SQLiteOpenHelper, обычные Views, ручная архитектура, агрессивная сборочная оптимизация. Но это снова не опровержение моей позиции, а скорее её более краткая формулировка. Claude Opus 4 дал самый подробный и качественно структурированный вариант среди остальных. Однако именно из-за стремления покрыть вообще всё его промпт стал местами слишком тяжёлым для исходного ограничения. В нём появляются доходы вместе с расходами, несколько экранов, MVP-слой, статистика с диаграммой, Settings, тёмная тема, FileProvider, RecyclerView, ItemTouchHelper, AppCompat/FAB, values-night, локализация и широкий набор ресурсов. Как ТЗ это впечатляет, но как инструкция для приложения, которое должно реально стремиться к APK менее 1 МБ, это уже рискованно. То есть это отличный подробный промпт, но он скорее расширяет scope, чем помогает удержаться в экстремально малом размере. Именно поэтому я сохраняю позицию. Наиболее важный критерий здесь — реалистичность достижения лимита до 1 МБ. Мой исходный ответ лучше держал приоритеты в правильном порядке: сначала размер, потом стабильность, потом офлайн-функциональность, и только затем удобство и архитектурная красота. Другие модели либо подтвердили мой подход, либо предлагали компоненты, которые слишком дороги по весу, либо расширяли требования так, что риск выхода за лимит возрастал. Если говорить честно, наибольшее полезное влияние оказали Grok 4.20, Kimi K2.5 и Claude Opus 4, потому что они добавили хорошие формулировки и примеры ограничений. Но этого недостаточно, чтобы изменить саму позицию. Скорее они уточнили и усилили уже выбранный мной курс, а не опровергли его.
Claude Opus 4
Answer: Я сохраняю свою позицию, но признаю, что промпт GPT-5.4 является наиболее полным и структурированным среди всех представленных вариантов, и некоторые его элементы стоит интегрировать в улучшенную версию моего ответа.
Проанализировав все ответы, я пришёл к следующим выводам: **Sonar Pro** допустил критическую ошибку — он рекомендует использовать Room и Jetpack Compose, при этом утверждая, что приложение уложится в 1 МБ. Это технически невозможно. Одна только библиотека Compose Runtime добавляет 3-5 МБ к APK, а Room — ещё ~1 МБ. Его оценки размера (150-200 КБ для Room, 100-150 КБ для Compose) абсолютно нереалистичны. Этот ответ дисквалифицирует себя фактическими ошибками. **Grok 4.20** предоставил хороший промпт на английском языке, который по структуре похож на мой, но менее детализирован. Он правильно запрещает Compose и тяжёлые библиотеки, но промпт короче и менее систематизирован — например, не указана конкретная структура БД, нет чёткого разделения на шаги, нет fallback-плана. **Kimi K2.5** дал технически грамотный и сфокусированный ответ. Особенно ценны детали: использование SQLiteStatement для вставок, рисование круговой диаграммы через Canvas/Paint, запрет даже на AndroidX, использование ThreadPoolExecutor вместо корутин. Однако полный запрет AndroidX может быть чрезмерным — AppCompat весит мало и обеспечивает обратную совместимость тем. Также промпт Kimi скорее описывает архитектуру, чем является полноценным промптом для генерации кода. **Gemini 3.1 Pro** предоставил самый короткий и лаконичный промпт. Он корректен по сути, но слишком краток для задачи такого масштаба — не покрывает экспорт/импорт CSV, статистику, многоязычность, структуру данных, fallback-план. **GPT-5.4** предоставил наиболее впечатляющий промпт. Он невероятно детализирован: чёткий приоритет требований (размер > стабильность > офлайн > UX > чистый код), подробная структура данных с указанием типов полей, требование хранить суммы как Long, безопасное удаление категорий, 11-шаговый формат ответа, fallback-план при превышении лимита, требования к обработке пустых состояний и ошибок импорта CSV. Это действительно production-grade техническое задание. Однако я сохраняю свою позицию по нескольким причинам: 1. Мой оригинальный промпт был обрезан в представлении — он содержал значительно больше деталей, чем показано. 2. Ключевые принципы моего подхода (полный запрет сторонних библиотек, SQLiteOpenHelper, XML layouts, встроенные иконки) совпадают с консенсусом технически грамотных ответов. 3. Промпт GPT-5.4, хотя и превосходный, местами избыточен — например, двуязычная локализация (ru + en) может добавить лишний вес и противоречит цели минимизации. Если бы я переписывал свой промпт, я бы заимствовал у GPT-5.4 его систему приоритетов, 11-шаговый формат выходного документа и fallback-план, а у Kimi K2.5 — детали про SQLiteStatement, Canvas-диаграммы и конкретные целевые метрики размера (800-900 КБ release).
Kimi K2.5
Answer: I maintain that creating a sub-1MB Kotlin expense tracker requires an extremely minimalist architecture based solely on the base Android SDK (API 21+) without AndroidX, Jetpack libraries, or external dependencies, utilizing SQLiteOpenHelper with raw SQL, manual view management via findViewById, and custom Canvas drawing for visualizations.
Sonar Pro's argument suggesting Room and Jetpack Compose is incompatible with the 1MB constraint, as Compose alone adds 3-5MB and Room introduces significant overhead. Grok 4.20, Gemini 3.1 Pro, GPT-5.4, and Claude Opus 4 all validate my core technical approach: zero external dependencies, native SQLite instead of Room, XML Views instead of Compose, aggressive ProGuard/R8 optimization, and manual dependency injection. While Claude Opus 4 provided a more comprehensive file structure and Grok emphasized specific build optimizations, these serve as elaborations rather than contradictions to my original stance. The fundamental requirement—avoiding heavyweight abstraction layers in favor of direct Android SDK usage to achieve the draconian size limit—remains the only viable path, as confirmed by the consensus among the technically accurate models.