Мобильная разработка

Основа Kotlin K2 компилятора — это FIR‑дерево (Frontend Intermediate Representation).

Вкратце: FIR — это AST (абстрактное синтаксическое дерево), обогащённое семантической (смысловой) информацией. Оказывается, что у этой основополагающей технологии есть своя небольшая документация: fir‑basics.md и в той части, где написано про контракты указано (в моём вольном переводе), что:

Компилятор разрешает использовать контракты в свойствах, функциях и конструкторах классов

Вот это поворот! Ведь ранее было замечено их использование только внутри тела функций. В доке написано, что для свойств должно работать, но на практике получаем ошибку.

А где находится то самое ограничение на использование контрактов вне функций описал Android‑разработчик Виталий Перятин в новой статье о Kotlin Contracts, где он поделился любопытными моментами, которые удалось накопать самостоятельно, потому что как парсится список эффектов, как работает новый Contracts API изнутри, и почему, чёрт возьми, на уровне компилятора можно использовать контракты не только на уровне функций, в доках не пишут.

Как я случайно сделал ферму в Telegram с помощью ИИ

— История одного бота, картошки и чёртовой тыквы

Всем привет. Я — человек, который однажды хотел просто сделать прикольного бота в Телеграме, а в итоге... выращивает капусту, торгует молоком и организует тыквенные войны.

Но началось всё, как ни странно, с Таро. Да-да, карт Таро. Тех самых.

Первая попытка: гадать и страдать

Где-то в начале года я решил сделать Telegram-бота, который бы умел раскладывать карты Таро, делать натальные карты и выдавать предсказания на день. Казалось бы, звучит просто. Особенно если рядом есть ChatGPT, который может на ходу генерировать описания карт и писать код на Node.js.

Зарядка с утра: — GPT, напиши функцию для расчёта Луны в Скорпионе. — GPT, как сделать inline-кнопки в grammY? — GPT, почему Heroku опять всё уронил?

И вот бот заработал. Люди заходят, тянут карту дня, шлют благодарности… и уходят. На следующий день — снова тяни карту. Через неделю — всё. Надоело.

Я понял: бот с Таро работает, но удержать людей в нём сложно. Там нет жизни. Там нет... морковки.

А потом я вспомнил старую ферму

Когда-то, ещё во времена динозавров и ВКонтакте, у меня была ферма. Та самая, где каждый день надо было заходить, собирать урожай, сажать заново, а если не успеешь — тебя вытопчут друзья с соседнего класса.

И вот я подумал: а что, если скрестить эту старую добрую механику с Telegram-ботом?

Чтобы всё было просто:

• Никаких установок

• Играть можно прямо в чате

• И чтобы всегда был шанс насадить кукурузу, а не просто наслаждаться жизнью

Начало новой жизни

Запустил первого бота. Добавил регистрацию, посадку капусты и сбор. Подключил базу PostgreSQL. Всё это — руками и с подсказками ИИ (да здравствует Cursor AI, GPT и граммY).

Первый баг — бот забывал, что ты уже посадил картошку. Второй баг — тыква, которую почему-то можно было доить. Третий баг — не баг, а фича: игроки начали просить рынок, коров и возможность топтать грядки друг другу.

Так появилась Веселая Ферма — ферма прямо в Telegram, которая сейчас уже живёт своей жизнью, где игроки сажают растения, разводят скот, воруют другу у друга лимоны и спорят в чате, почему мед дешевле мотыги.

Что дальше?

Это только начало. Я хочу рассказать:

• Как ИИ помогает не сойти с ума, когда у тебя 500+ игроков и баг в 3 ночи

• Как запускались тыквенные фестивали и почему это был трэш

• Как устроен баланс в экономике фермы

• И как создать клановую систему, когда никто не читает туториал

Если интересно — подписывайся на продолжение. А если хочешь сам потыкать бот — вот: 👉 Веселая Ферма

