My very first job was in India during the late 90s. I joined a computer-aided design software company in Pune. I had just finished my Ph.D. My first computer at work was a state-of-the-art Sun Sparc workstation. It was bulky, but I loved the keyboard. The company handed those workstations off to us because the codebase was huge, computationally heavy, and required graphics-rendering power. It was a large proprietary codebase in C, C++, and PERL. Shortly after I joined, the company sent us to its headquarters in Bedford, MA. We spent about four months there. I don’t recall committing any code before that trip. I don’t think we were even allowed or expected to check in code for some time. No one mandated that we be productive on day one. We spent most of our time setting things up, reading manuals, and learning to build, debug, and run the codebase. Java was new then, and I used to get back to work at night to learn and build apps on the side. I couldn’t afford a personal computer yet. Residential Internet infrastructure wasn’t there then. While in Bedford, I was assigned a mentor. He was very soft-spoken and extremely knowledgeable about the codebase and the mathematics behind it. He would assign one or two bugs each week. He would occasionally drop by my cubicle to check in, or I would stop by his to ask question My first few months in that job felt like fighting the machine every day. The codebase was huge and poorly modularized. There were global structures and variables. You could spend hours figuring out which line touched which variable. I didn’t write the code. I didn’t invent the structure. My daily experience was attaching a debugger to the build, exercising the defect flow, and browsing the code. Once in a while, I would have an aha moment. I’d suspect something, then dive into the code. Then I’d repeat it and end up somewhere else. A few hours later, I would give up after reaching dead ends and backtrack. Navigating the code felt like exploring an underground maze. I would go down the wrong paths for days. At first, my mentor would pull me out. I would soon end up in the next dead end. I remember that exercise being very hard, and debugging the code to understand how it worked before identifying what to fix used to take a few days. Once identified, the fixes were usually small. Then I would show the change to my mentor, and he would often show a smarter way and a smaller fix elsewhere. Unlike me, he had written big parts of that codebase by hand and knew it well. I remembered that experience yesterday while working with a coding agent to debug a query performance issue. Though the same agent wrote about half the code, I wouldn’t call it writing. It assembled code snippets to meet my goals. My goal descriptions weren’t always precise, so it filled in what I didn’t say and built parts of it. As a result, the code grew larger. I had moments of “That’s why you built that feature I didn’t ask for? Huh.” When I gave it the goal of finding the root causes of the issue, it ended up in a maze with plenty of dead ends. It never once considered stepping back. Instead, it kept pursuing every possible path, running the coding-testing-performance-testing loop dozens of times. Finally, I intervened and asked pointed questions to help it step back. That didn’t work either. Then I handed that problem off to another agent and asked it to take a fresh look. Eventually, we had a solution. That’s when I realized what changed and what didn’t. At first, I thought I was that mentor, but I didn’t write the code either. The best I could do now was to ask questions and steer. My struggle to fix the issue would be worse than my agent’s. My agent is that new employee, the one fighting with the code. That fight remained, but it got cheaper. And yes, I wouldn’t earn my first job today.