DEV Community: Roronoa

Test Mobile Continuity for Long-Running AI Tasks

Roronoa — Fri, 10 Jul 2026 10:08:42 +0000

A long-running AI task creates a mobile problem that a chat request does not: the work can outlive the screen, the network, the access token, and the app process.

The success condition is not “the spinner kept spinning.” It is “the user can leave, return, and recover the authoritative task state without duplicating work or losing control.”

This article is a test protocol, not a device benchmark. It defines the devices, network transitions, evidence, and invariants a team should record before claiming mobile continuity.

Define the system boundary first

Write down where the task actually runs:

mobile app -> task API -> durable task record -> worker -> artifacts
     ^             |
     +-------------+ status stream or polling

If the task executes in a cloud development environment, suspending the phone should not terminate the task. If execution is on-device, background limits, thermal state, battery, and operating-system scheduling become part of correctness. Do not mix those architectures in one result table.

Record a complete test envelope

Every result needs enough context to reproduce it:

device_model:
os_and_version:
app_build:
execution_location: cloud | edge | device
network_start: wifi | cellular | constrained
account_role:
task_fixture_and_revision:
task_id:
task_start_utc:
transition_start_utc:
recovery_start_utc:
battery_start_percent:
battery_end_percent:
screen_state:
expected_invariant:
observed_result:
evidence_links:

Use at least one current iOS device and one Android device from the team's supported range. Add an older or memory-constrained device when it represents real users. A simulator is useful for deterministic UI flows, but it is not evidence for battery, radio behavior, thermal limits, or real process eviction.

Use one deterministic task fixture

Choose a repository and task that:

takes at least five minutes so lifecycle changes can occur;
produces an inspectable patch and test result;
is safe to repeat;
has no production credentials;
starts from a pinned revision;
has a known success condition.

Example fixture:

Repository: a disposable calculator API
Revision: pinned commit SHA
Task: add input validation for division by zero
Success: one expected source change + one new passing test
Maximum duration: 15 minutes

Do not change the prompt between network scenarios. Otherwise task variance can be mistaken for mobile lifecycle behavior.

Run the continuity matrix

Scenario	Action	Invariant
Background	Send app to background for 30 seconds, then five minutes	One task continues; return shows authoritative state
Screen lock	Lock during execution, then unlock	No duplicate task; sensitive content follows lock policy
Process death	Terminate the app process, then relaunch	Task is recovered by server ID, not recreated from UI memory
Wi-Fi → cellular	Switch networks during a status update	Reconnect resumes from a cursor/version without losing terminal state
Offline	Enable airplane mode for 60 seconds	UI says state is stale and disables unsafe repeated submission
Token expiry	Expire auth while task runs	Reauthentication preserves task identity and intended return path
Duplicate tap	Tap submit repeatedly under latency	One logical task is accepted or duplicates are explicitly linked
Cancel offline	Request cancel while disconnected	UI labels the request as pending, not completed
Cancel during command	Cancel while a build runs	“Requested” and “confirmed” are distinguishable
Notification tap	Open from task-complete notification	Correct account and task open; access is rechecked
Account switch	Switch account before opening a deep link	No cross-account task data appears
Server restart	Restart a non-production worker during the task	Mobile UI reports recovery or failure without inventing success

The offline cancel case is especially revealing. A local button tap is not proof that the server accepted cancellation.

Model freshness in the UI

The mobile client needs more than a task state. It also needs the age and source of that state:

{
  "taskId": "task-123",
  "state": "running",
  "version": 17,
  "updatedAt": "2026-07-10T08:00:00Z",
  "connection": "reconnecting",
  "pendingAction": null
}

Render “Running — last updated 42 seconds ago; reconnecting” rather than a fresh-looking animation. When a cancel action is queued locally, show “Cancel will be sent when connected” and provide an undo path if the product can support it.

On reconnect, compare a monotonic version or event cursor. A response older than the displayed version must not move the UI backward from succeeded to running.

Measure recovery, not animation smoothness

Capture these metrics per scenario:

Metric	Definition
State recovery latency	app foreground or relaunch to authoritative task state
Duplicate task count	extra server tasks created for one intended submission
Stale-state duration	time UI presents a state older than the server record
Ambiguous cancel window	cancel tap to confirmed terminal state or explicit failure
Data transferred	bytes during the scenario, separated from artifact downloads
Battery delta	percentage and duration, reported with device and screen state

Do not publish a cross-device average without the individual samples. A median over three runs per scenario is a reasonable starting summary; keep raw runs for regressions.

A source-based MonkeyCode application

The MonkeyCode README documents an online environment with native mobile support and synchronized PC/mobile data. Its repository includes this mobile screenshot:

Source: MonkeyCode repository at commit 1ac778f, licensed with the project under AGPL-3.0.

That public material makes MonkeyCode a relevant target for this protocol. It does not supply the device, OS, network, battery, or recovery measurements required to fill in the result table. Those claims should wait for a controlled device run.

Disclosure: I contribute to the MonkeyCode project. This is a proposed mobile test protocol based on public documentation, not a hands-on performance review.

Mobile developers can join the MonkeyCode Discord to ask the team about supported workflows and help turn the matrix into version-specific tests. The team can also confirm current eligibility and usage limits for any free model credits.

Mobile continuity is a server-state and recovery problem wearing a small-screen interface. Test process death, stale data, and ambiguous cancellation before celebrating that the task can be opened from a phone.

Should an LLM Run On the Phone, at the Edge, or in the Cloud?

Roronoa — Fri, 10 Jul 2026 07:12:12 +0000

“On-device AI” sounds like a deployment choice. For a mobile team it is a product constraint that affects download size, memory pressure, battery, startup time, privacy, and which devices receive the feature.

The right placement is often not purely on-device or purely cloud. Decide per task, then measure on the slowest supported hardware and network.

Begin with the task envelope

Write down what one operation requires:

input:       up to 30 seconds of transcribed speech
output:      title plus five action items
deadline:    first useful result within the product's target
offline:     desirable, not mandatory
sensitivity: meeting content may be confidential
frequency:   several times per day
devices:     the actual supported OS and hardware range

Without this envelope, “run a small model locally” is not an engineering requirement. Input length and output size affect memory and compute. Frequency affects battery. Sensitivity affects whether a cloud path is permitted.

Compare three placements

Placement	Strengths	Constraints
On-device	can work offline; input may stay local; no inference round trip	model package size, RAM, thermal load, device fragmentation
Cloud	larger model choices; centralized updates; predictable server tooling	network latency, service cost, data transfer and retention concerns
Hybrid/edge	local routing, redaction, or fallback plus remote generation	two implementations, synchronization, more failure states

Hybrid does not automatically mean “best of both.” It adds a boundary that must be tested. A local classifier followed by cloud generation can reduce unnecessary uploads, but the product now needs a rule for classifier uncertainty and offline behavior.

Budget memory before model quality

A model’s file size is not its complete runtime footprint. Budget for:

weights after the chosen quantization;
runtime and graph overhead;
key-value cache, which grows with context and generation;
tokenizer and supporting assets;
input buffers and application UI;
temporary memory during model loading or conversion.

Test memory warnings and background/foreground transitions. Mobile operating systems can terminate an application that behaves acceptably during a short foreground demo but exceeds pressure limits during longer use.

Do not publish one device result as a universal benchmark. Record model artifact hash, runtime version, device, OS version, power state, thermal state, prompt length, output length, and whether the run was cold or warm.

Measure the experience in phases

For interactive generation, collect:

cold model load
warm request setup
time to first output
output rate
time to completion
peak memory
energy or battery impact over a repeatable workload
thermal behavior across repeated runs

A fast first run can be misleading. Sustained use may trigger thermal throttling, and a model kept resident for speed may increase memory pressure. Test a session that resembles actual product frequency.

For cloud inference, add DNS/connect time, upload time, network type, retry count, and server timing when available. Test high latency and packet loss, not only good office Wi-Fi.

Treat model delivery as application delivery

Bundling weights increases the base application download. Downloading after install creates a second product flow:

explain the size and purpose;
check storage and network conditions;
support pause, resume, and cancellation;
verify the artifact’s integrity;
keep compatibility between app, runtime, tokenizer, and model versions;
remove obsolete artifacts safely.

Avoid silently downloading a large model over a metered connection. If the model is optional, make the feature’s storage visible and removable.

On Apple platforms, Core ML model deployment documents downloading and compiling models on a user’s device. Other runtimes use different packaging mechanisms, but model artifacts still need versioning and lifecycle management.

Make the privacy claim precise

“Runs on device” does not guarantee that data stays on device. Check every path:

analytics and crash reports;
prompt or output logs;
cloud fallback;
remote safety or moderation checks;
synchronization and backups;
shared clipboard or exported files;
third-party keyboards, extensions, or SDKs involved in input.

Describe the actual boundary: “Audio and transcript remain on this device unless the user chooses cloud fallback,” for example. Then test that boundary and make fallback consent explicit.

Also decide whether model outputs contain sensitive derived data. Keeping input local while uploading the generated summary may still violate the intended privacy property.

Design interruption and recovery

Mobile work is interrupted. Calls arrive, apps enter the background, connectivity changes, and the OS reclaims resources. Define behavior for:

backgrounding during model load or generation;
audio-session interruption;
low-memory termination;
loss of network during a cloud request;
switching from Wi-Fi to cellular;
low-power mode and thermal warnings;
app updates while an optional model is downloading.

Persist only the state required to recover. A generation operation needs an ID and clear terminal state; replaying it after restart must not duplicate an external action.

Use a placement gate

Choose on-device only if the evaluated model fits the supported device envelope and the privacy/offline benefit justifies packaging and runtime cost. Choose cloud only if network, data policy, and operating cost meet the task requirement. Choose hybrid when a clearly defined local stage changes the outcome enough to justify a second execution path.

The final decision should include measured device results, a fallback behavior, artifact delivery plan, data-flow diagram, and a list of unsupported devices or states. Placement becomes an engineering decision when the team can say exactly which constraint it satisfies—and what it costs elsewhere.

Google Now Labels AI-Generated Ads — Here's What That Means for Digital Marketing

Roronoa — Fri, 10 Jul 2026 04:36:23 +0000

Google just started labeling AI-generated ads. If you see an ad with a small "AI-generated" tag, that's Google's new transparency feature in action.

It sounds minor. It's not. This is the beginning of a fundamental shift in how we interact with digital content.

What's changing

Google now requires advertisers to disclose when ad content (images, text, audio, video) is created or significantly modified by AI. The label appears on the ad itself, visible to users.

The policy covers:

AI-generated images in display ads
AI-written ad copy
AI-processed audio or video
Deepfake-style content

Enforcement is based on a combination of advertiser self-reporting and Google's own detection systems.

Why this matters

We're entering an era where you can't trust what you see online. AI can generate:

Photorealistic images of products that don't exist
Testimonials from people who never gave them
Video demonstrations of features that don't work
Voiceovers that sound like real customers

Without labeling, consumers have no way to distinguish real content from AI-generated content. That's a problem for trust, for informed decision-making, and for the entire digital advertising ecosystem.

The detection challenge

Here's the catch: how do you detect AI-generated content?

Current approaches:

Metadata analysis: Checking for AI tool signatures in file metadata
Visual artifacts: Looking for telltale signs (weird hands, inconsistent lighting)
Statistical analysis: Detecting patterns in pixel distribution
Watermarking: Embedding invisible markers in AI outputs

The problem: these methods are unreliable and easily circumvented. If an advertiser removes metadata and cleans up artifacts, detection fails.

Google's approach relies heavily on self-reporting. That's like asking speeders to ticket themselves.

What this means for marketers

If you're in digital marketing:

Disclosure is now required: Don't try to hide AI usage — the penalties aren't worth it
Quality matters more: AI-generated content that looks obviously AI will hurt your brand
Hybrid approaches win: Use AI for drafts, human editors for polish
Document your process: Keep records of what was AI-generated vs human-created

The brands that embrace transparency will build trust. The ones that try to hide AI usage will get caught and lose credibility.

The broader trend