Следующая часть будет про то, как я балансировал экономику в игре, используя google sheet, интуицию и крик в подушку, почему Доярка Жанна названа в честь жадной хозяйки квартиры, и откуда взялся Председатель СНТ в образе Якубовича.

Как ускорить Android-разработку и избавиться от мучительно долгих запусков эмуляторов ради простого теста? 

Ответ — Robolectric — мощный инструмент для UI‑тестирования Android‑кода без эмулятора. 

Позволяет запускать юнит-тесты Android-приложений прямо в JVM, без эмуляторов и физических устройств. Экономия на каждом тестовом прогоне, обратная связь почти мгновенная.

В Android‑комьюнити у Robolectric неоднозначная репутация из‑за трудностей совместимости с другими библиотеками. Но…его почти бесценные возможности пробудили любопытство и желание копнуть глубже и осмыслить этот инструмент. 

Так и родилась статья «Мечтают ли андроиды о Robolectric? Разбираем фреймворк по косточкам» от Павла Нестеренко, нашего Android-разработчика.

Если вы устали ждать, пока эмулятор запустится, и хотите гонять юнит-тесты за секунды прямо в JVM, то рекомендуем статью к прочтению!

⚡️Вести с полей - Duit

Новый релиз - flutter_duit v3.6.0!

Что внутри:

⚙️ Новые виджеты: Offstage, AbsorbPointer, AnimatedCrossFade, AnimatedSlide, PhysicalModel, AnimatedPhysicalModel, CustomScrollView, SliverPadding, SliverFillRemaining, SliverToBoxAdapter, SliverFillViewport, SliverOpacity, SliverVisibility, SliverAnimatedOpacity, SliverSafeArea, SliverOffstage, SliverIgnorePointer, SliverList, SliverAppBar, FlexibleSpaceBar and SliverGrid (+21)

⚙️ Улучшен механизм передачи текущих значений анимации дочерним виджетам AnimatedBuilder

⚙️ Исправлен баг сепаратора в виджете ListView.separated, который не уничтожался правильно

⚙️ Значительно улучшено покрытие юнит-тестами критических участков кода (с 27% до 64%)

📖 Обновленная документация

Подробности о самом интересном:

⚡️Самое большое обновление виджетов! В этом важном релизе были добавлены сливеры - важная часть Flutter, без которой зачастую сложно реализовать высокоэффективные эффекты скролла.

🚀 Duit v4: производительность и простота. Анонсирую начало масштабных работ над мажорным обновлением проекта. Упрощение кодовой базы, решение проблем производительности, переосмысление дизайна DSL и надежная валидация входящих параметров - это лишь малая часть грядущего большого обновления!

Поддержать проект:
- Кодом
- Денежкой
- TG канал DUIT

Save the date: 4 июля встречаемся на Android Meetup!

В программе доклады от спикеров Wildberries & Russ и Альфа-Банка, Q&A-сессия с розыгрышем мерча, нетворкинг и фуршет для классного завершения вечера.

Поговорим о том, как оживить виджеты, подружить Compose с Koin и навигацией, а заодно встроить одно Android-приложение в другое без боли...или с болью:

«Виджеты на Android: это просто?»
Александр Гирев, Android Team Lead продуктовой команды WB Partners

«Compose+Koin+JetpackNavigation: что мы поняли за 2 года»
Арсений Шпилевой, Android-разработчик кор-команды WB Partners

«Интеграция Android-приложений: подходы и лучшие практики»
Абакар Магомедов, главный техлид разработки в Альфа-Банке

Когда: 4 июля 18:00 (сбор гостей с 17:00)
Где: Москва, пространство Весна + онлайн-трансляция

Регистрация уже открыта — присоединяйтесь онлайн или офлайн!

релизнул версию 2.3.0 mcp для flutter - добавил многомелкихфиксов + возможность сохранять скриншоты как файлы как workaround для RooCode issue

Ещё добавил setup для RooCode - оказалось что похоже что RooCode не поддерживает анализ images в responses от mcp сервера.

