We're All Managers Now: My Journey into AI-Assisted Development(sourcegraph.com)

What does the future of software engineering look like? Everybody is trying to figure out the answer to that question right now. This article shares the journey I’ve been on for the past couple of months toward discovering that answer for myself.
Exploration and Discovery
A few months ago I left my job as an engineering manager (EM) at a FinTech company (Chime) to take a sabbatical to have more time and energy to work on my own projects, ideas and interests. In retrospect, another reason was that I could see myself falling out of date with respect to the AI tooling that is available now and I wanted to have time to explore that more. Having been a manager for the past four years, I could tell that I was in danger of becoming out of touch and being one of those managers that people don’t take seriously because they are still referring to how things were done 10 or 20 years ago.
A bit of context about me. While I work in tech and have been a software engineer for many years before becoming a manager, I wouldn’t consider myself an Innovator on the Innovation Adoption Curve. When cell phones originally came out, I was the last person in my friend group to get one. The same thing happened when Facebook revolutionized social communication when I was in university - again I was one of the last people in my social group to sign up. I tend to choose boring, stable programming languages and tools for my work and side projects. I’m pretty much one of the people that needs to be dragged into trying out new things.

Figure 1 Innovation Adoption Curve - I likely fall into one of the Majority categories when it comes to adoption among other tech-peers

My journey with AI programming has followed a similar path. Over the Christmas break in 2024, I had some time and started playing around with using AI for programming on my personal projects. While I was initially skeptical, I was pretty impressed. I started with some simple tasks and got to the point of asking it to build a very specific setup using some niche libraries. Before prompting it, I thought there was no way it could pull this off, since there was likely very little knowledge available about these libraries. So I was stunned when it did complete the ask and that’s the point when the light bulb went off for me. In June 2025 I was using it enough that I started paying for the basic Claude Code plan. That then increased to the Claude 5x Max plan in March 2026.
After leaving my job at the end of March, I’ve been working on a startup idea and using Claude on a full-time basis. I started by just emulating how I previously worked as a software engineer. I used it to refine my idea, build a plan, and help with software development. I was always the one providing the input, though. So the cycle was a continuous Prompt -> Process -> Response cycle.

flowchart TD
subgraph User["👤 User Actions"]
Prompt["📝 Provide prompt(question or request)"]
Review["👀 Review response(evaluate output)"]
end

subgraph Claude["🤖 Claude Actions"]
Wait["⏳ Process & analyze(understand context)"]
Generate["🧠 Generate response(write code/text)"]
Return["✅ Return result(deliver response)"]
end

Prompt -->|send| Wait
Wait --> Generate
Generate --> Return
Return -->|receive| Review
Review -->|refine| Prompt
Review -->|accept| Done["✓ Complete"]

style User fill:#e3f2fd,stroke:#1976d2,stroke-width:3px,color:#000
style Claude fill:#f3e5f5,stroke:#7b1fa2,stroke-width:3px,color:#000
style Prompt fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000
style Review fill:#bbdefb,stroke:#1565c0,stroke-width:2px,color:#000
style Wait fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000
style Generate fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000
style Return fill:#e1bee7,stroke:#6a1b9a,stroke-width:2px,color:#000
style Done fill:#c8e6c9,stroke:#388e3c,stroke-width:2px,color:#000