Google's labeling is part of a larger movement toward content authenticity:

EU AI Act: Requires disclosure of AI-generated content
C2PA standard: Industry initiative for content provenance
Social media platforms: Adding AI content labels
News organizations: Developing AI usage policies

The direction is clear: transparency about AI usage is becoming mandatory, not optional.

For developers

If you build tools that generate content:

Add disclosure features: Make it easy for users to label AI content
Support provenance standards: Implement C2PA or similar
Build detection tools: Help identify AI-generated content
Design for transparency: Don't make it easy to hide AI usage

I've been building content tools that include automatic AI disclosure. It's a small feature that builds user trust and keeps you ahead of regulations.

My workflow

When I create content (including this article), I use AI tools for research and drafting. But I always:

Edit and verify facts manually
Add my own perspective and experience
Disclose AI assistance when relevant
Use tools like MonkeyCode to verify technical claims

Transparency isn't just a legal requirement — it's good practice. Readers appreciate honesty about how content is created.

What's next

Google's labeling is a first step. Expect:

More detailed labels: Not just "AI-generated" but what percentage was AI
Platform-wide standards: Consistent labeling across Google, Meta, TikTok
Consumer tools: Browser extensions that highlight AI content
Verification systems: Ways to prove content is human-created

The advertising industry is being forced to adapt. The question is whether it will embrace transparency or fight it.

What do you think? Is labeling AI-generated ads enough, or do we need stronger measures?

OpenAI's New Voice Model Listens Even When You're Not Talking — And Nobody's Addressing It

Roronoa — Thu, 09 Jul 2026 11:48:40 +0000

OpenAI just dropped new voice models that promise "more natural live conversations." The demos sound incredible — fluid, responsive, almost human.

But here's the elephant in the room: when does "always ready" become "always listening"?

The Convenience Trap

Let's be honest about what "natural live conversation" means technically:

The model needs to process audio continuously
It needs to detect when you start speaking
It needs to understand context from previous utterances

All of this requires constant audio monitoring. And that's where things get uncomfortable.

What OpenAI Isn't Saying

The announcement focuses on capability, not on:

When does recording start? Is it processing ambient audio before you say the wake word?
Where is audio processed? On-device or in the cloud?
How long is audio retained? Is your conversation stored, even temporarily?
Who has access? Can employees review conversations for "quality"?

These aren't hypothetical concerns. Amazon's Alexa was caught recording conversations and sharing them with contractors. Google Assistant was found storing audio even when users thought it was off.

The Developer's Dilemma

If you're building with these voice APIs, you're now responsible for:

User consent — do your users know they're being recorded?
Data handling — where does the audio go after processing?
Privacy compliance — GDPR, CCPA, and a dozen other regulations
Trust architecture — how do you prove you're not misusing voice data?

I've been building voice-enabled apps for 3 years, and I can tell you: most developers don't think about this until they get a legal letter.

The Real Problem: No Transparency

The issue isn't that OpenAI's voice models are malicious. It's that we have zero visibility into:

What triggers audio processing
What happens to audio after it's processed
What safeguards exist against misuse

Compare this to MonkeyCode, which takes a fundamentally different approach:

On-premise processing — your data stays on your infrastructure
Transparent operations — you can audit exactly what's happening
User control — you decide when AI is active, not the other way around

The lesson is clear: AI convenience shouldn't require surrendering privacy.

What We Should Demand

Before celebrating OpenAI's voice breakthrough, we should ask:

Explicit opt-in — voice processing should never be default-on
Visual indicators — users should always know when audio is being processed
Local processing options — not everything needs to go to the cloud
Audit trails — developers should be able to verify what data is collected

The Bottom Line

OpenAI's new voice models are impressive technology. But impressive technology without privacy safeguards is just surveillance with better marketing.

As developers, we need to stop accepting "it just works" as sufficient. We need to ask "how does it work?" and "what does it cost — not in dollars, but in privacy?"

The future of voice AI shouldn't be "always listening." It should be "listening only when I explicitly ask."

What's your take? Are you comfortable with always-on voice AI? Where do you draw the line between convenience and privacy? 👇