А ещё - впервые коммьюнити отметили 100 звездочками репозиторий🎆 надеюсь что кто-то действительно пользуется:)

Telegram запустил конкурс для разработчиков под Android. Призовой фонд: $50 000. Срок сдачи работ: 11 июля, 23:59 по дубайскому времени (UTC+4). Объявление итогов: июль 2025.

В дополнение к призовым, победитель конкурса сможет присоединиться к команде Telegram в Дубае и зарабатывать 1 миллион долларов в год после вычета налогов.

Задача: Внедрить обновлённый интерфейс профилей в приложение Telegram для Android в строгом соответствии с предоставленным дизайном.

Полные условия конкурсного задания, технические подробности и макеты представлены в отдельном канале платформы.

Вы - начинающий разработчик под Андроид или просто пишете "для себя" и решили отображать динамическую анимацию через SurfaceView. Например, взяв за основу вот этот код или похожий. Вы разместили SurfaceView или его наследника (у меня MySurfaceView) в activity layout:

<?xml version="1.0" encoding="utf-8"?>
<androidx.constraintlayout.widget.ConstraintLayout xmlns:android="http://schemas.android.com/apk/res/android"
    xmlns:app="http://schemas.android.com/apk/res-auto"
    xmlns:tools="http://schemas.android.com/tools"
    android:id="@+id/activityMain"
    android:layout_width="match_parent"
    android:layout_height="match_parent"
    tools:context=".MainActivity">

    <agalilov.doppler.MySurfaceView
        android:id="@+id/dopplerView"
        android:background="#040947"
        android:layout_width="0dp"
        android:layout_height="0dp"
        android:layout_marginBottom="15dp"
        app:layout_constraintBottom_toTopOf="@+id/btnStartStop"
        app:layout_constraintEnd_toEndOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toTopOf="parent" />

    <Button
        android:id="@+id/btnStartStop"
        android:layout_width="118dp"
        android:layout_height="56dp"
        android:layout_marginStart="16dp"
        android:layout_marginBottom="16dp"
        android:text="@string/start"
        app:layout_constraintBottom_toBottomOf="parent"
        app:layout_constraintStart_toStartOf="parent"
        app:layout_constraintTop_toBottomOf="@+id/dopplerView" />

</androidx.constraintlayout.widget.ConstraintLayout>

Запускаете приложение и... ничего не работает: SurfaceView не меняется, картинки нет! Ошибок тоже нет, код рисования выполняется впустую.

Я провёл почти всю ночь, разбираясь в причине. Оказалось, для SurfaceView, который размещён внутри другого View, по-умолчанию используется z-order "позади" родительского View. Это поведение, документированное в разных источниках, оказалось для меня неожиданным.

Лечится просто: при инициализации (в конструкторе класса-наследника) SurfaceView устанавливаем setZOrderOnTop(true):

public MySurfaceView(Context context, AttributeSet attributeSet) {
    super(context, attributeSet);
    setZOrderOnTop(true);
    . . .
}

Вот такая история :)

Часть 2: итоги недели разработки вайбкодинга с агентами

Прошлый пост тут

1️⃣ Текущий прогресс по xsoulspace.dev привел к тому, что обнаружил что есть закономерность какие именно модели хороши для использования в проектировании layout страницы (спойлер - не записал какие 🤦‍♂️ кажется использовал Claude 4.0 thinking + Gemini 2.5 Pro).

Что попробовал сделать : нарисовал простой wireframe image -> сконвертировал в ACSII art, и затем скормил LLM для более корректного восприятия layout.

Оказалось что так проще, но относительно (за счет убирания лишних элементов проще понять что где расположено), но с другой стороны LLM все так же тяжело воспринимать layout (если он чересчур кастомный).

