AI, Ownership, and the Future of Engineering

As engineers take on more product responsibility, the engineering manager's role changes with them. The familiar structure of a manager overseeing a group of software engineers does not answer every question about how to lead a team of product engineers. We are bringing responsibilities together that were often treated separately.

I see this as a learning process for managers, engineers, and the wider business. We have to understand where people need support, how decisions will be made, and what ownership means in practice. I spoke about this as a transition we are working through, rather than a finished model with every answer already in place.

The pace of development has changed so much that comparing it with how we worked even a year earlier feels strange. I used to spend much more time writing code line by line and looking for answers on Stack Overflow. Now I can explore an idea, build it, and try another approach in a fraction of that time. That changes what I expect from myself as an engineer.

But faster coding exposes the delays around it. A requirement goes back and forth. An edge case waits for a decision. A growing queue of pull requests waits for review. If those parts stay the same, the whole process still gets stuck. In the conversation, I kept coming back to looking at the entire development process, including the work that happens before anyone writes code.

I also see a big difference in how deeply people use these tools. Having an AI assistant open is a starting point. There is much more to explore in how we investigate problems, define requirements, and connect the steps of delivery.

Reading announcements and following other people's experiences only gets me so far. I need to use the tools myself. Building something reveals how to work with an agent, what context it needs, and where the process could be more efficient.

I spend a lot of my weekends experimenting and building things for myself. That gives me a much clearer view of what is possible when I am making decisions as a manager. It also opens up ideas beyond engineering: ways technology could help other people in a business with the work they do every day.

I described using Claude Code for development, Codex for reviews and other tasks, and Cursor as part of the coding environment. The more interesting part for me is how those tools fit into a process. An agent can investigate a bug, create a ticket, write the change, and respond to review comments before bringing the result back for someone to assess.

Review becomes a problem when the amount of code being produced grows faster than people can read it. A queue of dozens of pull requests can turn thoughtful review into a quick skim and an approval. I spoke about experimenting with multiple AI reviewers to address that pressure and continuing to evaluate which tools worked best.

The human questions I care about are architectural and contextual. Is this change doing the right thing? Does the approach make sense in the wider system? Those questions need an understanding of what we are trying to achieve.

Quality standards also need to be part of the instructions we give our tools. When bringing new code into an existing codebase, I want the agent to work with its conventions and constraints. The workflow needs to carry those expectations through implementation and review.

When I can build several possible solutions quickly, choosing between them becomes a much bigger part of the job. The question is which direction makes sense for the product, and which ideas we should say no to. Being able to build more things gives us more decisions to make.

Some of that uncertainty can be resolved by putting alternatives in front of users. I spoke about building two variants, running an A/B test, and using the results to decide what comes next. The cost of trying those alternatives is falling, which makes this approach more accessible to smaller teams.

That is where I see engineering providing more value to the business: making options concrete, collecting useful evidence, and helping people make a decision. We still need priorities. We just have better ways to explore them.

I know very good engineers who are used to receiving a carefully defined ticket. Someone else has understood the problem, chosen a solution, written the acceptance criteria, and handed over the implementation. They can deliver that work quickly and well. But AI is changing how much of that final step needs an engineer to carry it out.

If a ticket already contains all the context and decisions, an agent can do a growing amount of the implementation. That makes it important for engineers to participate earlier. I want engineers to understand why a problem matters, ask questions about the proposed solution, and help work through the details.

This is a real change in mindset, and I do not expect it to feel easy for everyone. Product engineering existed before these tools. AI is making the reasons to work that way harder to ignore.

Deploying a feature used to be a natural point to hand it over and move to the next ticket. With more product ownership, the engineer stays involved. Did the feature do what we expected? Did the fix solve the problem? What are the metrics telling us?

Those answers should shape the next decision. Sometimes we need another iteration. Sometimes the first version has missed something. I see understanding what happens after release as part of the engineer's responsibility. It takes a different kind of attention from simply working through a queue of tasks.

People outside engineering are gaining the ability to build something useful for themselves. Designers can turn an idea into an interactive prototype. Teams doing manual work can explore a tool that makes their day easier. They can bring something working to a conversation about what they need.

That changes how I think engineers should respond. We can welcome the initiative, understand the problem it solves, and help with the next step. A working example often communicates the intended behaviour much more clearly than a short written request.

There is still work in making that code fit an existing system. Integration, security, maintenance, and competing priorities all matter. I want to keep the energy that made someone build the first version while applying the standards needed to support it over time. AI can help with that integration too.

If the job has changed, the interview should reflect it. I want to see how someone works with the tools they will use day to day, including AI. That means giving them room to show how they approach a problem and how they get a working change over the line.

I described a practical exercise where candidates receive a repository and its issues a few days in advance. They have time to set it up and understand the work. During a 45-minute coding session, they can use whichever AI tools they choose, without restrictions. There are several issues available, so the choices they make are part of what I learn: where they start, why they choose it, and what they manage to deliver.

The rest of the technical conversation still matters. I ask about system design, explore decisions from their own experience, and test their understanding of the underlying technology. Fast output alone does not tell me the difference between an experienced engineer and someone who can generate a lot of code.

A CV can only show so much of this. Naming an AI coding tool tells me less than explaining a workflow someone built or an agentic feature they implemented. I want to understand the depth of their experience. The interview process itself needs iteration as we learn how to assess these skills better.

I finished the conversation thinking about people who have wanted to build something but kept running into the same limits: needing a team, needing to hire, or having too much to do alone. AI is changing what one person can attempt.

The opportunity reaches beyond development. Marketing, sales, and customer support are all part of running a business, and these tools can help across those areas too. I expect to see more solo founders and small teams doing work that previously needed a much larger group.

If you have had an idea sitting there for years because you could not see how to get started, this is a good time to look at it again. That was the thought I wanted to leave people with.