AI Assistance Has a Timing Problem, Not a Capability Problem

AI writing assistants improve fluency but erode writers' sense of ownership. Researchers tested whether better framing could restore it.

Method: The study tested two common design interventions: persona-based coaching (framing suggestions as 'write like a confident professional') and style personalization (training on users' prior writing). Neither intervention restored ownership. Across 176 participants completing professional writing tasks, both persona-based and personalized suggestions left writers feeling equally detached from their text compared to generic AI suggestions.

Caveats: Tested only on professional writing (emails, proposals, cover letters). Creative writing contexts might differ.

Reflections: Would post-generation editing interfaces (where AI drafts, user revises) preserve ownership better than inline suggestions? · Does ownership erosion persist over time, or do writers adapt and reclaim authorship with extended AI use? · Are there task types where ownership doesn't matter—and if so, how do users distinguish them?

Proactive AI coding assistants could accelerate development, but interruptions might disrupt focus. When are developers actually receptive to unsolicited suggestions?

Method: Developer receptivity varied dramatically by task phase. During exploration (understanding requirements, planning architecture), 73% of proactive suggestions were welcomed. During focused implementation (writing specific functions), identical suggestions were rejected 68% of the time. The AI tool couldn't detect which phase developers were in, leading to mistimed interruptions.

Caveats: Five-day field study with 12 professional developers. Longer deployments might show adaptation or habituation effects.

Reflections: Can task phase be reliably inferred from code activity patterns (file switching, compile frequency, search behavior)? · Do developers develop learned helplessness if proactive suggestions are consistently mistimed? · Would user-initiated 'exploration mode' labels improve receptivity without adding cognitive overhead?

Block-based programming environments like Scratch are standard in K-12 CS education, but remain inaccessible to blind students. Prior solutions required modifying Blockly's core library, limiting adoption.

Method: The Extension-based Accessibility Framework (EAF) makes Blockly accessible without core library modifications. It uses a browser extension to inject keyboard navigation, screen reader support, and spatial audio cues. Tested with 12 BVI students across three existing BBPEs (Code.org, Scratch, custom platforms), all participants successfully completed programming tasks using only keyboard and screen reader.

Caveats: Tested with 12 BVI students in controlled tasks. Classroom deployment at scale not yet validated.

Reflections: Does the extension approach scale to more complex block structures (nested loops, custom functions)? · How do spatial audio cues compare to purely verbal descriptions for conveying block relationships? · Can the framework extend to other visual programming paradigms (node-based, dataflow)?