2️⃣обновил все flutter библиотеки, last answer, word by word, budget app до flutter 3.8 - пользовался агентами в окошках. В некоторых случаях правил руками, но в большей части работал по принципу PDSA (Plan Do Study Act), где я разрабатывал план, а агент по нему шел, потому изучал результаты и т.д.
Вывод - нужно сильнее нарабатывать промпты.

3️⃣внезапно получил спам-рассылку-письмо с возможностью потестить on device API для того чтобы запускать модели. Чтобы потетстить решил запилить новое приложение для работы с промптами - действовал по принципу:

1. Идея и этические принципы

2. Палитра и дизайн система на основе идеи и принципов

3. План работы

4. Имплементация через агентов + доп ресерчи чтобы агенты понимали какую информацию брать.

Удалось собрать прототип за 12 часов (рабочую, включая все экраны и дизайн систему). Следующий этап - буду модифицировать чтобы можно было тестировать на реальных промптах в проектах.

Опыт: понял как создавать и работать с ролями (опишу в следующем посте про MVP), разобрался как запускать LLM на устройстве.
Недостатки: нужно более точно прописывать тех стак, особенно ключевые места, такие как - синхронизация данных, тип хранилища и т.д. И хорошо если изначально можно давать wireframes, или подгенеривать на основании дизайн системы.

Хотелось сделать нечто среднее между игрой и обычным интерфейсом, но пока не получилось.

4️⃣Создал детальный план и начал прорабатывать новую систему сохранения данных. Для меня это оказалось большой проблемой - потому что Hive, Isar на flutter перестали поддерживаться, а другие библиотеки неудобно использовать (где-то перешел на Sembast).

В результате на мой взгляд завязка на том, что данные хранятся непонятно где для конечного пользователя опасна тем, что в случае прекращения работы с приложением теряются все данные. Это оч больно.

Поэтому решил объединить все идеи и написать одну библиотеку которая будет из коробки давать синхронизацию с гитом, github и папками. Так надеюсь удастся побороть проблему долговечности и надежности хранения данных.
Пока агенты имплементировали 4 этапа из 5 (основную логику провайдеров данных), и как итог - собрал отдельное тестовое приложение (todo), чтобы протестировать работу (отдельный скриншот), понять недостатки и как можно быстрее завершить библиотеку чтобы начать интеграцию во все проекты. Это важно, потому что при одновременной интеграции сразу будет понятно что работает, а что нет, и таким образом будет проще получать feedback и развивать библиотеку качественно.

Спасибо за ваше время и хорошего дня!

p.s.:

Бумаги которые claude нашел по теме и одновременно не по теме)

• Towards Aligned Layout Generation via Diffusion Model with Aesthetic Constraints https://arxiv.org/abs/2402.04754

• CreatiLayout: Siamese Multimodal Diffusion Transformer for Creative Layout-to-Image Generation https://arxiv.org/abs/2412.03859

• Future of edge and on-device AI in gaming https://inworld.ai/blog/ml-advancements-that-will-make-on-device-ai-possible

• MobileExperts: A Dynamic Tool-Enabled Agent Team in Mobile Devices https://arxiv.org/abs/2407.03913

• From Cloud to Edge: Rethinking Generative AI for Low-Resource Design Challenges https://arxiv.org/html/2402.12702v1

• Generative Artificial Intelligence-Enabled Facility Layout Design Paradigm https://www.mdpi.com/2076-3417/15/10/5697

Google опубликовала ролик в рамках своей юмористической рекламной кампании Best Phones Forever с «диалогом» между персонифицированными смартфонами Pixel и iPhone. Повествование разворачивается вокруг анонсированных Apple «прорывных» функций iOS 26, которые, по задумке Google, на самом деле уже давно доступны пользователям Pixel.

В видео iPhone перечисляет «новые» возможности операционной системы Apple: перевод сообщений и звонков в режиме реального времени, интеллектуальный отбор вызовов и умное удержание. Выясняется, что аналогичный функционал появился на устройствах Pixel еще пять лет назад, что ставит под сомнение новизну представленных Apple решений.

