AI Systems Become Infrastructure Before Users Learn When to Distrust Them

Developers adopt AI coding tools unevenly—some tasks see 80% uptake, others get ignored. We don't know which friction points actually warrant AI investment versus which are just hype.

Method: 860 developers mapped their tasks using cognitive appraisal theory, revealing that developers want AI for high-effort, low-stakes work (boilerplate, documentation) but reject it for high-stakes debugging where errors cascade. The study provides the first task-aware adoption matrix: developers rated 'routine coding' as prime AI territory (high effort, low consequence) while flagging 'architecture decisions' as a no-go zone (high consequence, requires human judgment). This isn't about capability—it's about risk tolerance.

Caveats: Self-reported perceptions, not observed behavior. Developers may overestimate their willingness to use AI in low-stakes tasks.

Reflections: How do adoption patterns shift as developers gain experience with AI tools over 6-12 months? · What specific explainability features would make developers trust AI in higher-stakes debugging scenarios? · Do these task preferences hold across different programming languages and domains (web vs. systems vs. data science)?

Romance fraud and pig-butchering scams exploit platform design—verified badges, algorithmic recommendations, integrated payments—to build trust over weeks or months. Victims blame themselves, not the platforms that enabled it.

Method: Interviews with scam victims reveal how platform affordances amplify manipulation: professional-looking profile verification signals legitimacy, algorithmic recommendations reinforce repeated contact, and integrated payment systems remove friction at the critical moment. Victims described how private chat features created a 'sealed bubble' where scammers could operate without external reality checks. The study reframes scams as a platform design problem, not just a user education problem—victims understood general scam warnings but couldn't recognize them in context.

Caveats: Qualitative study with self-selected victims; may not capture full range of scam tactics or platform vulnerabilities across all contexts.

Reflections: What specific friction points (payment delays, external confirmations) reduce scam completion without harming legitimate users? · How do scammers adapt when platforms add verification or friction features? · Can platforms detect gradual trust-building patterns algorithmically before financial harm occurs?

Pink-for-women, blue-for-men color schemes in data visualizations may trigger gender stereotypes during decision-making. No one has tested whether these color choices actually bias outcomes like salary recommendations.

Method: Controlled experiment with 160 participants making salary decisions from gendered bar charts. Stereotype-aligned colors (pink/blue) produced no significant bias in pay recommendations compared to neutral colors (green/purple) or grayscale. However, participants spent 8% more time on stereotype-aligned visualizations and showed subtle differences in confidence ratings. The study used a between-subjects design with salary recommendation as the primary outcome, controlling for participant gender and prior beliefs about pay equity.

Caveats: Lab study with hypothetical decisions; real-world stakes and organizational context may amplify subtle effects not detected here.

Reflections: Do stereotyped colors have stronger effects in domains beyond salary (hiring, promotion, performance reviews)? · What happens with cumulative exposure—do repeated stereotype-aligned visualizations create bias over time? · How do cultural differences in color-gender associations affect these results outside Western contexts?