How I Researched the Way Developers Work with Agentic AI

Even in a professional setting, as a software engineer, working with AI still raises a lot of questions. How should we collaborate with AI agents? How much access should we give them so they can actually help, without breaking things? These questions kept coming back to me, so I took on the challenge of an exploratory study at my company: how do developers, who are also my peers and juniors, adopt and collaborate with agentic AI?

The full report is on the company research page. Here I want to share the part a report doesn't show: how the research came together.

The questions and the interview

A survey didn't feel right for this. Almost every answer would need a follow-up question that depended on what the participant had just said, and that turned out to be true. I had done qualitative research before, interviewing users to build personas for the Jenius UI/UX competition, so interviews were the natural choice.

What I wasn't happy with from that competition was the analysis. It wasn't clear or standardised; I mostly read the notes and drew my own conclusions. This time I wanted a more formal qualitative method from HCI research, so the workflow and the results would hold up. I settled on an informed grounded theory approach. I went in with a few starting themes, coded the transcripts in steps, and let the categories come out of what people actually said.

I also reached out to my teammate from that competition. They helped me check and clean up the method, and stress-tested my interview questions before I committed to them. Having someone poke holes in the questions early saved me from a few leading ones.

In the end I interviewed seven developers, from under three years of experience to over ten. Each interview was semi-structured and lasted 45 to 60 minutes over video call.

Finding the three starting topics

I started from my own questions, then dug into current trends and literature on how agentic AI is affecting developers. Social media was loud: developers will soon be obsolete, software engineering is no longer relevant. Some people went as far as saying AI is so powerful it will soon be "self-aware". There was also a big controversy about how AI use should be governed and how ethically models are trained. Alongside the noise, I read the latest research on human–AI collaboration.

From all that information gathering, I narrowed it down to three topics.

Interaction shift

This one is HCI-heavy, and it was the first thing I really wanted to confirm. As developers we spend our days in the terminal and the IDE, and both are deterministic: you ask for A, you get A. If you get B, something is wrong. AI doesn't work like that. The same instruction can come back differently.

On my side, being IDE-heavy, moving from a GUI to just typing in a terminal was terrifying at first. I felt like I'd lost control of what I was about to do. I wanted to know if others went through the same thing.

So the questions here revolved around how each developer got familiar with the tooling, and their history of adopting LLMs: from copying answers out of a chat window, to inline suggestions in the editor, to agents. That history turned out to shape a lot of what they use today and how they use it.

Agentic AI as collaborator

This was the main topic. When we wrote code by hand, we owned its structure and quality. I still remember feeling guilty when I copied code from Stack Overflow that I didn't fully understand. Now an agent writes much of it. How do we decide what to hand over, how do we check its reasoning, and when do we trust it?

Identity and socio-technical impact

This section came from the hype on social media. On a personal level, do developers feel threatened by agentic AI? When I drafted the questions, the first thing on my mind was code ownership, because that's what we developers now delegate. If we only check and review, can we still say the code is ours? The other important part was the future of software engineering, and how we hire and grow junior engineers.

The topic I didn't plan for

While I was coding the transcripts, one topic kept showing up that didn't fit any of the three: the tools themselves. Developers had different reasons for choosing a tool and different ways of using it. Some stayed in the IDE because they could read what was happening. Others moved to the terminal because it could reach across several repositories. Some judged a tool by the size of its community, because a tool that disappears means relearning everything.

Tool choice turned out to shape the other three topics too: how much of the agent's work you can see, how you review it, and even how you think about ownership. So I added it as a fourth, emerged topic: Tooling and Platform Adoption. It's my favourite part of the method, honestly. The structure let the data say something I hadn't asked about.

What I'd do differently

I know there's still a lot to improve. It's a small study at one company, I was interviewing colleagues who know me, and all of us learned to code before agents existed. So what people said about juniors is a guess about a group none of us has supervised yet.

And the technology moves fast. Tools and models changed even during the two weeks of interviews. Some of these views and workflows could look different within a few months. I think that's fine for exploratory research. It's a snapshot, and the next one should start from where this one ended.