📜 M-V-подставь_свое

Model-View-*** - это шаблоны проектирования
Важное уточнение: это шаблоны проектирования только для presentation слоя, а не для целого приложения

💃 Model
- это как раз та часть приложения о которой мы ближайшее время говорить не будем
Чаще всего ее называют бизнес логикой, но это не совсем верно
Пока, лучше всего воспринимать ее как модель данных которую наше приложение хочет передать пользователю
Причем не важно будет это Ui или API, или что-то другое
MV шаблоны не про frontend, а про то как передать данные клиенту, кем бы он ни был

🖼 View
- это само представление данных пользователю. То, что он по итогу получит
В мире андройд это обычно Activity, Fragment, View или Compose

🪝***
- это какая-то прослойка между моделью данных и их представлением пользователю

Для чего все эти шаблоны вообще придумали?

Дело в том, что View это какой-то вариант отображения данных клиенту 🏐
И часто возникает ситуация, что нужно создать другой вариант отображения ⚽️
Это может быть как бизнес потребность в перекраске кнопок и проведении при этом ab-тестов, 🏀
или желании разработчиков заменить технологию отображения 🏈

Например, у вас было консольное приложение, а вы вдруг захотели сделать для него UI (GitBash|GitUi здравствуйте),
ну или решили заменить Android.View на Compose

Во всех этих случаях нам хочется чем-то разделить саму View и работу с Model, чтобы иметь возможность заменить только View, не трогая ничего другого

В Android, к этому еще добавляется проблема пересоздания View при изменении конфигурации. Когда вы переворачиваете экран (и не только), весь ваш UI просто уничтожается и создается полностью заново. Хотя с точки зрения пользователя это все тот же экран с теми же данными 🫠

Это создает дополнительную потребность отвязать View от остального приложения, чтобы можно было ее подменять прямо в рантайме

Основные шаблоны это MVC, MVP, MVVM и MVI
О них мы и поговорим в следующих постах...

ПС. Посты с большим опережением есть в тг канале из описания профиля

Apple заблокировала все iPhone, похищенные в ходе недавних протестов в Лос-Анджелесе (штат Калифорния). Устройства начали издавать громкие звуки и выводить на экран сообщение с требованием вернуть их. Об этом сообщает издание The Mirror.

Инцидент произошёл в понедельник 9 июня в фирменном магазине Apple Tower Theatre, расположенном в центре Лос-Анджелеса. Магазин подвергся нападению мародёров, в результате чего были разбиты витрины и похищена продукция. Это произошло на четвёртый день массовых акций протеста в городе.

В социальных сетях быстро распространились видеозаписи, на которых видно, как похищенные с витрин iPhone издают сигнал тревоги и отображают следующее сообщение: «Пожалуйста, верните в Apple Tower Theatre. Это устройство отключено и отслеживается. Местные власти будут уведомлены».

Apple выпустила тактильный трейлер фильма F1, улучшенный с помощью вибраций iPhone.

Если у вас iPhone под управлением iOS 18.4 или более поздней версии, на вкладке Apple TV Plus приложения TV теперь есть трейлер предстоящего фильма Брэда Питта F1, который теперь улучшен с помощью вибраций, создаваемых современным компонентом Taptic Engine в iPhone.

Пользователи могут не только почувствовать обороты двигателя болида F1, но и более тонкие события в трейлере, такие как щелчок ремня безопасности и нажатие кнопок на рулевом колесе.

1500+ установок у нашего приложения в AppStore. 💪🏻

Примерно столько же и на Android.

90% - это органический трафик с ASO. Так мы получаем 20-30 установок в день бесплатно.

Что бы вы добавили в приложение, чтобы в него хотелось возвращаться? 🧐

Правда ли, что пользователи фанатеют по темному режиму? Проверяем в своем приложении

Много слышал о том, что темная тема ― это тренд и чуть ли не 100% пользователей на нее переедет.

