I'm Not Reading All of That: Understanding Software Engineers' Level of Cognitive Engagement with Agentic Coding Assistants

This paper presents a formative study revealing that software engineers' cognitive engagement declines when using agentic coding assistants due to limited design affordances for reflection and verification, highlighting the need for new interaction modalities and cognitive-forcing mechanisms to sustain critical thinking in AI-assisted programming.

The Gist

The Big Picture: The "Lazy Co-Pilot" Problem

Imagine you are a chef (a Software Engineer) trying to cook a complex, high-stakes meal for a VIP. You hire a super-smart robot assistant (an Agentic Coding Assistant or ACA) to help you.

The robot is amazing. It can chop vegetables, mix sauces, and even invent new recipes faster than you can blink. However, the paper asks a scary question: Because the robot is so fast and efficient, are we chefs stopping thinking entirely?

The researchers found that when we let these robots do the heavy lifting, our brains tend to go on "autopilot." We stop tasting the food, stop checking the ingredients, and just assume the robot knows what it's doing. The paper argues that this is dangerous because if the robot makes a mistake (like adding salt instead of sugar), we might not notice until it's too late.

---

The Experiment: Watching Chefs Cook with Robots

The researchers watched four software engineers (from a beginner to a veteran) use a specific AI tool called Cline to write a script that organizes Excel files. They wanted to see how much the engineers were actually thinking versus just watching.

They broke the process down into three stages, like a movie:

1. The Planning Scene: The engineer tells the robot what to do.
2. The Action Scene: The robot starts typing code and running tools.
3. The Review Scene: The engineer checks the final result.

What They Found: The "Energy Dip"

The study revealed a funny but worrying pattern. The engineers' brain power (cognitive engagement) was highest at the start and lowest at the end.

• At the Start (Planning): The engineers were super focused. They were like a captain giving strict orders to a ship's crew. They made sure the robot understood the mission.
• In the Middle (Action): This is where things went wrong. The robot started spitting out a massive wall of text—lines of code, logs, and status updates.
  • The Metaphor: Imagine the robot is a news anchor who starts reading the entire newspaper at 100 miles per hour. The engineers got overwhelmed. One engineer literally said, "I'm not reading all of that." They looked away, checked their phones, or just waited for the robot to say "Done." They treated the robot's output as a "black box"—they didn't care how it was done, only that it finished.
• At the End (Review): The engineers only looked at the final result (the Excel file). If the file looked right, they said, "Great, job done!" They rarely looked at the code the robot wrote to make that file. They were checking the destination, not the journey.

The "Happy Path" Trap

The researchers noticed that the engineers only paid attention to the "Happy Path."

• The Analogy: Imagine driving a car. The "Happy Path" is driving on a sunny day with no traffic. The engineers only checked if the car drove forward. They didn't think about what would happen if a tire blew out, if it rained, or if a deer jumped out.
• Because they were so focused on the robot getting the "right answer" quickly, they forgot to ask: "What if the robot is lying?" or "What if this code breaks in a weird situation?"

---

The Solution: How to Wake Up the Chef

The paper suggests that we need to redesign these AI assistants so they don't let our brains go to sleep. Here are their two main ideas:

1. Stop Talking, Start Showing (Multimodal Interaction)

Right now, these robots just dump text on the screen. It's like a teacher reading a textbook out loud without showing any pictures.

• The Fix: The robot should use visuals and voice. Instead of writing 50 lines of code, it should draw a flowchart, a graph, or a mind map to show how it's solving the problem.
• Why it works: Just like a map is easier to read than a list of street names, a visual diagram helps the engineer understand the logic without getting a headache. It forces the engineer to look at the "big picture" rather than getting lost in the text weeds.

2. The "Speed Bump" (Cognitive Forcing)

Currently, the robot is too eager to please. It solves the problem instantly.

• The Fix: We need to design the robot to slow down and make the human think.
• The Analogy: Imagine a video game that pauses before giving you a hint. The game says, "I think the answer is X, but why do you think that? Explain your logic first."
• This is called Cognitive Forcing. It's like putting a speed bump in the road. It forces the driver (the engineer) to slow down, look at the road, and think before they proceed. This stops them from blindly trusting the robot and forces them to double-check the "edge cases" (the deer, the rain, the tire blowout).

The Takeaway

The paper concludes that AI shouldn't just be a tool that does the work for us; it should be a "Thinking Partner."

If we let AI do everything without checking its work, we lose our ability to think critically. To build safe, reliable software, we need to design AI that:

1. Shows its work clearly (using pictures and voice, not just text).
2. Forces us to pause and think, rather than just handing us the final answer.

In short: Don't let the robot drive the car while you nap. Keep your hands on the wheel, and make sure the robot shows you the map.

Technical Summary

1. Problem Statement

The rapid integration of Agentic Coding Assistants (ACAs) (e.g., Cline, Claude Code) into software engineering workflows presents a critical risk: over-reliance. While these systems accelerate development, their autonomous nature may undermine human critical thinking, leading to complacency.