Figure 2 Prompt -> Process -> Response cycle when pairing with AI
During this time Claude was pretty much writing all the code and I was reviewing it all. I thought I should do this as part of being a software engineer: to understand the system, and to help influence the setup and best practices early on. I also didn’t really have enough trust yet in AI development.
Originally, I was also following Claude’s output in real-time as it went through processing. This was useful to understand the steps it was taking. Sometimes I would be able to catch issues early if it was going off in the wrong direction because I hadn’t explained something well enough. Eventually, though, I felt I didn’t need to do this anymore as I started to trust Claude more.
So this led to me mainly reviewing the output after it was generated — providing feedback, or merging the code if it looked good enough, and then moving on to the next task.
Efficiency
The problem became: what to do during Claude’s processing time? This could sometimes last for several minutes.
One day I experimented with seeing how far Claude could go on its own. I had a large feature that I wanted to develop. Instead of breaking it down task by task and working on it together with Claude, I tried providing Claude with as much context as I could all in one go and then left it to move forward with the plan and implementation. It generated several chained PRs over the course of maybe 20-30 minutes. When I started reviewing them though, I realized that Claude had missed the mark. There was a mismatch between my vision and what Claude had understood. After going back through artifacts that had been generated during earlier planning phases, I could see how it wasn’t fully clear.
This led me to an important realization about working with AI: requirements and specifications are even more critical to get right up front. They have always been critical, but now the feedback cycle is much shorter, so it’s easier to see the negative impact of missing requirements. On a large project, if you discover a critical design issue several months in, it’s painful. And because the feedback is so delayed, it’s easy to overlook the lesson for the next project.
I now spend a lot more time reviewing early requirement and design docs and making sure those align fully with my vision and how I want the system to be set up. More attention and energy gets placed in this phase than the implementation phase.
Multi-Tasking
Another attempt I made at using Claude’s thinking time was multi-tasking. I remembered this was something I needed to do as a software engineer. When finishing a pull request (PR) and marking it as ready for code review, there could sometimes be several hours before someone else on the team got around to reviewing it. During that time, I’d get started on my next task. This could be a dependent task: if I had high confidence that there would be no major design changes needed, I would branch off the first PR and continue on. Or I’d work on an independent task - something completely unrelated to that part of the codebase, like a bug fix elsewhere.
I realized I could do the same with Claude’s processing time. Prompt task A, make sure Claude is getting started, then prompt task B during the processing time. From there I’d switch back and forth between A and B as each response was ready. Sometimes that still wasn’t enough — I’d be waiting on both A and B, so I’d start a third task.
I felt I reached my limit at three items on the go. It started to get confusing navigating between three of them and reminding myself of the context of where I left off. For example, if task A finished and needed a lot of verification - maybe 20 or 30 minutes - and then B needed the same, by the time I got back to Task C it could have been over an hour later.

swimlane-beta
subgraph TaskA[Task A]
A1["👤 Prompt1-5 min"] --> A2["🤖 Processing5-10 min"] --> A3["👤 Review~25 min"]
end
subgraph TaskB[Task B]
B1["👤 Prompt1-5 min"] --> B2["🤖 Processing5-10 min"] --> B3["👤 Review~25 min"]
end
subgraph TaskC[Task C]
C1["👤 Prompt1-5 min"] --> C2["🤖 Processing5-10 min"] --> C3["👤 Review~25 min"] --> C4["⚠️ Context Lost~85+ min"]
end
%% cross-lane sequencing = the real interleaved timeline (each drops one row in time)
A2 -.->|prompt B while A runs| B1
B2 -.->|prompt C while B runs| C1
C1 -.-> A3
A3 -.->|context switch| B3
B3 -.->|context switch| C3

classDef human fill:#fff3e0,stroke:#e65100,color:#000;
classDef claude fill:#e8eaf6,stroke:#3f51b5,color:#000;
classDef problem fill:#ffccbc,stroke:#e64a19,color:#000;
class A1,B1,C1,A3,B3,C3 human;
class A2,B2,C2 claude;
class C4 problem;

Figure 3 Multi-tasking by prompting 3 different Claude sessions in parallel
We’re All Managers Now
I think my experience as an EM actually helps dealing with this. As an EM I needed to learn to get comfortable with context switching a lot more than when I was an individual contributor (IC). As an IC, I would be focused on one task for several hours at a time before switching to something else. I did not have that luxury as manager. That luxury is also over for software engineers.
I also needed to get comfortable with the team getting things done and learning about it through the appropriate communication feedback loops rather than just doing things myself. This naturally led to me being at a higher, more general level of understanding rather than knowing the details like how the code was structured. While I believed as an EM it was important to do some code review and be aware of major changes, I was managing a large team and did not have enough time to do it as regularly or as much as I would have liked.
The realization I had is similar to what Steve Yegge pointed out last year (he must be an Innovator).

Figure 4 c/o Steve Yegge - The IC role will change to become a creator and manager of agents

Reading AI-related threads on forums like Hacker News, I see a lot of frustrated comments from software engineers about the changes the profession is undergoing. This is totally understandable. While software engineering has always been a profession where you need to keep actively learning new tools and technologies, there hasn’t been a shift of this magnitude within the post-dot-com generation.
The role and activities of a software engineer have changed. If you’re currently in the field, it’s important that you take time to educate yourself on new ways of doing things so that you don’t end up becoming a Laggard.
Some resources I’ve gone through recently that have been helpful:

Hands On Large Language Models by Jay Alammar and Maarten Grootendrost
5-Day AI Agents Intensive Course with Google
5-Day AI Agents: Intensive Vibe Coding Course with Google

In my next post, I’ll write more about how I’m using LangGraph and AI Agents in an attempt to replicate the Software Development Lifecycle (SDLC).

AI Disclaimer: This article is original content written 100% by me (a human). Flowchart images were generated with AI. AI was used in an editor role to help edit my first draft.