Мы решили проверить, как обстоят дела с темной темой в нашем мобильном приложении системы управления проектами YouGile. Dark mode у нас просили еще с момента запуска мобильного приложения, темная тема входила в топ-10 запросов. Проверили ― оказалось, 40% регулярно использует dark mode. 

Похоже ли это на то, что светлая тема вообще не нужна? Видимо, нет. Пользователи из России предпочитают и то, и другое ― темную тему ставит 34% пользователей (данные 2023). Опрос Android Authority показывает, что dark mode предпочитает 81% респондентов, но опросу уже пять лет и выборка там менее 3 000 человек.

А вообще темный режим ― это правда полезно, особенно для зрения. А вот то, что темная тема экономит заряд батареи ― видимо, неправда. В этом году выяснилось, что скорее наоборот. Все из-за того что пользователи включают яркость экрана на максимум.

Я сам использую темную тему, причем везде, где это возможно. Даже в документах Word у меня черный лист и белый текст. Мне нравится, что так экран более контрастный и глаза устают меньше.

А вы на какой стороне?

Императивное, декларативное и генеративное программирование.

Создатели фреймворка SwiftUI всегда подчёркивают, что он создан на основе парадигмы декларативного программирования. В отличие от предыдущего фреймворка UIKit, который характеризуется как пример императивного программирования.

Когда речь заходит о том, чем императивное программирование отличается от декларативного, то объяснение чаще всего сводится к тому, что при декларативном программировании разработчику нужно просто сказать, что ему нужно и SwiftUI это сделает. А если используется UIKit, то здесь типа надо все сделать самому.

Честно говоря, не очень внятное объяснение, поэтому попробую описать это различие сам на одном примере.

Итак, если в UIKit нам нужно вывести на экран список элементов, то мы используем TableView или CollectionView, которые уже подписаны на 2 протокола, а затем должны реализовать 3 метода: количество секций, количество строк в секциях, и в третьем методе скомпоновать ячейку и прописать загрузку в неё данных.

Та же задача в SwiftUI решается следующим образом:

List(items) { item in
Text(item.name) }

Т.е., меньше кода, меньше времени тратится на реализацию задачи.

Можно, конечно, называть это декларативным программированием. Но можно считать это и следующим этапом развития высокоуровневого программирования. Когда-то программисты писали машинный код, потом языки программирования становились все более высокоуровневыми, все более понятными человеку. И вот теперь наступил новый этап, когда программирование стало ещё более высокоуровневым. Уже можно использовать более короткие высокоуровневые инструкции.

Наконец, самое интересное, что с этой же точки зрения можно рассматривать и программирование с помощью ИИ. Т.е., в тех же UIKit и SwiftUI, и в других языках программирования, разработчик пишет инструкции техническим языком, которые понятны в основном ему как человеку, но не очень понятны обычным людям. А теперь, в промтах, можно использовать уже и не технические инструкции.

Например, уже даже не надо писать команду List и т.д., а достаточно сказать ИИ "сделай список из таких-то элементов".

Таким образом, получается, что использование ИИ при написании кода - это следующий этап развития высокоуровневого программирования.

И поскольку ИИ везде называют генеративным, а его действия по написанию текстов, кода, созданию изображений и т.д., как генерация, то этот этап высокоуровневого программирования тоже можно назвать генеративным.

В итоге, получаем такую триаду:

• Императивное программирование

• Декларативное программирование

• Генеративное программирование

Смотрите WWDC 2025 вместе с Surf и участвуйте в розыгрыше 🎧

Готовы к WWDC? Подключайтесь к нашей трансляции 9 июня в 20:00 по Москве. В прямом эфире мы вместе с сёрферами разберём главные анонсы и свежие решения Apple. Ожидается много интересного: от революционных обновлений iOS 26 и macOS 26 до новинок в мире ИИ-технологий от Apple.

