Do I Still Need to Understand the Code?

Coding

AI

Software Architecture

Do I Still Need to Understand the Code?

Abhishek Chaturvedi

15 min read·

1 day ago

--

Actually, I don’t think I have written many long-form things in my life, except code files.

My journey with computers started with Microsoft Word.

I was probably around 10 when I first saw WordArt. It was one of the coolest things I had seen. You could create these amazing (at least for a ten-year-old) pieces of text and make things move around the screen. I remember trying to replicate it myself, building all sorts of fun WordArts.

It was a small thing, but it fascinated me.

That fascination eventually led me to electronic engineering. In college, I participated in a competition where we had to build a robot that could follow a given track. We bought the parts, built a small robot on wheels, and I did the microcontroller coding. It was pretty simple, but I remember having a lot of fun building it and trying to make it actually follow the track.

From there, I eventually landed at Microsoft. That’s where my real software engineering journey began. I spent over a decade there working on different teams, including Exchange Server and Outlook.

One project I worked on at Microsoft was a room booking assistant. The idea was pretty simple: instead of finding and booking a room yourself, you could just select an option indicating that you need a room for the meeting. Before the meeting, the system would find one and book it for you. And if people were joining from different locations, it would book a room in each location.

Then in 2023, I joined Docusign. ChatGPT had just come out and suddenly everyone was talking about AI and trying things with it.

The very first feature I worked on at Docusign was a feature that used AI to summarize an agreement for the signer, so instead of going through pages of an agreement, they could quickly understand what they were signing.

That was really my first experience working with AI on the job. I remember being genuinely excited about it. It felt new, and honestly none of us really knew how far this was going to go.

In this whole journey, I realized that my joy for software engineering has always been solving problems.

I loved writing code. I still write it, or at least I used to before AI took much of that over in recent years. But I have always enjoyed debugging things even more.

Anyone who has spent enough time debugging knows the feeling. You have an issue that makes absolutely no sense. You try one thing. That’s not it. You stare at logs. You form another hypothesis. That’s wrong too.

Hours later, you finally root-cause it. That feeling cannot be described and I loved that part of the job. Now AI has started to do more and more of this for me, and I definitely didn’t think that in just a few years, AI would change so much of how I do my own job and, increasingly, my relationship with code.

At Microsoft, I worked on Exchange Server.

Sometimes we would get reports of issues that had happened to one particular email for one particular customer. Reproducing something like that could be almost impossible.

We tried a lot of things to find what was going on, but it was one of those race conditions that happens occasionally, so consistent repro was not there.

If I built the same thing today, I am pretty sure we would call it an agent.

The idea was simple: for each request, we could register a condition, such as “when the user is Joe and the exception contains ‘InvalidOperationException,’ capture additional information and dump it in a secure log.”

We didn’t need to reproduce the problem anymore.

We waited for it to happen again and collected the information we needed.

In the last year, though, things have started to change.

I was working on a data transfer tool here at Docusign.

I needed to understand a bunch of existing code and add support for some data and tables that weren’t being transferred.

Sonnet 4 had just launched inside Copilot and it was definitely something different.

I started with explaining my data transfer problem to Sonnet 4.

It started going through the legacy code and putting together a plan.

When I came back, Copilot had already come up with a plan.

I sat down and reviewed it. Trust in AI in those days was thin, so I fact-checked its assumptions. And it was mostly good.

I made some minor changes and asked it to go ahead and implement the plan

Something I had estimated at about a week (given the code base was new to me) was basically done in a day.

It still took time to test things locally, get the PR reviewed by other engineers, and eventually deploy it to customers.

That was probably the first time I realized AI was going to change software engineering much more, and much faster, than I had expected.

I don’t write code at all anymore, at least not in the traditional way of “writing code.”

We go back and forth. I ask questions. It proposes something. I disagree. It investigates more. We change the plan. Sometimes we do that several times. (I’m just now realizing I’m calling this workflow “we”.)

Once I am happy with our plan, I let it run.

That’s how I am developing features these days.

I am still making high-level decisions, fo the most part.

But the part where I sit down and type out the implementation?

At Docusign, a coworker and I built our cloud coding agent, aka our “coding elf.”

Initially it was really just the two of us using it. And somewhat ironically, most of what we used it for was to write code for the coding elf itself. Then other engineers started trying it for simple changes like feature flag rollouts and bug fixes. Over time, more and more people started depending on it.

The funny part is that now the coding elf is writing most of its own code.

Sometimes I would send it a Slack message. Sometimes I would assign it a Jira task and give it what to build, and it would go off and come back with a PR.

I would send it tasks during the day. At night. While I was at my kids’ school.

The coding elf could spit out a PR in something like 20 minutes with just a message from me.