• The Core Tension: ACAs are increasingly acting as autonomous collaborators that generate, modify, and reason about code. However, Large Language Models (LLMs) powering them are prone to hallucinations and biases.
• The Gap: Current research focuses on performance metrics (speed, code correctness) but lacks insight into how software engineers (SEs) cognitively engage with these agents. Specifically, there is a need to understand if SEs are merely accepting outputs or actively engaging in sensemaking, verification, and reasoning.
• Goal: To investigate the decline in cognitive engagement during human-ACA interactions and propose design strategies to sustain "Tools for Thought" rather than just "Task Performers."

2. Methodology

The authors conducted a formative user study involving four software engineers with varying levels of experience (ranging from <1 year to >10 years).

• Participants: Four SEs (P1–P4) from a large software company in the Philippines.
• Tool: Cline, an open-source agentic coding assistant chosen for its planning capabilities, tool invocation, and familiarity among participants.
• Task: A single code generation task derived from the DevGPT dataset.
  • Prompt: Write a script to scan Excel files, find a specific sheet ("dashboard"), copy data, and generate a new workbook with specific naming conventions.
  • Process: Participants interacted with Cline in two modes: Plan (agent proposes a solution) and Act (agent generates code). Participants could ask clarifying questions and review the agent's output.
• Data Collection:
  1. Observation: Moderators recorded behavior, including "think-aloud" protocols and eye movements (noted via observation).
  2. Post-Task Survey: Immediately following the task, participants completed a survey based on Bloom's Taxonomy to measure cognitive engagement across five dimensions:
     • Recall (Remembering details)
     • Understanding (Comprehending the logic)
     • Analyzing (Breaking down the structure)
     • Evaluating (Judging the quality/reliability)
• Analysis: Thematic analysis of survey responses and observational notes, cross-referenced with the actual code generation logs.

3. Key Findings

The study revealed two primary patterns indicating a degradation of cognitive engagement as the task progressed.

A. Declining Cognitive Engagement Over Time

• Planning Phase (High Engagement): Participants invested significant cognitive effort here. They actively read prompts, verified file directories, and meticulously reviewed the agent's proposed plans. This was driven by a desire to ensure the agent understood requirements (Germane cognitive load).
• Execution Phase (Sharp Decline): As Cline generated code and invoked tools, engagement dropped precipitously.
  • Information Overload: Participants experienced "extraneous cognitive load" due to the volume of streaming text.
  • Disengagement: Participants looked away, skimmed outputs, or explicitly stated, "I'm not reading all of that." They treated the agent's output as a "black box" until a result was presented.
• Evaluation Phase (Output-Centric): Participants focused almost exclusively on the final output (the Excel file) rather than the process (the code).
  • If the output was correct, they assumed the code was correct (System 1 thinking).
  • Only when errors occurred did they engage in deep process-level review (System 2 thinking).

B. Focus on the "Happy Path"

• Participants primarily recalled, understood, and analyzed the sequence of events that led to a successful outcome.
• Deficiencies in Deep Cognition:
  • Recall: None could correctly recall the number of functions in the generated script.
  • Understanding: Only 50% could summarize the function of the first code block.
  • Analysis/Evaluation: Only 50% felt confident analyzing edge cases or potential vulnerabilities.
• Implication: This "greedy allocation" of cognitive resources means SEs are likely to miss critical security flaws, edge cases, or subtle logic errors that do not immediately break the "happy path."

4. Key Contributions & Design Opportunities

The paper proposes shifting the design paradigm of ACAs from passive code generators to active Tools for Thought that force critical engagement.

A. Multimodal Communication (Beyond Text)

• Problem: Text-only streams overwhelm working memory and encourage skimming.
• Solution: Integrate visualizations (flowcharts, graphs, mind maps) and voice modalities.
  • Visuals can synthesize complex logic, reducing extraneous load.
  • Voice can act as a social cue to maintain attention and improve information retention (citing prior work on AI voice in learning systems).

B. Cognitive Forcing Designs

• Problem: Users default to System 1 thinking (heuristics/shortcuts) to minimize effort.
• Solution: Implement Cognitive Forcing Mechanisms that disrupt the flow to trigger System 2 (analytical) thinking.
  • Interruption: The AI should pause or require user input at critical decision points before proceeding.
  • Verification Gates: Force the user to analyze specific parts of the code or explain a logic step before the agent generates the next block.
  • Delayed Feedback: Similar to usability testing studies, show AI suggestions only after the user has attempted their own analysis, positioning the AI as a verification tool rather than a primary solver.

5. Significance

• Safety & Reliability: In high-stakes software engineering, over-reliance on ACAs without deep cognitive engagement risks deploying systems with undetected vulnerabilities, logic errors, or security flaws (e.g., backdoors).
• Human-AI Collaboration: The study reframes the role of the AI. It should not replace human reasoning but augment it. The design goal is to sustain the "pair programming" dynamic where the human remains an active, critical thinker.
• Future Research: The authors highlight the need for larger studies, more open-ended tasks, and the use of objective metrics (like eye-tracking) to validate self-reported cognitive states.

Conclusion: The paper argues that without intentional design interventions (multimodality and cognitive forcing), agentic coding assistants will lead to a "shallow engagement" where developers lose the ability to critically evaluate the systems they build, potentially compromising software quality and security.