AI Assistance Erodes What It Claims to Enhance

AI writing assistants improve fluency but erode writers' sense of authorship. Users can't tell where their thinking ends and the model's begins.

Method: An ownership-aware co-writing editor that offers sentence-level suggestions on demand, testing two interventions: persona-based coaching (e.g., 'Write like a confident professional') and style personalization (trained on user's prior writing). In a 176-person study across three professional writing tasks, generic AI suggestions reduced perceived ownership, but persona coaching restored it without sacrificing fluency gains. Style personalization showed no ownership benefit.

Caveats: Persona coaching only tested for professional writing tasks. Unclear if it works for creative or technical domains.

Reflections: Does persona coaching scale to longer documents where authorship boundaries blur over time? · Can users detect when persona suggestions subtly shift their intended meaning? · What happens to ownership when multiple personas are used in a single document?

LLM-based web agents fail on real-world tasks because they can't handle long sequences of actions or the visual chaos of heterogeneous site designs.

Method: ColorBrowserAgent uses a dual-mode architecture: autonomous mode for routine actions, collaborative mode for ambiguous decisions. The key mechanism is a color-coded overlay system that segments the DOM into visually distinct regions, reducing the token count LLMs need to process. It also implements a hierarchical planning system that breaks tasks into subtasks with explicit checkpoints. Tested on complex workflows like multi-step booking and form submission.

Caveats: Requires DOM access, so it won't work on heavily obfuscated or canvas-based interfaces.

Reflections: How do users calibrate trust when the agent switches between autonomous and collaborative modes? · Can color-coded segmentation generalize to mobile interfaces with smaller screens? · What's the latency cost of hierarchical planning on time-sensitive tasks?

Block-based programming environments like Scratch are standard in K-12 CS education, but they're inaccessible to blind students. Prior solutions required modifying the Blockly library, which killed adoption.

Method: The Extension-based Accessibility Framework (EAF) makes Blockly accessible without touching the core library. It uses a browser extension that injects keyboard navigation, screen reader support, and audio cues into existing Blockly instances. The framework intercepts DOM events and translates visual block relationships into a navigable tree structure. Tested with BVI students on Code.org and Scratch-based platforms.

Caveats: Only works for Blockly-based environments. Doesn't address other visual programming paradigms like node-based editors.

Reflections: Can the extension handle custom Blockly blocks created by educators? · How do BVI students debug programs when error messages are visually positioned? · Does the audio feedback scale to large programs with hundreds of blocks?