DEV Community: babycat

Build an Accessible Agent Task Timeline, Not a Spinner

babycat — Fri, 10 Jul 2026 10:08:24 +0000

A spinner is honest for about two seconds. After that, it stops answering the questions a person actually has:

What is happening now?
Did anything finish?
Is the product waiting for me?
Can I leave and come back?
What will cancellation preserve?

Long-running agent tasks need two interface layers: a concise current-state summary and a durable event history. The summary helps someone decide what to do now. The history helps them understand what already happened without relying on animation or memory.

Start with a state-to-message contract

Do not let each backend event become raw UI copy.

State	Summary	Primary action
queued	Waiting for an environment	Cancel
running	Name the current verifiable step	View details or cancel
needs input	State the decision and consequence	Answer question
succeeded	Name the artifacts ready for review	Review patch/results
failed	State what is preserved and what can retry	Retry or inspect logs
canceled	State whether partial changes remain	Review or discard

“Working…” is not a useful running message. “Running unit tests: 42 of 68 complete” is useful because it has an object and progress that the system can actually verify.

A single-file implementation

Save the following as task-timeline.html and open it in a browser:

<!doctype html>
<html lang="en">
  <meta charset="utf-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />
  <title>Accessible task timeline</title>
  <style>
    body { font: 1rem/1.5 system-ui; max-width: 44rem; margin: 3rem auto; padding: 0 1rem; }
    .summary { padding: 1rem; border: 2px solid #555; border-radius: .75rem; }
    li { margin-block: .75rem; }
    time { color: #555; }
    button { padding: .6rem .9rem; margin-right: .5rem; }
  </style>
  <main>
    <h1>Refactor authentication</h1>
    <p id="summary" class="summary" role="status" aria-live="polite" aria-atomic="true">
      Task queued. No action needed.
    </p>
    <ol id="events" aria-label="Task event history"></ol>
    <button id="advance" type="button">Simulate next update</button>
    <button id="cancel" type="button">Cancel task</button>
  </main>
  <script>
    const updates = [
      ["running", "Environment ready; analyzing the repository."],
      ["needs input", "Choose the target branch before changes continue."],
      ["running", "Branch selected; running tests."],
      ["succeeded", "Task complete; review the patch and test results."],
    ];
    let index = 0;
    const summary = document.querySelector("#summary");
    const events = document.querySelector("#events");
    const advance = document.querySelector("#advance");
    const cancel = document.querySelector("#cancel");

    function addEvent(state, message) {
      summary.textContent = `${state}: ${message}`;
      const item = document.createElement("li");
      const now = new Date();
      item.innerHTML = `<strong></strong><br><span></span> <time></time>`;
      item.querySelector("strong").textContent = state;
      item.querySelector("span").textContent = message;
      item.querySelector("time").textContent = now.toLocaleTimeString();
      item.querySelector("time").dateTime = now.toISOString();
      events.append(item);
    }

    advance.addEventListener("click", () => {
      if (index >= updates.length) return;
      addEvent(...updates[index++]);
      if (index === updates.length) {
        advance.disabled = true;
        cancel.disabled = true;
      }
    });

    cancel.addEventListener("click", () => {
      addEvent("canceled", "Task canceled; partial changes require review.");
      advance.disabled = true;
      cancel.disabled = true;
    });
  </script>
</html>

The demo deliberately keeps focus on the button the user activated. Moving focus to every new event would make a live interface difficult for keyboard and screen-reader users. The role="status" summary announces a short, polite update; the ordered list remains available for deliberate review.

Accessibility decisions hiding in the code

One live region, not a live log

Marking the whole event stream as live can produce a wall of announcements. Announce the newest decision-relevant summary once. Let users navigate history normally.

Text carries the state

Color can reinforce success or failure, but it cannot be the only signal. The demo uses visible state words and complete messages. Add icons only with accessible names or hide decorative icons from assistive technology.

Cancellation has a result

The button says “Cancel task,” but the resulting message says what remains: partial changes require review. In a real product, confirm whether cancellation stops future work, discards a workspace, preserves a patch, or merely requests termination.

Time is machine-readable

The visible time is local and readable. The dateTime value preserves an ISO timestamp for assistive technology and future formatting.

A documented product example

The public MonkeyCode repository includes this screenshot of its AI task workspace:

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

The screenshot is useful context for a frontend review, but it is not an accessibility test. A serious review still needs keyboard navigation, focus behavior, semantic inspection, zoom and reflow, contrast, screen-reader announcements, reduced motion, error recovery, and tests with people who use assistive technology.

For a task workspace such as MonkeyCode, I would verify these flows first:

returning to a task after the page reloads;
receiving a question while focus is elsewhere;
canceling while a command is running;
distinguishing “cancel requested” from “canceled”;
reviewing partial files after a failure;
opening a preview without losing task context.

This article demonstrates an independent UI pattern. It does not claim that MonkeyCode currently implements the exact markup or behavior above.

Disclosure: I contribute to the MonkeyCode project. Product observations are limited to the linked public screenshot and repository documentation.

Frontend developers can join the MonkeyCode Discord to discuss the task interface with the team. Readers interested in trying the hosted workflow can also ask about current free model-credit availability, eligibility, and usage limits.

The core pattern is simple: keep the current state short, keep the history durable, announce only what needs attention, and make every stop state explain what the user can recover next.

An Accessible Streaming AI Interface Has More Than a Loading Spinner

babycat — Fri, 10 Jul 2026 07:12:05 +0000

Streaming text makes an AI feature feel responsive, but it also creates an awkward interface: the result is visible before it is complete, changes many times per second, and may fail after the user has already started reading.

An accessible implementation needs more than a spinner and an aria-live attribute. It needs an understandable state model.

Give every state a user-facing meaning

Start with explicit states:

type GenerationState =
  | { name: "idle" }
  | { name: "submitting" }
  | { name: "streaming"; partialText: string }
  | { name: "complete"; text: string }
  | { name: "cancelling"; partialText: string }
  | { name: "cancelled"; partialText: string }
  | { name: "failed"; partialText: string; retryable: boolean };

This prevents contradictory UI such as an enabled Generate button beside a result that is still arriving. It also forces product decisions: Does partial text remain after cancellation? Can a failed request be retried? Is a streamed draft safe to copy before validation?

Separate visual output from announcements

Do not place the rapidly changing token stream inside an assertive live region. A screen reader may attempt to announce every update, producing noise that is impossible to follow.

Use two regions:

<div id="generation-status" role="status" aria-live="polite"></div>

<section aria-labelledby="result-heading" aria-busy="true">
  <h2 id="result-heading">Generated draft</h2>
  <div id="result-output"></div>
</section>

Update the visible output as text arrives. Update the status region only at meaningful transitions:

“Generating draft.”
“Draft complete.”
“Generation cancelled. Partial text is available.”
“Could not generate the draft. Your input was preserved.”

Set aria-busy="false" when the operation reaches a terminal state. The WAI-ARIA specification defines the status role as a live region with polite announcements; reserve interruptive alerts for information that genuinely needs immediate attention.

Keep focus under the user’s control

Starting generation should not move focus to the output. The user may want to review or edit the input while waiting. When generation completes, announce completion and provide a clear way to reach the result.

Move focus only when it supports recovery, for example:

to a validation error after submission;
to an error summary after a failed operation when the current control no longer explains what happened;
to a confirmation dialog for a consequential next action.

Do not focus every new paragraph or token. Dynamic content can update without taking the keyboard away.

Implement real cancellation

The Cancel button should be a button, stay keyboard reachable, and describe its operation:

<button type="button" id="cancel-generation">
  Cancel generation
</button>

In the browser, connect it to an AbortController:

const controller = new AbortController();

const response = await fetch("/api/drafts", {
  method: "POST",
  body: JSON.stringify(payload),
  signal: controller.signal,
  headers: { "content-type": "application/json" },
});

cancelButton.addEventListener("click", () => controller.abort());

AbortController stops the browser-side fetch, as documented by MDN’s AbortController. If the backend starts a separate job, send a cancellation request there too; disconnecting the browser does not necessarily stop server work.

While cancellation is pending, change the button label to “Cancelling…” and disable repeated activation. After cancellation, state clearly whether partial output was kept and whether it has been validated.

Preserve the input and the partial result

A generic “Something went wrong” message creates unnecessary work. A useful error state answers:

What happened?
Was the user’s input saved?
Is partial output available?
Can the operation be retried safely?
Is there another path to complete the task?

Example:

The draft stopped before completion. Your source text and the partial draft
are still here. Try again, or continue editing the partial draft manually.

When retrying, avoid deleting the partial result until the replacement has started successfully. If a retry might create a duplicate action, the server needs an idempotency key; the UI alone cannot guarantee safety.

Label uncertainty at the right level

A permanent banner saying “AI may be wrong” quickly becomes wallpaper. Put guidance next to the decision it affects:

mark streamed output as “Draft—still generating”;
show source links beside claims when the feature has retrieval evidence;
use an editable field for content the user is expected to review;
require explicit confirmation before publishing, sending, or changing data;
distinguish “no source found” from “the request failed.”

The interface should make correction normal, not frame it as an exceptional failure by the user.

Test more than the happy path

Run the component with:

keyboard-only navigation;
a screen reader at normal and very fast stream rates;
reduced motion enabled;
200% and 400% zoom;
a slow response, an empty response, malformed data, and a mid-stream error;
cancellation before the first token and after substantial text;
a retry after reconnecting to the network.

Also test the DOM announcement sequence. A snapshot can confirm labels and roles, but listening to the interaction is what reveals repeated or interrupted announcements.

Streaming is a presentation technique, not a complete interaction model. When status, output, focus, cancellation, and recovery are designed separately, the interface can feel fast without becoming confusing or exhausting.

Ollama Just Raised $65M — Here's Why Open-Source AI Tools Are Winning

babycat — Fri, 10 Jul 2026 04:36:17 +0000

Ollama just raised $65 million. The open-source tool for running AI models locally now has nearly 9 million users. That's massive for a developer tool that most non-technical people have never heard of.

But if you're a developer who cares about privacy, cost, and control, you probably already know why Ollama is winning.

What Ollama actually does

In case you haven't used it: Ollama lets you run large language models on your own computer. No API calls, no cloud, no monthly bills. Download a model, run it locally, use it for whatever you want.

The experience is dead simple:

ollama run llama3

That's it. You now have a local AI assistant that runs entirely on your machine.

Why developers love it

Three things drive Ollama's adoption:

1. Privacy
Your code never leaves your machine. For companies with strict data policies (healthcare, finance, government), this isn't a nice-to-have — it's a requirement.

2. Cost
API calls add up fast. If you're using GPT-4 for development, you might spend $50-200/month. Ollama is free. The models are free. Your electricity bill is the only cost.

3. Control
No rate limits. No downtime. No "we're experiencing high traffic" messages. Your model runs when you want it, how you want it.

The numbers tell the story

9 million users is huge for a developer tool. For context:

Docker took years to reach similar adoption
VS Code had about 10M users in its first couple years
Ollama hit 9M in under 2 years

The growth is driven by one thing: local AI models got good enough.

A year ago, running Llama locally meant poor quality output and complex setup. Now, models like Llama 3, Mistral, and Phi-3 are genuinely useful for coding, writing, and analysis. And Ollama makes them accessible with one command.

What $65M buys you

With this funding, Ollama can:

Hire more engineers: The core team is small; they need more hands
Optimize performance: Running models locally still requires decent hardware
Expand model support: More models, better compatibility
Build enterprise features: SSO, team management, compliance tools

The enterprise angle is where the money is. Individual developers are great for adoption, but enterprises pay the bills.

The local AI movement

Ollama isn't alone. The entire local AI ecosystem is growing:

LM Studio: GUI for running local models
GPT4All: Another local model runner
llama.cpp: The engine behind many local AI tools
Hugging Face: Hub for downloading models

This movement is driven by distrust of cloud AI providers and the desire for control. After seeing companies change pricing, restrict usage, and train on user data, developers want alternatives.

My local setup

I run Ollama with a few models:

Llama 3 8B: For general coding questions
Mistral 7B: For faster responses when quality matters less
CodeLlama: For code-specific tasks

Combined with tools like MonkeyCode for code review, I have a mostly-local development workflow. The only cloud AI I use regularly is Claude for complex reasoning tasks that local models can't handle yet.

The hardware question

The main barrier to local AI is hardware. Running a 7B parameter model requires:

8GB+ RAM (16GB recommended)
A decent GPU helps but isn't required
SSD storage for model files

Most developer laptops from the last 2-3 years can handle it. Desktop users with dedicated GPUs get the best experience.

What this means for the market

Ollama's success proves there's a market for local AI tools. Expect more investment in this space:

Hardware companies will optimize for local AI (Apple already does with Neural Engine)
Model makers will prioritize smaller, efficient models
Cloud providers will offer hybrid options (cloud + local)
Enterprise tools will add local-first AI features

The $65M isn't just for Ollama. It's a bet that the future of AI isn't all-cloud.

Try it

If you haven't tried Ollama, now's a good time:

# Install
curl -fsSL https://ollama.ai/install.sh | sh

# Run a model
ollama run llama3

The barrier to entry is basically zero. And with 9 million users, the community support is solid.

What's your experience with local AI tools? Are they good enough for your daily workflow yet?

Meta's Muse Image Generator Uses Your Photos — And the Opt-Out Is Designed to Fail

babycat — Thu, 09 Jul 2026 11:44:37 +0000

Meta just launched Muse Image, their new AI image generator. And within hours, users discovered something disturbing: it's trained on your photos.

The backlash was immediate. But Meta's response reveals a deeper problem with how big tech companies approach AI training data — and why their "opt-out" mechanisms are designed to be as inconvenient as possible.

What Actually Happened

Meta rolled out Muse Image as part of their AI ecosystem. The tool generates images from text prompts, similar to DALL-E or Midjourney. But users quickly noticed that Muse could generate images that looked suspiciously similar to their private photos.

The issue? Meta's AI training data includes photos from Facebook and Instagram — your photos — unless you specifically opt out.

The Opt-Out Illusion

Here's where it gets infuriating. Meta technically allows you to opt out of having your data used for AI training. But they've designed the process to be as painful as possible:

You have to find the form — it's buried deep in Meta's privacy settings, not linked from any obvious location
You need to provide specific URLs — you can't just say "don't use my photos." You need to provide exact URLs of the content you want excluded
It's per-item — you have to submit separate requests for each photo, album, or piece of content
No bulk opt-out — there's no "exclude all my content" button

If you have 1,000 photos on Instagram, you need to submit 1,000 individual requests. That's not a choice. That's a punishment for caring about privacy.

Why This Matters for Developers

This isn't just a Meta problem. It's a pattern across the entire AI industry:

OpenAI trained on the entire internet without explicit consent
Stability Diffusion used LAION-5B, which contains billions of scraped images
Google uses your Gmail, Docs, and Search history for AI training

The default is always opt-in by default, opt-out by design. And the opt-out is always just inconvenient enough that most people won't bother.

The Real Solution: AI-Native Privacy Tools

The problem isn't that AI uses data. The problem is that users have no control over how their data is used.

This is where tools like MonkeyCode take a fundamentally different approach. Instead of building AI that hoovers up everything and asks questions later, MonkeyCode is designed with privacy as a core feature:

On-premise deployment — your code and data stay on your infrastructure
Transparent processing — you know exactly what data is being used
User control — you decide what gets processed, not an algorithm

The lesson from Meta's Muse debacle is clear: AI tools need to be built with privacy from day one, not bolted on after the backlash.

What You Can Do Right Now

If you're concerned about your data being used for AI training:

For Meta/Facebook/Instagram:

Go to Meta's privacy center
Look for "AI data usage" settings
Submit opt-out requests (prepare to spend hours if you have lots of content)

For a better approach:

Use tools that are privacy-first by design
Choose AI assistants that run locally or on your own infrastructure
Support open-source AI projects that respect user consent

The Bigger Picture

Meta's Muse controversy isn't about one image generator. It's about the fundamental question of who owns your digital identity in the age of AI.

Right now, the answer is: not you.

Your photos, your writing, your code, your conversations — they're all training data. And the companies using them have made it deliberately difficult to say no.

It's time to demand better. Not just better opt-out forms, but better defaults. AI should be opt-in, not opt-out. Privacy should be the starting point, not an afterthought.

Have you checked your Meta privacy settings recently? What's your take on AI training data consent? Let's discuss below. 👇