How confidence cues shape developers' trust in AI-generated code
This project was developed during a semester-long Human Factors & Ergonomics module guided by Prof. Swati Pal at IDC, IIT Bombay.
This case study summarises our experiment and findings.
Akshay R Nair
Kanishk Kamal
Srishti Rachna
What Happens When You Add Trust Cues to AI Responses?
Developers increasingly use AI assistants to generate and optimise code. But a fluent response does not guarantee a correct solution.
Interface cues can influence how carefully a developer checks that solution before using it.
We asked whether adding a confidence label or peer-approval count would change developers’ ability to distinguish correct code from flawed code.
The full research paper documents the study design, detailed methodology, statistical analysis, and implications for designing trust cues in AI-assisted coding tools.
Read the full research paper (PDF)Three ways to present the same code
We compared
We selected software development as a domain where participants could inspect a response and make a concrete decision about its correctness.
Baseline / No Cue
AI code block without any supplementary signals, requiring developers to rely solely on manual code inspection.
This will be our control condition.
Social Proof
AI code block displaying how many peers accepted the solution (Crowd Approval).
Social proof literature (Cialdini; Deutsch & Gerard).
Confidence Label
AI code block displaying the system’s own confidence score.
Automation bias research (Lee & See; Parasuraman & Riley).
Using Google AI Studio, we recreated a chatbot environment with preset questions and answers. Every group evaluated the same content.
Explore the study prototype. The first load may take a few minutes while the server starts.
The Speed-Accuracy Trap
We ran a between-subjects study across 18 Python developers (252 total evaluation decisions). Post-study, we conducted qualitative interviews to understand their experience.
| Metric | Control | Social Proof | Confidence Label |
|---|---|---|---|
| Accuracy | 60.5% | 81.2% | 54.7% |
| Flawed Code Rejection | 40.5% | 92.9% | 50.0% |
| Bug Acceptance Rate (FPR) | 59.7% | 7.2% | 50.0% |
| Cue-Following Rate | — | 63.0% | 77.0% |
| Signal Sensitivity (d’) | 0.635 (weak) | 1.962 (strong) | 0.241 (near coin-flip) |
| Average Decision Time | 89.8s | 59.6s | 36.6s |
What changed across conditions
Peer approval was associated with better bug detection:
Participants in the social-proof condition rejected flawed code on 92.9% of trials, compared with 40.5% in the control condition.
Their overall accuracy was
Confidence labels encouraged faster reliance:
Participants in this condition made decisions in about 37 seconds, compared with 90 seconds in the control group, and followed the cue on 77% of trials.
However, they accepted flawed code on half of those trials. Their overall accuracy was 54.7%, compared with 60.5% in the control group.
Speed was a trap:
Faster decisions did not correspond to better performance in this study.
The confidence-label condition combined shorter decision times with lower accuracy, suggesting that an apparent gain in efficiency can mask reduced scrutiny.
Designing for Constructive Friction Over Superficial Speed
In this small study, confidence labels were associated with faster decisions and lower accuracy, while peer-approval cues were associated with better detection of flawed code.
This suggests a design direction worth testing further: make the basis for a recommendation visible and