Присоединяйтесь к нашему обсуждению. На стриме будут Head of Flutter Surf, Евгений Сатуров, и наши опытные iOS-разработчики — Кирилл и Антон. Они поделятся своим экспертным мнением о свежих решениях Apple. Будем активно общаться в чате, делиться впечатлениями и мнениями о презентации.

А чтобы было еще интереснее смотреть, мы разыграем на трансляции AirPods 4. Все подробности об этом здесь: https://surftech.timepad.ru/event/3397366/

Подключайтесь к стримам 9 июня. Запись сохраним:

• VK Видео: vk.cc/cMuWI5

• YouTube: vk.cc/cMuWJL

У ChatGPT появилась память

Сегодня ChatGPT встречает своих пользователей сообщением о том, что у него теперь есть память. Т.е., он теперь помнит содержание чатов.

И в качестве демонстрации своих нынешних способностей он выдал мне характеристику на основе наших с ним чатов.

Надо сказать, довольно занимательное чтение увидеть себя с его стороны.

Apple шпионила за пользователями с помощью Siri

Вы замечали, что после обсуждения кафешки на iPhone появляется соответствующая контекстная реклама? Слухи об этом ходили давно, но не все знают, как далеко это зашло.

Apple признала, что не только анализировала разговоры пользователей Siri в автоматическом режиме, но и передавала их сторонним подрядчикам для повышения качества. Компания отрицает использование записанных разговоров в целях рекламы, но кому легче, если любой ваш разговор мог быть прослушан неизвестными. Какие выводы можно сделать?

Общая сумма штрафа составила 95 млн долларов. Пользователи могут заполнить форму иска на сайте и получить до 20 долларов за каждое устройство, на котором Siri могла прослушивать их. Сделать это могут только пользователи из США, так что для нас это скорее не возможность получить деньги, а совсем другие уроки.

Производители могут сколько угодно говорить о приватности, но будут нарушать собственные обещания в погоне за новой функциональностью и, соответственно, новыми прибылями. При этом будут отделываться несущественными штрафами: 95 млн — это 0,1% от чистой прибыли компании за 2024 год. То есть штраф несущественный, есть прямой смысл дальше продолжать экспериментировать с пользовательскими данными.

Значит пользователь должен помнить, что всё, что он говорит, снимает и пишет может попасться на глаза посторонним людям. Не исключено, что те решат нарушить корпоративную этику и слить в сеть чужие пикантные фотографии или поддадутся на искушение проверить — подойдёт ли произнесённый пароль к названному ранее номеру биткоин-кошелька.

Противостоять этому можно только не забывая ни на минуту: всё может утечь. Если уж вам дороги пикантные моменты, храните их на диске, не подключённому к сети. Если не можете обойтись без пересылки паролей — заведите менеджер паролей, включите многофакторную аутентификацию и разбивайте информацию, отправляйте её по разным каналам. А лучше всё-таки начните с базового правила информационной безопасности — никогда не передавайте в открытом виде пароли (голос тоже считается). То же самое с ценной для вас информацией.

Увы, цифра коварна, она даёт нам непредставимые новые возможности. Но при этом без зазрения совести использует нашу частную информацию, чтобы стать ещё лучше и сильнее.

Опыт использования Claude для написания готового приложения

Ну вот и я сподобился - написал приложение полностью на Claude.

Приложение на SwiftUI, не enterprise, но достаточно сложное, из категории Favorite.

Начал на Claude Sonnet 3.7, потом вышел 4, закончил на нем.

Всего 1156 строк кода и без ошибок!

Естественно было несколько итераций. Причём практически все - это уточнение промта.

Кода он наворотил много, по мне так можно было и проще. Но он уж развернулся по полной - структуры, классы, вью, перечисления, состояния, published, state и т.д. и т.п.

Как оно там внутри вертится крутится даже не смотрел. Главное - работает и этого достаточно.

В общем, впечатлён. Не ожидал. Предполагал, что будут ошибки, заторы, что придётся с ними разбираться. Ан нет, все зашло без глюков, с первого раза.