That started changing the way I thought about engineering work.

But something that happened during one of our FixIt Days changed it even more.

We have a quarterly FixIt Day where engineers get one day to fix something, or work on pretty much anything they want.

A group of Docusign designers saw our coding elf and asked if it could help them fix a few UX issues. They weren’t asking me to help them fix it; they wanted to use it themselves, instead of creating backlog ticket items for us engineers.

So they gave it a try. They found an issue — a simple bug — then asked the coding elf to convert that into a PR.

During that FixIt Day, they sent around 80 PRs.

More than 10 were merged the very next day. The remaining ones went through review and many were merged over time.

Engineers reviewed the code and it went through our deployment process, but engineers didn’t need to context switch to write the implementation for the simple bugs.

That’s the shift we are seeing across the industry now.

Normally, a designer finds something that needs change and then there’s a handoff somewhere. An engineer has to translate that task/bug into code.

Now, that boundary has started to disappear.

Maybe AI isn’t only changing how engineers write software.

Maybe it’s changing who gets to write software.

The coding elf created another problem for me.

Because colleagues across Docusign — engineers, designers, product folks — had started depending on it to write and update software, I needed to keep it running.

I would monitor errors and exceptions from the coding elf service logs. If I saw a bug, I would investigate it and then ask the coding elf to fix itself.

The coding elf was writing most of its own code.

But I still had to spend time investigating any errors/issues and then tell the coding elf to fix it.

In a way, I was the bridge between the error logs and the coding agent.

So, during Docusign’s next hackathon, two engineers and I built an agentic platform called Krew. I created my first agent (we call them Krewmates) and named it Night Watch.

Night Watch monitors the coding elf service logs. It looks for errors and problems, investigates them, and opens Jira tasks. The coding elf can then pick up those tasks and produce a PR.

So now, I can go to sleep and software engineering continues.

There is some irony here: I spent much of my career loving debugging. That eureka moment when I finally figured out why something was broken was one of my favorite parts of being an engineer.

Then I built an agent to do it while I was sleeping.

As an engineer, that is a strange feeling. Part of me loves it; I built something that can do work I used to spend hours doing myself. That feels “engineering-y” in the sense of automating things and making them better.

But there is another part of me that wonders what happens when we automate parts that we enjoy.

I am still not sure how I feel about that.

AI has changed things in the last year more than I expected.

It has amazed me in many ways. It has also disappointed me.

And one of the things I have started noticing is how much we trust it.

I hear a new phrase from engineers now: “Claude said…”

One actual conversation with an engineer was about a service. He responded, “It’s throwing a 404. I thought it was because the feature flag was off, but Claude said otherwise.”

Claude had a different theory: the host app needed a corresponding route registered. It even pointed to the existing route and the source file where the related routes lived.

It was a detailed, completely plausible technical explanation.

But something about the wording caught my attention.

Not, “I traced it and it looks like we’re missing a route.”

Not, “I think we need a change in the host app.”

I started seeing versions of this trust in AI elsewhere.

Another real message: “Claude said that these fields are exposed with some API somehow connected with Zuora.”

We have an answer. But do we understand the answer?

This was probably my favorite version of a ‘Claude said’: “Copilot said this was 95% coverage. I’m sure it wouldn’t lie.”

But there is something underneath the joke.

Yet we are learning to trust them remarkably quickly.

I mentioned earlier that when Sonnet gave me that data transfer plan, I carefully fact-checked it.

Partly because after something gives you a good answer again and again and again, you naturally start trusting it.

But I have also been burned by that trust.

For one feature, I was researching capabilities in Azure Cosmos DB.

I needed to understand something around the MongoDB API and change streams.

Eventually I went back to the MSDN documentation and started actually reading it myself.

The capability wasn’t supported the way the AI had told me it was.

If AI gave stupid answers all the time, this would be an easy problem.

It doesn’t. It gives incredibly good answers most of the time.

Good enough that I estimated a week of work and got it done in a day.

Good enough that non-engineering designers created 80 PRs in one day.

And good enough that slowly, without really deciding to, we started trusting it.

We recently had a situation where one LLM suggested a fix.

Then our code review agent looked at the change and said the fix was broken.

Maybe the code review agent only noticed it now because those lines had been touched.

So we asked a different LLM to look at it.

Another LLM says the code review agent is right.

It’s funny. But it’s also a preview of a problem I think we are going to deal with much more.

We keep saying agents will review the work of other agents.

Which AI do we believe? One? The other? Neither?

And if a third AI is the tie-breaker, what happens when that one disagrees too?

At some point, someone needs to know what is actually true.

A comparison I hear a lot is that this is just another abstraction layer.

Most engin