engineering·AI·technical-leadership
My Role and Goals in the AI Era
An article about engineering work at Stripe helped me review my recent work and goals in the AI era.
- PROBLEM
- I needed to define my role between direct building and wider technical responsibility in a faster AI work environment.
- DECISION
- I set four parts of my role: building, problem framing, helping others, and quality checks.
- OUTCOME
- I defined four parts of my current role and set goals that do not depend on doing everything alone.
I recently read an article about Staff Engineers at Stripe in 2026. It says AI makes work faster, but it also raises expectations. Staff Engineers must manage several agents and projects. They must also improve the work of people around them.
My work environment is different from Stripe. Still, the article helped me review my recent work. My role is already moving beyond finishing one project well. I needed to define what I own now and what I should improve next.
The problem I owned
My recent work did not fit one simple job name. I designed and operated an internal content system. I scoped a web service to replace manual support work. I helped non-developers build tools with vibe coding. I also reviewed deployment access, security alerts, bot hosting, and domain migration.
These tasks look different. However, they had one common point. The owner or scope was unclear at the start. Some requests crossed several teams and systems. My role was to enter this unclear space and make the next decision possible.
Facts and limits I checked
Direct building is still important. When a live system fails, I need to find the cause and restore it. Some internal tools also need fast testing from planning to deployment. If I move too far from real systems, my designs can miss the real problem.
However, doing every task myself makes me a bottleneck. Repeating the same setup in one-to-one support does not scale. Building every requested tool for other people also has a clear limit.
AI can make coding faster. It does not create context or ownership. More output also creates more review work. We must check deployment rules, access rights, data use, and maintenance earlier.
The choice I made
I defined four parts of my current role.
First, I build directly when the problem is an important bottleneck. I should be able to check the real code and operating environment.
Second, I turn unclear requests into material that the organisation can decide on. In one case, I reviewed many work sheets. I separated items to move, items to remove, and items to delay. Then I asked the right group to decide ownership and launch stages.
Third, I help the next person move without me. During vibe coding support, I changed a repeated setup task into a guide that others could reuse. Code reviews and short decision records serve the same goal.
Fourth, I set quality limits without blocking speed. I checked that automated deployment worked before reducing direct deployment access. For an external traffic change, I placed certificate and network checks before the DNS switch. I do not want to control every task. I want to find the few points where mistakes are expensive.
What I actually did
These parts already appear in my work. For one internal system, I handled design, building, operations, and incident recovery. In another task, I reviewed manual work and reduced it to a clear first release. I changed one-to-one setup help into reusable documents. I also reviewed automation, access, and public traffic as one operating flow.
The article’s use of several AI agents is a goal I want to explore more. Research, drafts, and repeated coding can run in parallel. However, a person must still choose the problem, set acceptance rules, and own operational risk. My goal is not to run the largest number of agents. It is to keep good judgement and clear checks while using them.
Confirmed results and remaining work
My current role is now clearer. I work on technical problems left between teams. I turn them into a scope that people can act on. When needed, I also build and operate the solution myself. After that, I should turn repeated work into documents, automation, or checks that help other people move faster.
My next goal is not to do more work alone. I want to change repeated support into self-service. I want a clear view of the status and quality of agent work. I also want high-risk changes to meet clear checks before deployment. Other engineers and vibe coding builders should be able to own more work safely.
This result is not complete yet. I will not judge the role only by the number of tasks I finish. I will check how quickly unclear decisions become clear. I will also track repeated support and risks found before deployment.
AI should not only raise my personal output. It should raise the organisation’s ability to execute. That is the role and goal I am working toward now.